FOSDEM slides up
I gave a talk about Debian GNU/kFreeBSD at FOSDEM 2006. It tooks me time, but I finally have made the slides available.
I gave a talk about Debian GNU/kFreeBSD at FOSDEM 2006. It tooks me time, but I finally have made the slides available.
Yesterday I have setup a kfreebsd-amd64 (ie GNU/kFreeBSD on an amd64 CPU) build daemon. Its name is shockley.aurel32.net (all my machines are named related to electronics), and it has Sempron 2600+ CPU.
As you can see on the photo, it is still missing a decent case. There are actually two machines on the the photo, the motherboard in the case is maxwell's one (one of the kfreebsd-i386 build daemon), while the one on the top front is shockley's one. That's a bit strange, but the amd64 motherboard needs a power supply with a P4 connector, while the other one only needs a small power supply.
Thanks to Ingo Juergensmann, the kfreebsd-amd64 architecture is now listed on http://buildd.net. As you can see on the graph, this machine is very fast (it only runs for 24 hours!).
Thanks to Ingo Juergensmann, the kfreebsd-i386 architecture is now listed on http://buildd.net. That means that Debian developers can now easily check the state of their packages, and if they fail to build, to find why.
The requirement to appear on http://buildd.net was to use wanna-build and make its output available somewhere on the web. As I was still using a set of (very) ugly shells scripts to handle the build-daemon, I spent a part of the last days to setup wanna-build, and to understand how it works. With wanna-build a lot of thing is automatic, and almost everything could be controled via the mail interface. That would save me some time that I could invest in porting packages to GNU/kFreeBSD.
The machine on the photo below is currently somewhere between France and Switzerland. It runs Debian GNU/kFreeBSD, and will be accessible to all Debian developers. Thanks to Gürkan Sengün, the ETH Zürich will host it.
I am running a build daemon for the Debian GNU/kFreeBSD port. It was a bit overloaded by the high number of packages to build since the CXX ABI transition has begun. I decided to use the old mainboard of my main computer to upgrade it from an AMD K6-2 500 to an Athlon XP 1800+. I also had to buy a new box since the old mainboard was an AT one, whereas this mainboard is an ATX one. The hard disks (an old 8.4 GB IDE disk for the system and an old 4.3 GB SCSI disk for the build daemon stuff) are still a bit slow, that is probably the next thing I'll upgrade.
It runs for a few hours now and has already reduced the backlog. Currently 83% of the Debian packages are built for the kfreebsd-i386 architecture.
I have just upgraded my main computer with a new motherboard and a new CPU. It now has and Athlon 64 3000+ CPU, it is a lot faster than my old Athlon XP 1800+.
I have four SATA disks in a software RAID 5 array, and with my old mainboard the SATA controllers were on two PCI cards. The PCI bus was limiting the maximum transfer rate to about 60 MB/s. My new mainboard has an NForce 3 chipset, which has two SATA controllers connected directly to the HyperTransport bus, so that I can reach 158 MB/s. That's a great improvement!
I have a total of 5 hard-disks, 1 DVD-ROM drive and 1 DVD-RW drive resulting in a lot of cables and a big mess in the mini-tower box, as it could be seen on the photo below. Hopefully I now have less PCI cards as the soundcard, the SATA controllers and the ethernets controllers are now integrated on the mainboard.
Now that the hardware is setup, I'll have to look at the software, as my computer is still running in 32-bit mode.
Sam has got a laptop with a very strange keyboard. Have a look:
No, it's not a DVORAK one.
Actually he explained me he tried to convert the QWERTY keyboard into a DVORAK one, but some of the keys can not be swapped because of the trackpoint. And he is using it as a QWERTY keyboard.
I have got two hardware problems today.
First my UPS died, leaving my servers at home as well as my ADSL modem without any power. The bad thing is that I am not at home, but in Helsinki for Debconf 5, so I had to managed to get it replaced by simple wires, by phone. That was not that easy, because the person that did the changes (thanks a lot Dominique) hasn't my keys, and thus have to get it first.
The second problem I got today concerns my laptop. It seems the memory has not supported the flight to Helsinki, and I had to remove half of it :-(
As others I am very unhappy with the outcome of the release meeting. This "proposal" has been made by people that have key responsabilities in Debian, and without asking other people, except the DPL candidates. By the way, I feel silly that such persons sign this "proposal" as DPL candidates, whatever is their opinion.
In short the proposal says: "We've got problems to release with 11 architectures, let's drop 8 of them." A lot of users who choose Debian because it was the only distribution out of there to provide serious support for the architectures they care for, for various reasons. That's the end of the Universal OS, and that's sad.
It's seems that the actual teams found they are overloaded, so as they don't want to share their powers and call for help (even worse, they refuse help), they prefer to drop architectures.
The criteria given to keep architectures seems to have been choosen after the list of architectures itself. And actually none of the architectures in Debian fulfill them (all the four proposed architectures, i.e. i386, ppc, amd64 and ia64, only have one build daemon). And when you ask the technical point behind each criterion, nobody answers...
I don't say there isn't any problems, but there is a difference between a reasonable answer to these problems, and dropping most of architectures we support. If they are problems with build daemons, the solution is to solve them (hint: more build daemons and more admins would be a good start).
But actually I doubt the number of architectures is the real problem for Sarge. One of the main problems since August (at least that is what is announced in every "Bits from the release manager"), is the testing build daemons. Why it lasts so long? Why offers for help have been refused?
And don't forget the social contract: "Our priorities are our users and free software"
I have just uploaded a new version of simulpic. This software is a simulator for Microchip PIC16F84 microcontrollers. The initial version was a student project of the University of Pisa, and the development has stopped 8 years ago. Well, not really stopped as they were some patches in the Debian package.
Recently, a new upstream has decided to continue this project and to add some functionalities. He has just released a new version, the first one for more than 8 years! That demonstrates the power of Free Software.