Ein Artikel ohne Bilder ist wie ein Redner ohne Stimme – langweilig bis lästig.
Aber woher nehmen und nicht stehlen?
Über 3 Millionen legale Bilder zu bezahlbaren Preisen gibt es z.B. von http://www.fotolia.com/. In dieser (kleinsten) Auflösung (z.B. 412×292) für nur 83¢.
English article at Bad Habits Die Hard – How to Prepare Java Apps for Full Speed Debugging.
Beim Instrumentieren einer Java Anwendung für (auch Remote) Debugging werden oftmals VM-Parameter verwendet, die die Anwendung spürbar verlangsamen, da sie den Just-In-Time Compiler der Java VM ausschalten, z.B.:
-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
-Djava.compiler=NONE
Ab Java 1.4 ist es weder erforderlich noch per se ratsam, den Java Just-In-Time Compiler auszuschalten.
Die Anweisung -Djava.compiler=NONE sollte einfach entfallen:
-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
So kann eine Anwendung für das Debuggen vorbereitet werden, ohne dass ihre Performance darunter leidet, solange sie nicht aktiv debugged wird. Und selbst während des Debuggens wird die Anwendung durch den Just-in-Time Compiler beschleunigt. Dies ist in Test- (oder sogar Produktions-) Umgebungen sehr willkommen, die sowohl performant ausgeführt werden sollen, als auch eine bei Bedarf zu öffnenende Hintertür enthalten sollen, durch die Probleme untersucht werden können.
Sogar in aktuellen Posts wird das -Djava.compiler=NONE Antipattern verbreitet, wie z.B. bei ImageJ Plugins in Eclipse entwickeln.
Und das böse -Djava.compiler=NONE versteckt sich nicht nur in vielen Konfigurationsdateien und Werkzeugen, sondern hat es sogar geschafft, bis in Java 6 selbst vorzudringen. Siehe -Djava.compiler=NONE and -Xdebug anachronisms unanachronistically disable full-speed debugging in Suns Bug Database.
Deutsche Fassung bei Debuggen von Java Anwendungen – auf der Überholspur!
When instrumenting your Java application for remote debugging, a commonly used set of VM parameters brings your application to a crawl, as it disables just-in-time compiliation and enforces interpeter-only mode, e.g.:
-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
-Djava.compiler=NONE
Starting with Java 1.4, it is neither required nor advisable to disable the Java just-in-time compiler,
so just remove the -Djava.compiler=NONE:
-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
Thus, you are able to prepare your application (e.g. JBoss) for debugging, and there will be no perceivable overhead unless you actually connect your debugger to the debuggee (using remote debugging). And even while debugging, the Java just-in-time compiler will speed up your application. That may be handy for test (or even production) environments that are supposed to both deliver full speed and still supply a back door for debugging once the need arises.
Even recent posts still promote the -Djava.compiler=NONE antipattern, as in See how maven works inside – remote debugging plugins or Debugging your Maven Project in Eclipse.
And the bad -Djava.compiler=NONE habit may still be hidden within numerous configuration files or tools, as it even made its way into Sun’s Java 6 itself. See -Djava.compiler=NONE and -Xdebug anachronisms unanachronistically disable full-speed debugging at Sun’s Bug Database.
The Acoustic Energy WIFI Internet Radio
The AE 100 was one of the first devices that, in a stand-alone unit, receives radio broadcasts from all around the world using Reciva technology and firmware.
AE 100 users are well aware of a common pitfall of this unit. When the volume is low your listening experience is impaired by frequent crackling noises.
Where do those crackling sounds come from?
Inside the AE 100 there is a WIFI USB stick, that implements the connection to your wireless LAN. The RF energy of its transmitter leaks into the wires which connect the loadspeakers to the analog amplifier circuit, where it is rectified and causes transmission packets to be heard. Well, it’s not a Sony 😦
How to avoid them?
There are some work-arounds for this bug, notably the one provided at AE 100 crackle problem : yet another fix. Philippe gives detailed instructions on how to dismantle the unit and how to shield the loadspeaker wires using shielding foil from STP computer cabling.
My no materials approach: Just twist them wires
Losely following Philippe’s instructions (I put the unit flat on its side, so I would not need three hands to handle the housing parts), I opened the case and unplugged the loudspeaker wires. Then I twisted them gently, so that they looked similar to the ones found in UTP cabling. I then reconnected the wires and reassembled the unit, trying to put as much of the wires near the loadspeakers as possible.
Less noise in almost no time at all
The crackles can still be heard with the volume set to 1 bar and your ear next to the front grid, but they are no longer perceivable at all during normal use 🙂
The actual noise level may be more or less random depending on the position the wires will take when closing the unit.
After having installed Java 6 Update 2, my Internet Explorer 6 would refuse to start without any indication whatsoever. I’m running Windows 2000 Server and – as I’m doing Java development – there are numerous older JDKs installed on my PC.
The problem appears to be caused by …Javajre1.6.0_02binssv.dll (SSVHelper Class plugin) included within Java 6 Update 2 up to and including build version 1.6.0_02-b05.
IE immediatley returns to normal operation by either uninstalling Java 6 Update 2 or disabling the SSVHelper Class plugin.
As I was unable to disable SSVHelper from within IE 6 (I believe it is an IE 7 feature) I reverted to ShellExView, an excellent Shell Extensions Manager that allows arbitrary Shell Extensions to be disabled in case they are causing problems – SSVHelper in my case.
13-jul-07 update:
The bug has been fixed and the downloads at http://java.sun.com/javase/downloads/ have been updated to build version 1.6.0_02-b06 (as shown by java -version).
To recover your PC from this bug, either re-download and re-install the JRE or disable the SSVHelper Class.
Links:
Zusammengefasst: Verwenden Sie für Ihr 2,4 GHz WLAN auschließlich die Kanäle 1, 6 und 11. Und die Welt wird ein klein wenig besser – ganz umsonst 🙂
Endlich! Ihr neuer WLAN Router und auch die Zugangsdaten sind eingetroffen. Da Sie ein umsichtiger und technisch versierter Mensch sind, wählen Sie den Kanal für Ihr neues WLAN so, dass er sich möglichst nicht mit denen Ihrer Nachbarn überschneidet. Bei der Suche nach verfügbaren WLANs stellen Sie fest, dass die Kanäle 1, 6, 9 und 11 bereits belegt sind und entscheiden sich für den Kanal 3. Sie sind sich nun ziemlich sicher, dass Sie Ihr WLAN optimal eingestellt haben und alles wie am Schnürchen laufen sollte. Glauben Sie…
In Wirklichkeit haben Sie gerade eben einen neuen Störsender installiert, der die Übertragungsgeschwindigkeit dreier WLANs halbiert – einschließlich Ihres eigenen. Wie kann das sein?
Nur 3 der 11 weltweit verfügbaren Kanäle überschneiden sich nicht: 1, 6 und 11
Dies liegt an der Frequenzbelegung der Kanäle in den 802.11 b/g Standards und dem Verhalten der WLAN Stationen: Während die einzelnen Kanäle voneinander nur einen Abstand von 5 MHz aufweisen, beträgt die von einer Übertragung genutzte Bandbreite etwa 20 MHz. Das bedeutet, dass nicht nur der eingestellte Kanal selbst, sondern auch die beiden nächstkleineren und die beiden nächsthöheren Kanäle belegt werden.
Daher nutzt eine WLAN Station, die auf Kanal 1 eingestellt ist, die Kanäle 1-2-3. Der nächste nicht-überlappende Bereich ist bei Kanal 6, der das Frequenzspektrum der Kanäle 4-5-6-7-8 nutzt. Der verbleibende Kanal 11 nutzt das Frequenzspektrum der Kanäle 9-10-11-12-13.
Überlappende Kanäle vermindern den Durchsatz erheblich
In städtischer Umgebung und mit nur 3 nutzbaren nicht-überlappenden Kanälen müssen sich WLANs irgendwann gegenseitig stören. Wenn man die gegenseitigen Störungen also schon nicht gänzlich vermeiden kann, ist es dann nicht besser die Lücken zu füllen, also alle verfügbaren Kanäle zu nutzen? Zwei Stationen, die auf den gleichen Kanal eingestellt sind, sollten sich mit Sicherheit stärker behindern, als wenn sie zwei benachbarte Kanäle nutzten. Überraschenderweise ist das nicht so.
WLAN Stationen sind überhaupt nicht dumm. Bevor sie einen Datenblock senden, hören sie zuerst ihren eingestellten Kanal ab, um festzustellen, ob bereits eine andere Station gerade einen Datenblock sendet. Erst wenn “die Luft rein” ist, beginnen sie mit der Ausstrahlung. Dieses Verfahren (DCF, eine Variante des CSMA) soll gegenseitige Störungen des gemeinsam genutzten Übertragungskanals minimieren. Dies ist ein Punkt, der sehr oft übersehen oder ausgeklammert wird, auch in wissenschaftlichen Arbeiten.
Wenn Station überlappende Kanäle verwenden (die also weniger als 5 Kanäle auseinander liegen), wird die Fähigkeit der Stationen, andere Übertragungen zu erkennen behindert – so als würden Sie ihnen ein Tuch vor die Augen binden – wodurch sich ihr soziales Verhalten verschlechtert und sie zu egoistischen Kriminellen werden.
Außerdem bewirkt die Bandbreite einer Übertragung, deren Kanal sich nicht an die 1-6-11 Regel hält, dass gleichzeitig zwei der nicht-überlappenden Bereiche gestört werden. Daher verursachen Stationen, die sich nicht an die 1-6-11 Regel halten, unwissentlich vermeidbare Störungen, die ihrerseits wieder zu häufigen Sendewiederholungen führen, was letztlich den Durchsatz ihres eigenen und den benachbarter WLANs in den Keller bringt.
Was ist mit den Kanälen 12, 13 und 14
In Europa und Japan gibt es zwei zusätzliche Kanäle: 12 und 13. Sie bieten jedoch keinen wirklichen Nutzen, da sie sich das Frequenzspektrum der Sendungen mit Kanal 11 überschneidet. Daneben besteht die Gefahr, dass WLAN Stationen sich nicht mit Kanal 12 oder 13 verbinden können, falls sie nicht richtig für den Betrieb in Europa konfiguriert worden sind. So kann z.B. ein Nokia E6x keine Verbindung mehr über Kanal 12 und 13 herstellen, wenn Sie das SIMM aus dem Telefon entfernen.
Kanal 14 ist etwas Besonderes. Er wird nur in Japan verwendet und trotz seiner Nummer besitzt er einen Abstand von 12 MHz zu Kanal 13, er wäre also besser mit Kanal 15,4 bezeichnet worden. Da sich die Übertragungen auf Kanal 14 nur minimal mit denen des Kanals 11 überschneiden, können in Japan die Kanäle 1, 6, 11 und 14 verwendet werden, um gegenseitige Störungen zu minimieren.
Links:
Demnächst: Warum SuperG und andere 108 MBit-Verfahren mehr schaden als nutzen. Warum eine 3dB Antenne mehr bringt als 12 dB mehr Sendeleistung.
In short: Only use channels 1, 6, 11 (and 14 if you live in Japan) for your 2.4 GHz wireless LAN and simply ignore the other ones. The world will be a better place with no effort at all 🙂
Great! Now you have got a WiFi of your own. As you are a prudent guy you’ll carefully choose a free channel so as not to interfere with your neighbors’ WiFis. Scanning for available networks reveals that channels 1, 6, 9 and 11 are already being used, which leaves channel 3 as the way to go. You are quite confident that everything should be in order now. The truth however is rather disconcerting and may come to you as a shock.
What you have really done is, you have set up a new jammer that will halve the throughput of at least 3 networks – including yours. How can that be true?
Only 3 out of 11 channels do not interfere: 1, 6 and 11
This is due to the channel allocation scheme that is used by 802.11 b/g standards and the behaviour of WiFi equipment: While channels are equally spaced 5 MHz apart, the bandwith consumed by a single transmission path is roughly 20 MHz, effectively occupying 5 channel slots: The center channel it is set to, 2 adjacent channels towards lower frequencies and 2 channels towards higher frequencies as well.
Thus a station set to use channel 1 will occupy channels 1-2-3. The next non-overlapping channel will be 6 occupying channel slots 4-5-6-7-8. The only channel left will be channel 11 occupying channel slots 9-10-11.
Overlapping channels substantially decrease throughput
Assuming urban surroundings and just 3 useable non-overlapping channels, wireless networks are bound to interfere with each other. If interference cannot be avoided, why not try to minimize interference by “filling the gaps”? Two stations using the same channel should most certainly experience much more interference than if they were using different ones, even if they were just one slot apart. Suprisingly enough, this is not true.
Wireless stations are by no means dumb passive devices. Before initiating a transmission they will listen for other ongoing transmissions and abide from starting their own transmission when they find that the channel is currently in use, thus minimizing interference (DCF, CSMA) . Sadly enough, this is an important factor that is often overlooked or set aside, even in academic documents.
Now when you offset two stations by less then 5 channels you’ll impede their capability to properly detect ongoing transmissions – practically blindfolding them and turning them into anti-social criminals.
Furthermore, by virtue of its bandwidth, each transmission that does not adhere to the 1-6-11 rule will use up 2 instead of 1 out of the proper channel bands described. Thus stations set to channels other than 1, 6 or 11 will unknowingly and unneccessarily interfere and disrupt both each other and other adjacent channels, in turn causing frequent re-transmission which will bring throughput down to a crawl.
What about channels 12, 13 and 14
Within Europe and Japan, there are two additional channels available: 12 and 13. But they are of little use, as they both overlap with channel 11. Still worse, devices may refuse to connect to those channels, unless they have been set up properly, e.g. a Nokia E6x will no longer connect to channels 12 and 13 when you remove your SIMM.
Channel 14 is a very special case. It is used in Japan only and despite its number it is spaced 12 MHz apart from channel 13, so it might have been named channel 15.4. Transmissions on channel 14 will interfere only minimally with those on channel 11. Therefore, in Japan there are 4 channels that should be used in order to minimize interference: 1, 6, 11 and 14.
Links:
Comming next: Why SuperG and other 108 MBit transmissions often cause more damage than benefit. Why a 3 dB Antenna boosts more than increasing Transmit Power by 12 dB.
Just all the pictures dumped from my camera using FirmTools AlbumCreator.
Hier einfach alle Bilder aus meiner Kamera, aufbereitet mit FirmTools AlbumCreator.
After upgrading to WP 2.1, Kelson had to downgrade WP-Cache 2.1 to a tweaked 2.0.17, because with RSS feeds WP-Cache 2.1 would, when serving a request from its cache, always return Content-Type text/html instead of Content-Type text/xml.
Why does WP-Cache not reproduce the original Content-Type text/xml?
I had a look at wp_cache_shutdown_callback within wp-cache-phase2.php and found that all and everything should work perfectly.
Disabling WP-Cache’s code that forcibly sends a Content-Type text/html header if there is none, led me to the mazes ob flush(), ob_flush(), ob_end_flush(), headers_sent() and the like. And to the interesting fact, that…
WP-Cache does not see at least some of the http response headers, that have been output by WordPress code. Why?
If WP-Cache misses some headers, the reason must be located somewhere in the way it tries to retrieve them. wp_cache_get_response_headers() first interrogates apache_response_headers() and, if this function does not exist, reverts to headers_list().
headers_list() docs clearly state, that it returns both, headers that have already been sent and those that have not yet been sent, i.e. are about to be sent. That might be the ones, that WP-Cache is missing after all. headers_list() requires PHP >= 5, but even then, headers_list() may not work at all due to Bug #29683 headers_list() func. return empty array.
apache_response_headers() requires PHP >= 4.3 (>= 4.3.3 with NSAPI) and its docs are a little bit vague on platform requirements. There are some hints on how to have it “working good”.
Fix for wp_cache_get_response_headers within wp-cache-phase2.php:
function wp_cache_get_response_headers() {
if(function_exists('apache_response_headers')) {
flush(); // fix text/html on feeds
$headers = apache_response_headers();
} else if(function_exists('headers_list')) {
$headers = array();
foreach(headers_list() as $hdr) {
list($header_name, $header_value) = explode(': ', $hdr, 2);
$headers[$header_name] = $header_value;
}
} else
$headers = null;
return $headers;
}Last-not-least an honorable mention of ieHTTPHeaders , that made it possible to spy on both the actual http request and response headers and much more. Thanks to Jonas!
There’s another interesting area as to when a page needs refreshing. It’s the If-Modified-Since header. Do WordPress and WP-Cache support this technique, and why not? I’ll try to cope with that one in a future post…
After having added some wallpapers to Vistered Little, I learnt that they will all be downloaded, regardless whether they are actually shown or not. That sums up quite a bit… The reason is, that the background selection does not display real thumbnails, but just tiny squares taken from the center of the wallpaper images instead.
That was easy – I thought. Thus I modified Vistered Little so that the menu would fetch its images from a separate directory (wallpapers/thumbs) and then prepared real tiny thumbnails (20×20 px). All and everything appeared to be great, even my Nokia E61 now showed the site without a glitch (it used to choke on the multi megabytes before), but… IE 6 would no longer refresh its background on a selection change 😦
The problem only occurs with Internet Explorer 6. IE 7 is ok, as is Firefox. I’m currently working on this bug… In the meantime, press F5 to refresh.
It appears as though programming real world browsers is a preview of living hell. IE 6 completely refuses to load images when requested by setting document.style.background, but happilly displays them if – by chance – they have been loaded at least once before. Changing the background image within the onload event of an Image object did not work with Firefox 1.5, but works as advertised with both IE 6 & 7.
So here’s a code snippet that appears to work for FireFox (1.5), IE (6&7) and the Nokia E61 alike – the background is set both, immediately and within the onload event, if required 🙂
function setBackgroundWP(bgNumber,bgUrl) {
var im = new Image();
im.bgSty = "url('" + bgUrl + "') top center fixed";
im.setBackgroundWPOnLoad = function() {
if (document.body.style.background != this.bgSty) {
document.body.style.background = this.bgSty;
};
};
im.onload = im.setBackgroundWPOnLoad;
im.src = bgUrl;
document.body.style.background = im.bgSty;
createCookie('wpcookie',bgNumber,7);
}Disabling JavaScript reveals a tiny bug within Vistered Little: The initial background style refers to the wrong directory within functions.php.spitOutWallpaperCSS() :
// nono print "/images/" . $wallpaper . "') top center fixed; }n";
print "/wallpapers/" . $wallpaper . "') top center fixed; }n";
Reiner Saddey's Place 