| Danske bank fiasco |
[Mar. 26th, 2008|05:03 pm] |
Approximately one year ago danske bank swallowed the second-largest Finnish bank, Sampopankki. Last weekend, the perfectly fine working web-bank was flushed down the toilet and replaced with Danske Banks infrastructure. So far the results are quite horrific:
- People are reporting missing/too much money been shown in their accounts.
- Standard ssl/html based frontend has been replaced by a java applet. Worse, it needs a JNI library. Apparently to sniff your PC configuration. Surprisingly they provide a (ia32) Linux JNI lib as well. Compile once, run to the hills...
- The new webbank has security holes. url's that show a competing banks login prompt instead of sampo/danske bank are circulating on IRC. Apparently the danish website has the same bug too. The bank representative has (so far) refused to acknowledge there is a security hole.
A surprising number people have dismissed the whole issue as "IT business as usual, why complain?". Sure, we all *know* that most IT projects deliver late, fail to work until the first service pack, fail to import data properly from previous versions or simply fail completely. But is that something we should just accept as part of life? Even for banks that are (were) holding our money? |
|
|
| |
[Mar. 4th, 2008|11:41 pm] |
Texas Instruments (TI) joins Linux foundation. Congrats.
TI will help foster the growth of the Linux platform and collaborate with industry leaders who define both technical and operational best practices around open source software. .... TI will further ensure that its customers have the necessary tools to create innovative and differentiated Linux-based mobile devices that use the OMAP platform and DaVinci technology.
How about starting with
- Releasing the OMAPx TRM (Technical Reference Manuals) available to Linux community
- Documenting your DSPs and providing a OSS bios for them (compilable with a OSS toolchain)
- Release drivers for _all_ parts of OMAP chips, such as the AES accelerator, Jazelle java acceleration, powerVR 3d and so on.
If you continue providing documentation only for "high volume customers", your membership in Linux Foundation is a PR stunt at best. |
|
|
| And so it begins.. |
[Feb. 5th, 2008|12:42 pm] |
accepted: dpkg_1.14.16.6_armel.changes
AKA: ftp-master is now accepting armel packages
Thanks AJ!
current todo item: populating the archive cleanly |
|
|
| Where is debian/armel port |
[Nov. 2nd, 2007|11:18 pm] |
Sune asked where debian/armel is. Inspired by the blog, I posted a status update to debian-arm mailing list.
Other random updates
1) apt-get install recommends has now been enabled by default. This bites sbuild and pbuilder (#448562). In your buildd chroots set APT::Install-Recommends "false"; and be aware that you pbuilder build results might not be as pristine as we all have got used to..
2) I blame the rapidly growing kittens here for distracting me...
 |
|
|
| Debian armel status |
[Aug. 4th, 2007|01:17 pm] |
The debian armel port reached one milestone yesterday: Being able to run debootstrap from DD-signed, upto-date unmodified debian/unstable packages.
Looking backward:
* When watching the buildd's, the worst of Debian is visible. You don't spend much time wondering on successful builds. The time goes into wondering about the crappy code that fails to compile, the maintainers who ignore RC bugs for months, code with dead upstream..
* bootstrapping a Debian port is still painful. Fortunately Lennert did that for us this time.
* Most maintainers are very responsive, and are happy enough apply patches that help even unofficial ports. The few who ignore patches or are else effectively MIA can cause long delays...
* C++ code is evil. or at least the g++ implementation of it. A random game written in C++ can take 5h to build, when even the most complex C apps compile in 2-3 hours (with a few exceptions like glibc and linux-2.6). Worse, g++-4.2 seems to be another 10-20% slower than g++-4.1... Remember God kills a kitten every time you upload a c++ package unnecessarily!.
* Esoteric language bindings suck too.
Looking forward:
There is some 500 (out of 7100) packages that in Dep-Wait state due some missing packages on armel port:
* ~290 packages that would need FORTRAN (!). specifically the old g77 version...
* ~80 packages waiting for objective C / gnustep
* ~70 packages waiting for ghc6 or related Haskell code
* ~40 packages waiting for Java (being worked on)
* ~15 packages waiting for mono (patch in BTS)
* Then there usual crop of esoteric languages, packages failing to build with current unstable on any port, and packages build-depending on stuff removed or to-be-removed packages.
Effectively this means getting armel over 90% built of Debian needs either g77 to armel or getting Debian to migrate from g77 to gfortran (which is available but not throughly tested on armel). I'm working on the second route..
* Start building d-i images. So that Eddyp can have blazingly fast softfloat rrdtool on his nslu-2 without bugs and trouble.
* Request inclusion into Debian ftp archives. I think with the latest milestones, armel should be ready for archive as a "second class citizen". Inclusion for lenny needs still some work.
* Finally: there's tablets and phones waiting to for Debian armel mobile ;) |
|
|
| Official statement of the year |
[Jul. 12th, 2007|08:45 pm] |
UK military spokesman Major Mike Shearer said: "We can categorically state that we have not released man-eating badgers into the area."
Source: BBC |
|
|
| |
[Jun. 22nd, 2007|03:38 pm] |
Since the release team update got the arm architecture names mixed, chances are that others are confused as well.
* arm - This is the current in-Debian, little-endian hard-float old-abi port.
This is somewhat inefficent port, as the hard-float code needs to be emulated
in the kernel. It is also depreciated by upstream.
* armeb - This was a effort to create an big-endian old-abi port.
Since the Linksys NSLU-2 got it's Ethernet driver reverse engineered and thus it became possible to run little-endian Debian on it, interest on this port has been weak. If interest in bigendian arm returns, it will probably be re-ported using EABI and softfloat.
* armel - This the shining new little-endian EABI (and thus soft-float) based architecture.
THIS IS SPARTA^W THE FUTURE. |
|
|
| state of arm port |
[Jun. 8th, 2007|09:20 pm] |
All doom and gloom? far away from that.
The good:
* Arm port is now third most popular port according to popcon.
* This mostly thanks to the popularity of Linksys NSLU-2, a tiny 80€ computer able to run Debian. Do you have a old pentium sucking up electricity in your closet? Do a service to earth and replace it with a NSLU-2!
* Armel (Arm EABI) is now at "63.41% up-to-date. That's 4515 packages built out of 7121". See the fancy Graph for the progress. Catching up sid has been achieved with just two buildd's (Thecus N2100) in my apartment and Aurelien Jarno building selected packages. Plus of course pioneering work from Lennert Buytenhek and people who created EABI in upstream.
* All core packages except apt (which hasn't seen a upload to sid since etch) have now armel support in official Debian packages.
* the old arm port has started catching up in up-to-dateness again, now that all buildd's have a recent enough kernel for glibc 2.5 (2.6.12+)
The bad:
* We need someone to take responsibility on the toolchain for arm. Java is semi broken on arm, Fortran, Java and objc need work for armel.
* There is still communications problems. It took quite a while to find out why glibc 2.5 doesn't work on some buildd's.
* People have lost interest in Bigendian arm port after nslu-2 started working with the regular Little-Endian arm port. General consensus is that bigendian port would only matter for highend networking gear.
The future:
* More supported devices. Now we support NSLU-2, Thecus N2100 and a few related IOP based devices plus netwinders. Arm boasts their partners shipped 2450 Million units based Arm technology in 2006. Would you like to run Debian on your brand new scsi RAID card? mp3 player? Cellphone? Internet Tablet? Washing machine? Your choice!
* Better recovery options. Many arm devices are headless, and if it crashes or doesn't boot, figuring out what went wrong is tricky. This is not really arm specific, but comes up often enough in debian-arm list.
* Anti-bloat festival. Many arm devices have very little storage and RAM available. To run debian on these, we need to figure out who to get rid of extra FAT. Less bloated software is everyones advantage. |
|
|
| cdbs: empathic maybe |
[Nov. 18th, 2006|01:16 pm] |
I tried to ask our cats if they felt threatened by CDBS. They didn't seem really worried.
I'm not sure if it is entirely fair to blame CDBS for complex packaging issues. If CDBS was not available, more maintainers would just cook up their own spaghetti packaging scripts. The balance needs to be somewhere between "everyone reinventing the wheel" and "frameworks that are harder to use than the raw stuff". Currently I would recommend only using CDBS for simple packages. |
|
|
| Dear lazyweb.. |
[Jul. 25th, 2006|10:45 pm] |
Relatively simple task - given a pid, find out if it is in the same chroot as you. Until now we simply used the following code, which would error out if the given pid was not in chroot like us:
readlink /proc/$pid/root
All good things end up eventually, this time with the soon to come out 2.6.18 Linux kernel release. A recent commit changes the permissions of symlinks in /proc, (not only /proc/$pid/fd like it would seem from the commit message). Using ptrace as security policy is not a bad idea. If you can access the information via ptrace, hiding it from /proc made little sense. Which leads to the scary observation that one can ptrace any process with same UID outside your chroot sandbox. This is not a security bug, since one can escape chroot anyway. I just hadn't realized *HOW* easy it was.
Back to the topic, using /proc/$pid/root was not a standard or even documented interface, so I can hardly complain. I'm still left without a proper replacement:
So what AM I supposed to use? |
|
|
| about DPL.. |
[Apr. 11th, 2006|08:42 pm] |
|
AJ, my congrats too. Together with your other positions in Debian you have accumulated, I feel you really need watch for yourself - don't burn out! Delegation time, please. In less serious tone, prepare for the hardest task of your life: [Flash warning] Herding CATS</> :) |
|
|
| planet techsupport |
[Apr. 11th, 2006|08:06 pm] |
Ross, use
debuild --preserve-env
Now that we are aware of it, we might fix the default for the next release. Of course, if I guess correctly where you need scratchbox, you can't use a new version anyway anytime soon... Crappy Crap..
Speaking of new versions, Scratchbox 1.0.3 AKA Scratchbox Apophis (looks like our new developer is Stargåte fan..) is out. Most important change is:
* easier support for "foreign" toolchains and host binaries.
In older versions toolchains and other host had to be built with scratchbox's own HOST toolchain using a gar-based build system. While making your own toolchain using scratchboxes build system is really not hard, it seems to scare people away. With foreign toolchain support, you can for example take CodeSourcery's excellent prebuild Gcc 3.4 2005q3-2 arm EABI crosscompiling toolchain and just drop it in. OTOH copying, setting up the symlinks, support files etc is a bit tedious, so that particular example is available Prepackaged too ;) |
|
|
| lazyweb answers: gnokii |
[Mar. 8th, 2006|03:00 pm] |
Ross, What you want is SyncML (WBXML encoded) over OBEX over bluetooth. Complex? Acronym overload? yes. There exists rumours that with an unreleased $REVISIONCONTROL snapshot of opensync syncml plugin it is actually possible with free software.
However you can cheat and just use (nostalogia alert!) AT commands to retrieve and write phonebook entries. gnokii --getphonebook and --writephonebook work perfectly here. |
|
|
| Linux destroys evidence! |
[Feb. 16th, 2006|08:53 pm] |
Of all the evil things Linux does (promotes communism, is cancer, has higher TCO or destroys jobs, is unamerican..), A new horror has been found: Linux destroys evidence!.
In other news, we now know Linux is used even by Fortune 500 CEOs. |
|
|
| Allnet ALL6500: Next Debian/Arm porting machine? |
[Feb. 2nd, 2006|09:27 pm] |
Finding arm machines is not hard. In fact, everyone of you probably owns some of them. However, finding something suitable for Debian infrastructure usage is harder. For example Buildd load pattern requires not only a decent CPU, but above all good IO performance. Most ARM systems do not have a hard drive, and if they do like on personal media players like Archos pma400, the drives are slow and optimized to minimize power consumption.
Therefor, the logical place to look for machines would the NAS devices, like the already-being-Debianized Linksys nslu-2. NAS machines tend to (relatively) cheap, well available and need good IO performance. The main problem with NAS devices is the lack of RAM (to minimize costs they tend to have 32MB or something soldered to mainboard), so I was more than happy to spot a NAS with 256MB of ram:
| Linksys NSLU2 | Allnet ALL6500 |
|---|
| 266Mhz* ixp420 | 400/600Mhz IOP80219 |
| 32MB ram | 256MB ram |
| USB 2.0 | 2xSATA & USB 2.0 |
| 100Mbit ethernet | 2x 1000Mbit ethernet |
| 95€ | 350€ |
*overclocked
The real shocker came when reading "Manual englisch": (arrows by me) 
This bloody thing seems to have a DIMM socket!
GPL sources seem to be well available. Can someone from .de confirm if the memory is really there? (Why does so many cool hardware never end OEM'ed this north?) IOP80219 supports up to 1GB so it really seems quite promising :) |
|
|
| Weather.. |
[Jan. 19th, 2006|11:37 pm] |
...Suddenly I feel like a sissy remembering I thought in the morning that -20 Celsius we have here is bad. |
|
|
| You know you have seen to many personal flamewars when.. |
[Jan. 15th, 2006|10:36 pm] |
When you see
Subject: [mythtv] Problems with Bob Playback
And you wonder who is Bob Playback and what has he done.. |
|
|
| Debian developers on a google maps widget |
[Sep. 24th, 2005|01:34 am] |
And in less serious news, a small google maps hack (Requires fast CPU or LOTS of patience):
Debian developers around the world
This is from the data at http://www.debian.org/devel/developers.loc, which has the same thing rendered with xplanet. I have to wonder, if LDAP has more accurate cordinates, those seem a bit rounded. |
|
|
![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small}
nchip's journal
