
Interessanter Artikel bei der 'jetzt' darüber, was mit meiner Generation nicht so ganz stimmt: sie entscheidet sich nicht.
Ich finde vor allem das Beispiel nett: statt sich zu entscheiden, welche Musik man auf seinen kleinen MP3-Player nimmt, kauft man sich lieber einen mit einer größeren Festplatte. Das warn noch Zeiten, als man bequem nur ein paar Kasetten oder CDs mitnehmen konnte... oder gar nur zwischen ein paar Radiosendern wählen konnte.
Dieses Nicht-Entscheiden zieht sich aber durch viele Lebensläufe: Beim Studium wird möglichst spät erst der Schwerpunkt gewählt, vielleicht schon das Studienfach so gewählt, dass man später "alles machen kann" (aber nichts richtig!).
In den USA ist ein MBA typischerweise ein Aufbaustudium. Das Leute machen die bereits einen Beruf haben, und dort ins Management aufsteigen können wollen. Bei uns jedoch wird das für manche zum Selbstzweck: gleich 'Manager' studieren, um sich nicht vorher entscheiden zu müssen, in welche Richtung es denn wirklich gehen soll.
Mir wird oft gesagt, dass ich talentiert sei. Ich bin mir da nicht so sicher - aber ich habe mich oft für (oder gegen) Sachen entschieden und das dann durchgezogen. Statt herumzueiern, und ewig Optionen gegeneinander abzuwägen einfach eine durchgeführt. So habe ich mich früh für Linux entschieden - klar, meine frührer sehr detaillierten Windows-Kenntnisse sind inzwischen verstaubt und veraltet - aber letztlich habe ich mir damit keinerlei Chancen verbaut, nur neue Eröffnet. Und habe jetzt einen enormen Erfahrungsvorsprung in diesem Thema.
Lieber Experte in einem Gebiet als bestenfalls mittelmäßig in allen!
Deswegen: sucht euch ein Thema, und wartet nicht darauf, dass ein Thema euch findet. Spezialisiert euch, und ihr werdet dabei Erfahrungen sammeln, die euch auch helfen, falls es das 'falsche' Thema war!
(Und das gilt übrigens nicht nur für Akademiker. Wer sich nicht entscheiden kann, ob er Schreiner oder Maurer werden will, wird beides nicht richtig lernen!)
P.S. "Wer nach allen Seiten offen ist, ist nicht ganz dicht."
From the acceptable use policy of Microsofts Anonymous Alcoholics^W^W academy alliance program:
Interesting. Who would still be running a telnet server? Everybody I know uses SSH. And if it's just for telnet, there are no benefits from graphics or sound drivers that might not be available for Linux. If I'd ever use XP on "thin clients", I'd use NX or XDMCP or VNC, but never telnet...
Also this explicitely only applies to XP, not to Vista?
I always liked pretending that nowadays, there are no driver issues with Linux (well, except for ATI and NVidia not releasing specifications, so for some of their product there are no good drivers available).
Well, thats not entirely true. Just these days, I've been running into some driver issues with my Intel hardware; and Intel recently has been the favourite of Linux developers for actually publishing driver source code under a free license.
Some details on the driver issues I had:
IPW3945 wireless with WPA on dual core. Apparently, there is some kind of race condition in the dual core setup under load, when two interrupts end up being handled by different CPUs. The WPA path probably is a bit slower, I read that theoretically it should also happen with WEP.
The effect is as this: when transferring data quickly, e.g. from a local machine on a WPA encrypted network (such as my parents wireless; basic WPA via the common AVM Fritz!Box), it will drop the connection every minute or so, and take another minute to reconnect. Obviously, that makes the wireless rather useless...
This is what the errors looked like:
TKIP: ICV error detected: STA=... N/A: Michael MIC verification failed for MSDU from ... keyidx=0 wifi0: MSDU decryption/MIC verification failed (SA=... keyidx=0) TKIP: received packet without ExtIV flag from ...
Upgrading to Kernel 2.6.20 turned these errors into something like Firmware bug detected; reconnect already was a bit faster. Upgrading the firmware past the Debian-packaged (in non-free) version to a newer one change them again (I think the ICV error remained) and made the reconnects even faster; still large transfers don't work reliably with WPA.
This is with a newer firmware and 2.6.20 connected to a Cisco AP, using enterprise WPA (i.e. EAP-TTLS):
ipw3945: Error sending LEDS_CMD: time out after 500ms. ipw3945: Microcode SW error detected. Restarting. ipw3945: Can't stop Rx DMA. ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels) CCMP: received packet without ExtIV flag from 00:03:52:e4:38:43
Another reason I upgraded to 2.6.20 was that the microphone didn't work on my Dell 640m. The upgrade helped here, I now can record from my microphone.
Every now and then, my system kind of freezes on resume; it seems that some interrupts (especially the keyboard interrupt) remain disabled...
I also tried the newer i810-modesetting driver, that should be able to handle the 1440x900 resolution without the aid of i915resolution (which basically overwrites part of the video BIOS to add the resolution to the supported resolutions list). The screen remained black (with both unstable and experimental versions of the driver). Another reason why I was trying this driver is that the current driver has like a default gamma 1.5 for XV, apparently - all XV using apps playback videos way too bright. Even if they don't have an XV gamma control.
Well, on the other hand, thats what Windows users might be exposed to every day. 99% of the time, everything works fine for me, too.
It just remains open whether 2.6.18 is actually the right kernel to use for the upcoming release... 2.6.20 improved on some of my issues. On the other hand, yaird failed to make a proper initrd for my computer, because CBC (cipher block chaining, a common choice if you encrypt your harddisk) became a module and wasn't added. There are just so many details to iron out when upgrading the kernel... that would pretty much mean an unfreeze, I guess. :-(
If we would release more often, that wouldn't be as essential, but for a release interval of two years, we really should have a kernel with few driver issues. And even if we're going to ship newer kernels with "dot releases" of etch, we'll have to avoid issues such as the CBC-module being unknown to yaird.
Many people assume that Linux is a system written by a few geeks.
Well, it's not just a few, as a recent statistic by LWN.net shows. It lists a mere 1961 developers being credited as authors of contributions to the Linux kernel over the last year.
So if some 2000 people have actually got contributions into the Linux kernel (which in turn can be cooperative work, and many changes have been rejected), you can safely assume that the development community looking at the Linux kernel source code is a lot larger.
Over 2000 developers. Thats quite some manpower, you know... and we're talking just kernel here. There are thousands of contributors to GNOME, KDE, Firefox, Openoffice.org, Gimp, ... and all the other, smaller opensource applications. The kernel is probably one of the opensource applications harderst to work with: you're working on the very guts of the operating system. Change something bad and your computer won't boot. It might lose some of your data etc. - if you are e.g. developing for firefox, the worst that can happen is pretty much that your browser crashes or you lose your bookmarks copy.
Also these 2000 aren't just your random geeks. Many of them are working for large companies such as IBM, Intel, Nokia, Oracle, HP, SGI, Broadcom, just to name a few of the big contributing companies who are not known as being a "pure Linux company". But they're working hand in hand across company borders and also with small developers. This is how Linux development happens: distributed, global, across borders: open and with free speech.
Auf der Suche nach einem rauchfreien Lokal für unseren Stammtisch, habe ich folgende Listen gefunden:
Muenchen.de Cafes, Muenchen.de Restaurants
Mein Blog hat (absichtlich) keine Kommentarfunktion. Wenn ihr Empfehlungen habt (insbesondere sollte es nicht zu "übertrieben elegant"/ elitär sein, gemnütlich und keinesfalls laut - wir wollen uns unterhalten können ohne nacher heiser zu sein...), schickt sie mir doch per Mail (erich AT debian DOT org) oder meldet sie bei den oben genannten Seiten.
Ich hoffe ja, dass das Gesetz wirklich gemacht wird (und nicht im letzten Moment zwecks Populismus alles nur wischiwaschi), und die Suche so bald erheblich einfacher wird... sonst sind halt weiterhin WG- und Wohnheim-Treffen die bevorzugte Lösung.
From Dojo Toolkit (a very powerful AJAX toolkit), but should probably go to The Daily WTF...
_getAdjustedDay: function(/*Date*/dateObj)
//summary: used to adjust date.getDay() values to the new values based on the current first day of the week value
var days = [0,1,2,3,4,5,6];
if(this.weekStartsOn>0){
for(var i=0;i<this.weekStartsOn;i++){
days.unshift(days.pop());
}
}
return days[dateObj.getDay()]; // Number: 0..6 where 0=Sunday
}
That code is inefficient and stupid on so many levels. For example the if
statement... you might be aware that 0 < 0 is false.Yep. I'd prefer something along the lines of
return (dateObj.getDay() - this.weekStartsOn) % 7;No arrays were abused during the making of this function.
I always thought PHP programmers were the worst, but apparently some JavaScript "coderz" are up to par.
I've been using Python to automate some tasks. A common thing with automation is to somehow notify yourself when it's completed.
Here's an elegant way to do that in Python (at least for GNOME users):
#!/usr/bin/python
import dbus
sesbus = dbus.SessionBus()
notify_obj = sesbus.get_object('org.freedesktop.Notifications',
'/org/freedesktop/Notifications')
notify_if = dbus.Interface(notify_obj, 'org.freedesktop.Notifications')
notify_if.Notify('HelloWorld',0,'','Summary','Body',[],{},-1)
For details, see pydoc dbus and the Notification Daemon API.
Dell is collecting customer wishes. It's interesting to see that all the top wishes are software related: starting with Linux preinstalled, OpenOffice, no AOL software preinstalled but a plain Vista only, Firefox as default browser or no software installed at all.
I'd strongly suggest Dell to consider bundling at least OpenOffice, Firefox, Inkscape, Gaim, Thunderbird, Gimp and some more of the great Opensource software available for Windows (remember: they're free - no extra cost, but some customers will be happy for having a good vector graphics program, or a free office suite...)
And I'd definitely like to see Dell offering a "no windows" option; I don't want to pay the Microsoft tax. An OS-less PC is fine for me, but it should be really cheap for Dell to get e.g. Ubuntu preinstalled.
A few days ago, at the main train station in Munich, subway level:

At least this series of payphones (there are different models with a touch screen in working height or with a camera) runs some form of Unix: they run WindowMaker which is only available for X11 as far as I know.
(I don't know if it's Linux or some BSD; and most likely the display component is a separate system from the actual phone. Note that some payphones at least in Berlin may also be equipped with a wireless access point running Linux, that could be even another system in the same payphone.)
Still it's amazing to see where Linux is today. Have a wireless router? Have a DSL modem (e.g. AVM Fritz)? Payphone? Bottle deposit machines (e.g. ALDI)? next generation of mobile phones? - Linux is just about everywhere where people are not exposed to the mouse. :-)
[Update: Daniel sent me an older picture of the phone display booting, it looks like being a SuSE. Funny (though not surprising) to see that the display is run non-rotated during boot (regular VGA), and when the driver is loaded it turns to the Portrait view.]
This post of ubuntu-tutorials.com (via Planet Ubuntu) suggests to run sshd on a different port than 22.
That does not increase security.
Serious attackers aren't fooled by just changing the port; if someone has an SSH remote exploit we're all in deep trouble anyway (but that code is heavily audited, you bet!), and it's trivial to scan on other ports if a system is detected as being Unix and not having SSH on port 22.
If you want to really increase security, you can
If your goal actually is to get rid of those annoying (but non-threatening, if you don't have trivial passwords) messages in your log files (you DO read your log files, don't you?) - consider using the iptables RECENT match to stop them early.
At the university, we have a RECENT match filter at the border firewall. It stops SSH scanners early on, giving them 5 tries total for the whole network (and they usually give up after that, not retrying when the recent match has expired).
For some details on how to use the RECENT match for filtering SSH connections, read this earlier blog post on iptables SSH protection. Use the INPUT chain to filter localhost.
For an example how to do a two-hop SSH connection, read this blog post. Just replace his OpenWRT router with a tighly secured SELinux gateway system. Another (without nc) is to use the LocalForward option of ssh. Just forward some local port through one ssh connection to the final machine, then do a second ssh connection over this. The gateway host could easily be restricted to only allow outgoing connections to port 22 in the fenced off network.
So basically, by NOT using a different port than 22 for SSH, you can increase security (by filtering port 22 specially, knowing that it's SSH). If you start putting your SSH daemons on different ports, you're actually making firewalling much harder.
Also note that in some networks, bandwidth policies are used for different ports. The SSH port usually is not limited; arbitrary ports are (since it might be a filesharing application using them). Another reason to stick to the standard ports, so you don't get punished by your network administrators!
... are pretty much unhandled in most applications, just like out of memory conditions. I wouldn't be surprised if some applications can also trash their data files when running into an OOM during writing.
Some bug squashing parties ago I was working on xchat bug #147832 (xchat: loses server list if disk fills up). I remember that xchat was pretty much nowhere handling out of diskspace, and it has several places where it would write files. There is a bug open on sourceforge about losing user commands the same way. (but the server list is probably written more often?)
Anyway, our applications, especially those written in C, are highly vulnerable to data loss if there is not enough diskspace left. We really need a library to write these files and pay attention to the error codes.
(This post was triggered by the diskspace issues of wiki.debian.org and a followup post by joey hess)
Seriously, RFC2445 is on crack. No wonder that few apps handle recurrence rules properly.
Let me give you some examples straight from the RFC:
RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1; BYDAY=SU;BYHOUR=8,9;BYMINUTE=30
These are tons of events: at 8:30 and 9:30 every other year, every sunday in january.
That's not precisely what I'd call a yearly frequency... I mean, we're talking about every sunday in januar. I'd more call that like... weekly.
And yes, this is the official solution:
"every Sunday in January at 8:30 AM and 9:30 AM, every other year"
Note that you can not do 8:30 AM and 9:00 AM. You could do 8:00 AM, 8:30 AM, 9:00 AM and 9:30 AM (using BYMINUTE=0,30). Pure crack.
Everyday in January, for 3 years:DTSTART;TZID=US-Eastern:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
or
RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1
Isn't that totally on crack? Using FREQ=YEARLY for everyday in january?
Notice how the semantics of "BYMONTH" change? In the first case, it's creating multiple events (BYMONTH=1,2 would name january and february independently); in the second case it's used to filter out individual days. Let me explain that a bit more:
FREQ=YEARLY;BYDAY=MO,WE means every Monday and Wednesday. See how the modifier makes about 104 recurrences out of a single year?
FREQ=HOURLY;BYDAY=MO,WE means every hour, but only on Monday or Wednesday. In this case, the modifier reduces the hourly events by throwing out all that are on other weekdays, reducing the number of recurrences.
Again, this is not my weird reading, but the RFC says:
BYxxx rule parts for a period of time which is the same or greater than the frequency generally reduce or limit the number of occurrences of the recurrence generated. [...] BYxxx rule parts for a period of time less than the frequency generally increase or expand the number of occurrences of the recurrence.
(Note that I didn't find any details on if they consider a week to be be "less" or "more" than a month, since there is no obvious subset relationship, but a week can overlap two months, and a month usually overlaps five weeks... So if I have FREQ=WEEKLY;BYMONTH=1;BYDAY=WE, is that Monday in every week overlapping January? Every week completely contained in January? If I'd want every Monday in January, I'd use FREQ=DAILY;BYMONTH=1;BYDAY=MO...)
Intersecting or joining two RRULE specifications is usually impossible (try to write one rule that is 8:00 and 9:30 every day for convincing yourself that a join won't work, and try to intersect FREQ=DAILY;INTERVAL=3 and FREQ=YEARLY;INTERVAL=2...)
Anyway, I'm truly not suprised that my mobile and probably many other applications don't handle recurring events completely (that is when importing from iCal they often just lose the repetitions).
My own implementation is doing okay. There are still a few missing features (BYSETPOS e.g. which can be used to say "the second to last tuesday or thursday each month"; should be trivial to add however, just picking the appropriate indexes out of a list), and some odd corner cases to dig in the specs and resolve (e.g. "every other week on friday, starting saturday march 3" - are we talking in business weeks, or intervals of 7 days here? When talking in weeks, is it friday in the week containing march 3, or following march 3, since that day itself is not a friday!)
Some of these details probably vary heavily from iCalendar-supporting application to another... e.g. FREQ=DAILY;BYHOUR=8;UNTIL=20070215T000000Z does this include a recurrence on 2007/02/15 at 8:00 (which is past the UNTIL time, however the hour of the UNTIL field is not used in presence of BYHOUR).
If you ever design a language for specifying recurrences, please:
Consider something like (intersect (repeat daily interval=3) (union (repeat weekly monday) (repeat monthly 1) ) )
(i.e. every 3 days, if they fall on the first of the month or on a monday)
Also spend some time thinking about alignment: "Every monday in a week containing the 15th of a month." - months and weeks are not aligned; assuming a week being defined as Monday-Sunday, this can be any day between the 9th and 15th of the month (in fact you could specify this in iCalendar, but it's probably easy to come up with an example that is too difficult to represent in iCalendar RRULEs, albeit trivial to calculate.)
Ihm zuehren soll in Berlin ein Gebäude nach ihm benannt werden: Die Merz-weg-Halle.
... suck.
The XML Schema "datetime" format can't be handled by Java's SimpleFormat (ok, that probably is more Javas fault, of not being able to handle hours:minutes in the timezone specification, anyway, this is mildy annoying).
The XSLT2 parsers are very intolerant about the format of the time specification, too. They could have made more stuff optional such as the specification of seconds; an error here will make the whole XSLT fail with an exception. Some compact form of error handling would be nice... as would be a smart parser which can handle various formats.
The XML Schema "duration" is even worse. First of all, it was completely forgotton when doing XSLT 2; there are no functions to format or disassemble it (except by regular expressions, which could also use a zero-width lookahead).
Secondly, it's lacking common specifications such as "next week". While "next week" is computationally equivalent to "in 7 days", it can have different semantics in some contexts (especially when not being aligned):
If I'm looking for the week February 9th 2007 is in, the result is February 5th two February 11th. If I'm looking at a 7 day interval containing this day, there are infinite possibilities (aligned on milliseconds and below...). So it does make sense to make a difference between 7 days and a week.
So far, DBus has two types of busses: the session and the system bus.
The session bus is used by most of your desktop applications.
The system bus is used e.g. by Hal signalling that new hardware was added, or by NetworkManager for network connectivity changes. The system bus is protected via a security policy.
Problems arise now when you need to locate your session DBus from a different session. For example, from a cron job.
There is a DBus application called "notification daemon" which can display popup baloons. This is useful for signaling yourself e.g. the completion of a long-running computation or just about anything you want. But it's using the session bus, so you can't reach it from outside of your current session.
A year ago, I wrote a hack for this, which will locate your current Gnome session, read the environment variable to find the session bus and then send a message to the sessions notification-daemon.
This is an ugly hack, however yesterday and today people asked on #dbus precisely how to do this. It seems to be a common question.
Maybe DBus should be extended by a "user" DBus, and applications such as music players or the notification daemon should actually listen on that bus (as well).
Maybe it could also be made possible to (securely) locate your session DBus via the system bus, I don't know how detailed the security policies of the system DBus are.
... is the working title of my diploma thesis.
Tomorrow I'll hold the introductory presentation on my topic in the research seminar. This is to explain my project to other members of the working group, so they can give me feedback and suggestions.
What I'll be doing:
Where I am:
Difficulties:
Fortunately, we have a rather strong research group here in Munich. There are experts for query and transformation languages (e.g. Xcerpt, SPEX - Querying XML Streams), temporal calculations (Computational Treatment of Temporal Notions, CTTN) and time modeling Calendar and Temporal Type System CaTTS); and I'm also working closely together with the author of IkeWiki and Xcerpt. And of course they're all nice people to work with!
Wie kann man so naiv sein wie die Politiker und offenbar manche Strafverfolger, dass "schwerkriminelle" nicht in der Lage wären, ihren Computer sicher zu halten?
Ich würde mal davon ausgehen dass jemand der wirklich etwas zu verbergen hat, auf ein sichereres System wie Linux setzt, wo der Trojaner eh nicht funktionieren wird. Das organisierte Verbrechen zeichnet sich nicht umbedingt durch Dummheit aus, ich denke man darf sie nicht mit Ottonormalverbrauchern verwechseln.
Deswegen böte der Einsatz des "Bundestrojaners" nur in seltenen Fällen einen Gewinn an "Sicherheit für den Bürger"; hingegen stellt er sehr leicht einen ungewünschten Eingriff in die Privatspähre da. Gegen "Systemkritiker" lässt er sich sicher öfter Einsetzen.
Ein weiterer Aspekt, der gerne ignoriert wird: Wenn der Trojaner so mächtig ist, so wäre es erst recht wichtig zu verhindern, dass er in falsche Hände gerät. Würde mich mal interessieren, wie der Wert des Bundestrojaners auf dem entsprechenden Schwarzmarkt ist... Eignet sich sicher auch gut zur Industriespionage, und damit kann man sicher viel Geld verdienen.
mp3val is a tiny command line utility (for Windows and Unix) that knows a lot about the MP3 format and is quite good at detecting and repairing common problems. Depending on the encoder and tagging tools you used, your MP3s might be more or less broken; sometimes it's just an incorrect length information (which might then cause incorrect playing time calculations). Mp3val can correct most of these errors.
Since mp3val operates on the MP3 frames and not on the decoded audio, it's fast; the operation is mostly I/O bound so it's probably as fast as your disk.
Anyway, mp3val is a command line utility, and I know that some people aren't too comfortable with command line tools. Here's a screenshot of the GUI:

As you can see, it's a three button application. Select the "Fix files" toggle if you want files to be repaired, then press "Add" (while the added files are processed, the "fix" button is greyed out). Then wait for the progress bar to finish.
The scrolling window below will print the warnings and errors emitted by mp3val. As you can see I have a few files with incorrect size information.
There are still some improvements that could be made. For example, the application could keep track of the "broken" files, so that they could be processed using mp3val in a second run without having to recheck all the "good" files. Brokenness-statistics and an sortable list view of the detected errors would also be interesting. But I consider none of these features to be important; I'll just let mp3val run over my collection and fix the files. It never trashed a file for me so far (but fixed some that didn't work), and I can still re-rip the songs when needed (but I'll choose Ogg Vorbis then as audio format).
The application is a tiny PyGTK script; that and mp3val is all you need. It should work on Windows, too, but I can't help you with that.
Another "Pymp of the day" - "Python mini project", done in just an hour. :-) Python and PyGTK are great for protoyping and mini applications. I love your work. Thank you!
[Update: mp3valgui is now on mp3val.sf.net and in CVS on sourceforge. Further development will happen there.]
Uwe Hermann asked about per-application proxy settings for GNOME apps.
I don't think this is currently supported in the UI; a majority of users won't want to have to configure the proxy for each application independently. That would suck even more.
I agree that it would be nice to be able to use different proxy settings for single apps. But from an UI perspective it somewhat sucks. I didn't check galeon gconf, only epiphany. There were no override settings for the proxy.
One thing you can definitely try is using about:config. Maybe you can even use a javascript:foo bookmarklet to change proxy settings; these probably won't be persistent.
On the long run, I suggest someone to work out a scheme on doing these overrides in gconf, and then providing patches for Epiphany and Galeon. I bet this has been on the radar for GNOME people, but just on a low priority.
My suggestion for such as scheme would be to use proxy profiles. If there is only one profile, the proxy settings dialog will be as it is right now; all applications default to the "Default" proxy settings. An "advanced" button in the dialog allows me to setup multiple proxy profiles (e.g. no proxy, proxy at work, privox+tor) and the UI in applications should consist solely of this profile chooser.
You might have read that several new DRMs were broken already. Given that cryptographers such as Bruce Schneier always said that DRM won't work the way it is supposed to be, unless taking all control over your computer away from you.
Crypto-Gram: the futility of digital copy prevention
Shortly after reports that the AACS copy protection scheme was broken, first HD-DVD movies started appearing on the net. I didn't verify that they aren't fake (my computer somehow doesn't play full HD resolution anyway: I couldn't playback the full quality version of the free movie Elephants Dream, and I don't want to download a dozen gigabytes either).
And now I read that the DRM system in Vista was also bypassed, allowing you to copy full quality protected media in Vista. (BoingBoing: Vista DRM cracked) "Vista launched this week, and it's already broken." - nice headline.