X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/70f990418b5d050f8a4d6be7c0d6b6ed3ee5d90f..501bd177a6fa0393d7ec1c00fc39b0bc554ddfed:/blog/archive/2010/05/05.rss diff --git a/blog/archive/2010/05/05.rss b/blog/archive/2010/05/05.rss index 86d986f856..d87d1065d7 100644 --- a/blog/archive/2010/05/05.rss +++ b/blog/archive/2010/05/05.rss @@ -299,5 +299,166 @@ please contact us on debian-edu@lists.debian.org.</p> + + Magnetstripeinnhold i billetter fra Flytoget og Hurtigruten + http://people.skolelinux.org/pere/blog/Magnetstripeinnhold_i_billetter_fra_Flytoget_og_Hurtigruten.html + http://people.skolelinux.org/pere/blog/Magnetstripeinnhold_i_billetter_fra_Flytoget_og_Hurtigruten.html + Fri, 21 May 2010 16:00:00 +0200 + +<p>For en stund tilbake kjøpte jeg en magnetkortleser for å kunne +titte på hva som er skrevet inn på magnetstripene til ulike kort. Har +ikke hatt tid til å analysere mange kort så langt, men tenkte jeg +skulle dele innholdet på to kort med mine lesere.</p> + +<p>For noen dager siden tok jeg flyet til Harstad og Hurtigruten til +Bergen. Flytoget fra Oslo S til flyplassen ga meg en billett med +magnetstripe. Påtrykket finner jeg følgende informasjon:</p> + +<pre> +Flytoget Airport Express Train + +Fra - Til : Oslo Sentralstasjon +Kategori : Voksen +Pris : Nok 170,00 +Herav mva. 8,00% : NOK 12,59 +Betaling : Kontant +Til - Fra : Oslo Lufthavn +Utstedt: : 08.05.10 +Gyldig Fra-Til : 08.05.10-07.11.10 +Billetttype : Enkeltbillett + +102-1015-100508-48382-01-08 +</pre> + +<p>På selve magnetstripen er innholdet +<tt>;E?+900120011=23250996541068112619257138248441708433322932704083389389062603279671261502492655?</tt>. +Aner ikke hva innholdet representerer, og det er lite overlapp mellom +det jeg ser trykket på billetten og det jeg ser av tegn i +magnetstripen. Håper det betyr at de bruker kryptografiske metoder +for å gjøre det vanskelig å forfalske billetter.</p> + +<p>Den andre billetten er fra Hurtigruten, der jeg mistenker at +strekkoden på fronten er mer brukt enn magnetstripen (det var i hvert +fall den biten vi stakk inn i dørlåsen).</p> + +<p>Påtrykket forsiden er følgende:</p> + +<pre> +Romnummer 727 +Hurtigruten +Midnatsol +Reinholdtsen +Petter +Bookingno: SAX69 0742193 +Harstad-Bergen +Dep: 09.05.2010 Arr: 12.05.2010 +Lugar fra Risøyhamn +Kost: FRO=4 +</pre> + +<p>På selve magnetstripen er innholdet +<tt>;1316010007421930=00000000000000000000?+E?</tt>. Heller ikke her +ser jeg mye korrespondanse mellom påtrykk og magnetstripe.</p> + + + + + More flexible firmware handling in debian-installer + http://people.skolelinux.org/pere/blog/More_flexible_firmware_handling_in_debian_installer.html + http://people.skolelinux.org/pere/blog/More_flexible_firmware_handling_in_debian_installer.html + Sat, 22 May 2010 21:30:00 +0200 + +<p>After a long break from debian-installer development, I finally +found time today to return to the project. Having to spend less time +working dependency based boot in debian, as it is almost complete now, +definitely helped freeing some time.</p> + +<p>A while back, I ran into a problem while working on Debian Edu. We +include some firmware packages on the Debian Edu CDs, those needed to +get disk and network controllers working. Without having these +firmware packages available during installation, it is impossible to +install Debian Edu on the given machine, and because our target group +are non-technical people, asking them to provide firmware packages on +an external medium is a support pain. Initially, I expected it to be +enough to include the firmware packages on the CD to get +debian-installer to find and use them. This proved to be wrong. +Next, I hoped it was enough to symlink the relevant firmware packages +to some useful location on the CD (tried /cdrom/ and +/cdrom/firmware/). This also proved to not work, and at this point I +found time to look at the debian-installer code to figure out what was +going to work.</p> + +<p>The firmware loading code is in the hw-detect package, and a closer +look revealed that it would only look for firmware packages outside +the installation media, so the CD was never checked for firmware +packages. It would only check USB sticks, floppies and other +"external" media devices. Today I changed it to also look in the +/cdrom/firmware/ directory on the mounted CD or DVD, which should +solve the problem I ran into with Debian edu. I also changed it to +look in /firmware/, to make sure the installer also find firmware +provided in the initrd when booting the installer via PXE, to allow us +to provide the same feature in the PXE setup included in Debian +Edu.</p> + +<p>To make sure firmware deb packages with a license questions are not +activated without asking if the license is accepted, I extended +hw-detect to look for preinst scripts in the firmware packages, and +run these before activating the firmware during installation. The +license question is asked using debconf in the preinst, so this should +solve the issue for the firmware packages I have looked at so far.</p> + +<p>If you want to discuss the details of these features, please +contact us on debian-boot@lists.debian.org.</p> + + + + + Parallellized boot seem to hold up well in Debian/testing + http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html + http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html + Thu, 27 May 2010 23:55:00 +0200 + +<p>A few days ago, parallel booting was enabled in Debian/testing. +The feature seem to hold up pretty well, but three fairly serious +issues are known and should be solved: + +<p><ul> + +<li>The wicd package seen to +<a href="http://bugs.debian.org/508289">break NFS mounting</a> and +<a href="http://bugs.debian.org/581586">network setup</a> when +parallel booting is enabled. No idea why, but the wicd maintainer +seem to be on the case.</li> + +<li>The nvidia X driver seem to +<a href="http://bugs.debian.org/583312">have a race condition</a> +triggered more easily when parallel booting is in effect. The +maintainer is on the case.</li> + +<li>The sysv-rc package fail to properly enable dependency based boot +sequencing (the shutdown is broken) when old file-rc users +<a href="http://bugs.debian.org/575080">try to switch back</a> to +sysv-rc. One way to solve it would be for file-rc to create +/etc/init.d/.legacy-bootordering, and another is to try to make +sysv-rc more robust. Will investigate some more and probably upload a +workaround in sysv-rc to help those trying to move from file-rc to +sysv-rc get a working shutdown.</li> + +</ul></p> + +<p>All in all not many surprising issues, and all of them seem +solvable before Squeeze is released. In addition to these there are +some packages with bugs in their dependencies and run level settings, +which I expect will be fixed in a reasonable time span.</p> + +<p>If you report any problems with dependencies in init.d scripts to +the BTS, please usertag the report to get it to show up at +<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org">the +list of usertagged bugs related to this</a>.</p> + +<p>Update: Correct bug number to file-rc issue.</p> + + +