Depenguinator "Upgrades" Linux to BSD
cperciva writes "Many systems around the world have been possessed by penguins and dead rats. It would be nice to exorcize these evil spirits, but this can be difficult without physical access to the machines in question.
Thanks to a new depenguinator, it is now possible to upgrade Linux systems to run FreeBSD 5.x without requiring anything more than an SSH connection." Clever idea.
Personally, I find this howto more useful. ;-)
HOWTO - Install Debian Onto a Remote Linux System
Trusted Computing FAQ | Free Dawit Isaak!
Use debootstrap. It will create a minimal install in any folder. Then chroot, and there you go, a small Debian system. Using that, you can either install Debian on another partition while running another distribution, or I suppose you also could replace your current install with Debian by booting into single user mode, and replacing your old system with Debian.
While you should be able to simply chroot into your new system and start adding stuff, I'd be a very good idea to boot it first. Debian will need to run some scripts on boot to finish configuring itself.
I'd go with the first option. The second one is too easy to screw up if you don't know what you're doing.
Well, I don't know of a tool, but how about HOWTO?
Have a good one. :)
"having to do a make world on 300 boxen"
/usr/obj (and /usr/src as well?) as nfs, mount it on your 300 boxen, and you only need to install the shiny new bsd with 'make installworld'. That's it. So it is actually quite easy to deploy on a large server farm. You would go the same way with the ports btw: build on one machine and have it make pakcages, than install the packages with pkg_add -r whatever on the rest of the machines. Neat. :)
Not any more, and 'make world' is being deprecated in favor of 'make buildworld'. The difference is, that 'make buildworld' is totally self contained. You do 'make buldworld' on one machine, export
In the FreeBSD Ports collection, there are many Ports marked as broken, and many more unmaintained and suffering from bit-rot.
Name any five that depend on each other and are important for real-world use? Ports suffers from both the desire to be large and from the fact that they're generally supported by one person. I've been running FreeBSD now for nearly 5 years and have only run into a broken port once, snmpd, which broke after a significant change in system variables, which in turn broke snmpd. It was fixed quickly, and since then every time I've built a port it's built.
How exactly is FreeBSD 5 a "dramatic step-up from ANY Linux distro"? FreeBSD releases are only supported for 12 months. Then you have to upgrade. In comparison, Debian supports its releases for at least two years, and RHEL offers a whopping FIVE years. That's right, five. This matters in real-world use.
You don't understand FreeBSD releases. There are point releases (eg, 5.2), -STABLE branches and -CURRENT branches. Most people track a -STABLE branch. Tracking a stable branch provides you with bug fixes and occasionally some new features backported from -CURRENT. Tracking -STABLE requires you to periodically rebuild the system from source, but this is FreeBSD's *advantage* -- it's a single, coherent system that can be easily and totally recompiled from up-to-date source code.
I've been running 4-STABLE now for almost 4 years and its still a supported (ie, active development and maintenance) branch of FreeBSD. The 2.2 and 3 STABLE branches are still there and I think 3 was still supported until the 5-STABLE branch was created.
Maintaining FreeBSD is easy if you track -STABLE and supported for years, and its often possible (albeit not necessarily recommnede) to upgrade from one major release to another -- I did it from 3.x to 4.x. In this manner (and not just point RELEASEs), FreeBSD revisions are suppported for years -- far longer than even most sane people would run a given revision of software.
I never did more chasing than I did trying to keep Dead Rat systems updated; either I used RPMs and prayed that the package author didn't decide to switch a bunch of compilation options, or a built packages from source, which meant I had to do my own porting. And then there was libc upgrades and all other manner of horror of trying to maintain an OS that was a kernel with a bunch of other stuff glued on without any coherency.
I'll grant some Linux distros have better turnkey desktop setups, and certainly greater corporate involvement (although ask yourself when "greater corporate involvement" and "better software" were part of the same sentence), and higher visibility.
But longer suppport, easier maintenance and reliability over the long haul? No way.
Interestingly, the k root name server has been running Debian Linux for a year or two now and has not had any "creak". It gets about 1500 queries/second per machine (the root server is distributed geographically via anycasting, and at each site by load balancing), and receives all manner of ill-formed packets.
Other root servers seem to run Linux (use nmap if you're curious), but I don't know the people running them so I can't be sure.
Now admittedly this is a very specific type of service: it's a single application that all fits into memory.
We're going to be moving www.ripe.net and whois.ripe.net from Solaris to Linux in 2004. The WWW server gets about 20 hits/second as you can see here, and the whois server gets around 28 hits/second as you can see here. These have more complex usage, with disk I/O, new process creation, and so on. I wouldn't let these services migrate if I thought they would be unstable.