Forgot your password?
typodupeerror
Debian BSD Linux

Debian Elevates KFreeBSD Port to First-Class Status 376

Posted by timothy
from the you-want-options-here-are-options dept.
Reader tail.man points out this press release from Debian which says that the port of the Debian system to the FreeBSD kernel will be given equal footing alongside Debian's several other release ports, starting with the release of Squeeze. Excerpting from this release: "The kFreeBSD architectures for the AMD64/Intel EM64T and i386 processor architectures are now release architectures. Severe bugs on these architectures will be considered release critical the same way as bugs on other architectures like armel or i386 are. If a particular package does not build or work properly on such an architecture this problem is considered release-critical. Debian's main motivation for the inclusion of the FreeBSD kernel into the official release process is the opportunity to offer to its users a broader choice of kernels and also include a kernel that provides features such as jails, the OpenBSD Packet Filter and support for NDIS drivers in the mainline kernel with full support."
This discussion has been archived. No new comments can be posted.

Debian Elevates KFreeBSD Port to First-Class Status

Comments Filter:
  • Re:OK (Score:3, Informative)

    by joe_bruin (266648) on Wednesday October 07, 2009 @04:22PM (#29674001) Homepage Journal

    But, does it run Linux?

    No, it's GNU/FreeBSD. It can, however, emulate Linux system calls and therefore natively run binaries compiled for Linux.

  • by nurb432 (527695) on Wednesday October 07, 2009 @04:35PM (#29674181) Homepage Journal

    So just take stock freebsd, rename pkg_add to apt-get and you are done :)

    Ok, im joking of course but you see the point im sure.

  • Re:Linux vs. FreeBSD (Score:4, Informative)

    by Bill, Shooter of Bul (629286) on Wednesday October 07, 2009 @04:36PM (#29674183) Journal
    That depends upon what you mean by veteran, and what you mean by UNIX. FreeBsd is closer to Unix due to its BSDness. So if you are used to kernels that are more Unix-y than Linux-y you may prefer it for that reason. If you are simply a fan of OSS that runs it as a desktop, there may not be any obvious advantages and perhaps some disadvantages due to lack of desktop like software. It should also include ZFS & dtrace which may entice you. Its also just a different kernel with a different schedule that may perform better for your specific tasks. Osnews carried a story about a benchmark between FreeBSD and Ubuntu [osnews.com] the comments from osnews readers are also pretty insightful which is why I linked to them and not the source article. .
  • Re:Awesome! But... (Score:1, Informative)

    by SafeMode (11547) on Wednesday October 07, 2009 @04:36PM (#29674191) Homepage

    and that's the problem with the terminology of calling Linux Linux and not Gnu/linux and the like. While being pedantic, it separates the fact that what people are familiar with in dealing with linux, has little to do with the kernel and mostly to do with the utilities and apps that run on top of it. With debian, you dont change the utilities and apps , so it's the same OS no matter what kernel you're using. The kernel just makes subtle changes in what those apps can do (and possibly let you run different apps that aren't compatible between kernels). Start thinking of "Linux" in the same light as we think "Unix". It's not an OS, but it's a superset of OS's. Distributions aren't simply repackaging an OS, they are different OS's. Some limited to just one kernel, some limited by the gui even. We need to stop visualizing them as all revisions of the same pseudo OS.

    So no, For the most part, i dont think linux users who use Debian Linux will find themselves in an alien environment with Debian kFreeBSD. And i dont think it would be a stepping stone to using FreeBSD. I think it just gives Debian users (which should be considered it's own OS) a different backend that may do certain things better than the more familiar Linux backend.

    With Debian crossing the kernel boundaries, i think the idea that the OS is the kernel will be even more obviously misguided. It's the Debian OS. It really can't be described as anything else. Debian refuses your limitations. Unless it has a non-free license.

  • Re:Linux vs. FreeBSD (Score:5, Informative)

    by Niten (201835) on Wednesday October 07, 2009 @04:37PM (#29674199)

    In my opinion, the biggest advantage of FreeBSD is how coherent the system is. Everything, from documentation to userspace utilities to the kernel, was developed and tested and released as a single project.

    This allows for neat features that require cooperation between several system components, which would be more difficult to implement in the Linux world. For instance, in FreeBSD you can press ^T while cp is copying some huge file, and this will send SIGINFO to cp, causing it to print a progress report to STDERR. Handy.

    So it seems to me that this Debian project defeats the most attractive feature of the FreeBSD operating system (by separating its kernel from its tightly integrated BSD userspace), while simultaneously casting aside Linux's advantages over FreeBSD (more drivers, more supported architectures, somewhat better performance, and--this may be controversial--in my experience, better stability). On the other hand, maybe Debian really can improve on the FreeBSD experience; apt rocks, and the Debian project does perhaps a better job than anyone of combining the disparate parts of the GNU/Linux ecosystem into a coherent operating system. So kneejerk reactions aside, I guess I shouldn't judge this until I have the chance to try it... still, I don't see myself trading in my Debian GNU/Linux anytime soon.

  • Re:Linux vs. FreeBSD (Score:2, Informative)

    by ground.zero.612 (1563557) on Wednesday October 07, 2009 @04:37PM (#29674203)

    As a UNIX/Linux veteran, I have to admit that I've almost no experience with FreeBSD. Could someone summarize why one might prefer it over Linux?

    FreeBSD is unix-like http://en.wikipedia.org/wiki/FreeBSD [wikipedia.org].

    You might prefer it over Linuxes for some of the same reasons you might prefer Apple's Mac OS X http://en.wikipedia.org/wiki/OS_X#History [wikipedia.org].

    Other than that, perhaps rock-solid stability, ZFS, or it's package management system (admittedly I don't use much Linux, but the pkg_add utility and the ports tree in fbsd are excellent). Oh and did I mention Linux binary compatibility?

  • Re:Linux vs. FreeBSD (Score:4, Informative)

    by XanC (644172) on Wednesday October 07, 2009 @04:42PM (#29674253)

    For instance, in FreeBSD you can press ^T while cp is copying some huge file, and this will send SIGINFO to cp, causing it to print a progress report to STDERR. Handy.

    Isn't this an internal feature of their cp implementation? I don't see what this has to do with the kernel, or indeed any program besides cp, at all.

  • Re:Cool (Score:5, Informative)

    by Timothy Brownawell (627747) <tbrownaw@prjek.net> on Wednesday October 07, 2009 @04:44PM (#29674297) Homepage Journal

    If your custom apps required you to install a package, it'll already be listed as manually installed, so it'll never be automatically uninstalled.

    The idea is that $app depends on $foo and $bar. But because $foo also depends on $bar, someone was able to goof up and only document that $app depends on $foo. So when $foo gets updated and drops its dependency on $bar, $bar goes away (due to being automatically installed) and $app stops working.

  • Re:Linux vs. FreeBSD (Score:5, Informative)

    by cbhacking (979169) <<moc.oohay> <ta> ... isiurc_tuo_neeb>> on Wednesday October 07, 2009 @04:51PM (#29674395) Homepage Journal

    A lot of wireless hardware still doesn't have drivers (at least, not working ones) on Linux (or FreeBSD). For obvious reasons, NT drivers do exist. FreeBSD's kernel supports directly loading those NT drivers. Linux has ndiswrapper, a project to allow the same thing (ndiswrapper itself is a Linux kernel module that attempts to load the NT driver binary) but the FreeBSD NDIS support is a feature of the kernel itself, and supported as such.

    For TL;DR folks: if you've ever had trouble making WiFi work in Linux, this might help.

  • Re:Cool (Score:5, Informative)

    by Chris Mattern (191822) on Wednesday October 07, 2009 @04:55PM (#29674455)

    If your custom apps required you to install a package, it'll already be listed as manually installed, so it'll never be automatically uninstalled.

    Not if the required package was already installed because a third package that required it and correctly specified it was installed. Uninstall that package, which seems to be utterly unrelated to your custom app, and BOOM, custom app breaks.

  • Re:OK (Score:2, Informative)

    by dazjorz (1312303) on Wednesday October 07, 2009 @04:55PM (#29674467) Homepage
    No, because in Debian GNU/kFreeBSD, as the name indicates, the userspace is GNU, not BSD. Therefore, GNU/FreeBSD. (in Debian GNU/kFreeBSD, the k stands for "kernel".)
  • Re:Cool (Score:3, Informative)

    by Chris Mattern (191822) on Wednesday October 07, 2009 @04:58PM (#29674507)

    That's a case for having apt on the test server, not the production server.

    Come to think of it, you'd have apt on the production server solely because you don't want it to look different from the test server, but you'd still never use it, instead simply copying the package changes from the test server.

  • Re:Cool (Score:3, Informative)

    by petermgreen (876956) <plugwashNO@SPAMp10link.net> on Wednesday October 07, 2009 @05:08PM (#29674653) Homepage

    Which is a good reason to either use apt-get which defaults to the sane behaviour of tracking packages it thinks are unused but not removing them until it's explicitly told to or reconfiguring aptitude to do the sane thing.

  • Re:Linux vs. FreeBSD (Score:5, Informative)

    by Sancho (17056) on Wednesday October 07, 2009 @05:17PM (#29674729) Homepage

    The grandparent was trying to make a point, but failed. Similar behavior exists throughout the FreeBSD userland--you can send SIGINFO with ctrl-t to many userland processes to get information on what they're doing. The point is that FreeBSD's kernel and userland were designed as a system, and little touches like this show that off.

  • Re:Awesome! But... (Score:3, Informative)

    by petermgreen (876956) <plugwashNO@SPAMp10link.net> on Wednesday October 07, 2009 @05:18PM (#29674739) Homepage

    One thing about so called "rc" bugs in debian is that they divide into a few categories.

    * Those that while technically qualifying for severity serious aren't actually bad enough for the release team to take any action.
    * Those in packages that the release team considers unimportant enough to kick out.
    * The real rc bugs, those that can't be allowed in the release but aren't in packages that can reasonably be kicked out either. These are a small minority of the so-called "rc" bugs but they are the ones that really hold up releases.

  • Re:Linux vs. FreeBSD (Score:5, Informative)

    by Guy Harris (3803) <guy@alum.mit.edu> on Wednesday October 07, 2009 @05:27PM (#29674833)

    For instance, in FreeBSD you can press ^T while cp is copying some huge file, and this will send SIGINFO to cp, causing it to print a progress report to STDERR. Handy.

    Isn't this an internal feature of their cp implementation?

    No. The fact that ^T sends SIGINFO, just as ^C sends SIGINT, is a feature of the "tty driver" (standard tty line discipline). The fact that a particular program catches SIGINFO and prints a progress report is a feature of the program.

    I don't see what this has to do with the kernel...

    The standard tty line discipline referred to above is in the kernel.

  • Re:What's Next ? (Score:2, Informative)

    by Knitebane (64590) on Wednesday October 07, 2009 @05:59PM (#29675159) Homepage
    Here you go....

    Nexenta [nexenta.org]

  • Re:Linux vs. FreeBSD (Score:5, Informative)

    by TheRaven64 (641858) on Wednesday October 07, 2009 @06:36PM (#29675517) Journal

    I would say mod parent up, but you're already at +5. This was what made me switch from Linux around 2002: Sound Works. I had a cheapy AC97 CODEC in my computer at the time. It didn't do hardware mixing. I installed Linux. There were two drivers, an OSS one and an ALSA one. Neither one let the majority of my programs play sound at the same time. For example, I couldn't have xmms playing music while I played BZFlag. Both KDE and GNOME came with their own sound daemon, which meant that either KDE programs could make sounds or GNOME programs could make sounds. Oh, and I think if I used the ALSA drivers then two programs that had had their sound output rewritten to use ALSA could play sounds at once... sometimes. Then I tried FreeBSD.

    In FreeBSD, there was one driver for the sound device. This was back in the 4.x days, so sound devices needed a little bit of extra configuration. I had to set the number of virtual channels and then tell each device to talk to a different one. I set up 4, one for GNOME, one for KDE, one for xmms and left the default one for whatever apps just wrote to /dev/dsp. I could have music playing, BZFlag sound effects in the game, and notification beeps when I got an email or IM. Then came FreeBSD 5 and all of that manual configuration went away. To play sound, a program opens /dev/dsp and writes audio data to it. That's it. No libraries to link against; it's all done via standard UNIX system calls (open(), read(), write(), and ioctl()). It's trivial to program for and it just works. With FreeBSD 8, you now get per-channel volume controls and a rewritten high-performance mixing algorithm, as well as support for all of the new OSS 4 APIs (backwards - binary - compatible with the old OSS 3 ones) if care about those things (i.e. if you are a programmer).

    A few other things that I like about FreeBSD:

    1. Documentation. The man pages and the handbook are written by people who seem to understand both English and the subject that they are writing about. They've also been translated into other languages, but I've only read the English ones.
    2. Sane and simple init system. RCng isn't as all-singing, all-dancing as something like Launchd, but it is sufficiently powerful and easy to understand.
    3. Interfaces don't change. Once you learn how to do something on FreeBSD, you know how to do it. Tools don't get arbitrarily replaced with ones that are in some way better but have completely different interfaces.
    4. Clear separation between FreeBSD and Other Stuff. Ports go in /usr/local/, everything else goes above that.
    5. Jails. If you want to isolate something, or you want a simple testing environment, jails are great. They are almost the same as chroot, except each jail has its own set of users. Root in a jail is not root outside the jail and so can create arbitrary other users inside the jail but can't escape. With FreeBSD 8, jails have virtualised network stacks and now work recursively, so root in a jail can create a new jail. They work especially well when combined with ZFS, because you can make an O(1) ZFS clone of a clean install of the base system to create new jails.
    6. ZFS. RAID without the write hole, per block checksums, top-to-bottom transaction support, O(1) snapshots and clones - what's not to like?
    7. Ports / packages. Not really anything special anymore, but nice and clean. Ports build from source and can have custom build options easily set. Packages are built from ports. Use them interchangeably.

    There are probably some things I've forgotten. I was going to say that the only thing I miss on FreeBSD was valgrind, but it turns out that Valgrind 3.5 has been in ports for a little while now and I just wasn't paying attention (so, obviously, I don't miss it that much).

  • Re:Cool (Score:2, Informative)

    by Anonymous Coward on Wednesday October 07, 2009 @06:39PM (#29675535)

    Sweet, I didn't know they added raid5/6 support to btrfs!

    ZFS also has triple parity ("RAID 7"?), as well as the ability to shim in SSDs transparently. There's also 'zfs send/recv'.

    How long, and how many petabytes of data has been in production on Btrfs?

  • by TheRaven64 (641858) on Wednesday October 07, 2009 @06:47PM (#29675605) Journal
    It's part of the name, and it makes sense. This is a GNU userland (importantly, a GNU libc) with a FreeBSD kernel. You probably can't run FreeBSD binaries on it, because they will expect different libraries. You can run any GNU programs that don't make system calls directly and you can run most GNU/Linux binaries with the Linux kernel ABI module loaded.
  • Re:Cool (Score:3, Informative)

    by Grishnakh (216268) on Wednesday October 07, 2009 @07:35PM (#29675945)

    You might want to read up on ZFS. It's not just a simple filesystem; it also includes LVM and RAID features, all in one. I'm not a professional sysadm, but my understanding is that, unlike Linux where changing a RAID5 array to have more disks or more space requires messing with the logical volumes using LVM, then messing with the RAID arrays with mdadm, then redoing the filesystems with the e[34]fstools, whereas doing this in ZFS just involves a few quick commands without having to unmount the filesystem.

    In fact, a quick Google search shows that resizing an ext3 partition is a bit of a pain, involving converting it to ext2 (removing the journal), running resize2fs, and converting it back. Obviously that's not good if the power cuts out while you're doing this. With ZFS, you should be able to resize arrays, add disks, etc., without even interrupting service.

    If btrfs can do this too, then it sounds great to me. I wish they'd pick a better name though.

  • by brunes69 (86786) <slashdot AT keirstead DOT org> on Wednesday October 07, 2009 @08:03PM (#29676139) Homepage

    Any sane admin has their own local apt repository, that they point all production and testing servers at. That repository has both "stable" and "testing" branches, like any apt server. All of the production servers grab off of the "stable", and all of the testing off of "testing".

    The trick is, this repository SHOULD NOT be a mirror of the actual debian repository. Rather, the "testing" of your internal server should be a mirror of the "stable" debian tree. Then, weekly or daily or whenever new debian "stable" packages come out, you update your testing boxes, and TEST the packages against your local software. If something breaks, no harm no foul - you wait till the next update.

    Once everything is tested OK, you sync those packages over to YOUR "stable" branch, and then that night all of your production servers will automatically get those updates. No fuss, no muss.

  • Re:Cool (Score:3, Informative)

    by domatic (1128127) on Wednesday October 07, 2009 @08:25PM (#29676255)

    There are more and less correct ways to go about running "non-stable" packages. Just jamming in a foreign binary deb and it's deps is generally the wrong way to do it. The right way to do it is to basically do what backports.org does....and check if backports has it first. If you're not running a Debian derivative then research the equivalent for your distro or BSD flavor:

    1. add an apt-src line from the "non-stable" distro. I've even done this when Ubuntu had the latest SpamAssassin and I wanted a late model debianized SpamAssassin. Note well I said "apt-src" and NOT an "apt" line. apt-get update, yadda yadda

    2. mkdir package-of-interest; cd package-of-interest; apt-get build-dep package-of-interest. If you're lucky this pulls in everything needed to build the package. If not you'll have to recurse with apt-get build-dep package-of-interest-newer-dependency; apt-get source package-of-interest-newer-dependency and come back to step 2 until you have everything you need to build your "non-stable" package.

    3. apt-get source package-of-interest (or -newer-dependency)

    4. cd package-of-interest-version; fakeroot dpkg-buildpackage -b. If all goes well a backport of the newer software that is built against your nice stable distro's libraries will be built one directory level up.

    5. If you had to build a newer library your package needs install it then go back to #2. rinse and repeat until you have your newer software. Myself, I'll build one or two before giving it up as a bad job. Generally I succeed at this. Bread and butter stuff like Clamav and SpamAssassin that is well behaved tends to work well with this procedure.

    The point of this is to avoid having to replace heeby jeeby inducing things like glibc, libstdc++, or even Perl since half your system scripts depend on such things. You avoid replacing packages that are contributing to the stability of the rest of the system and that are still getting critical bug and security updates. It keeps the "foreign" footprint to a middle and gives you a "foreign" package that is more or less compliant with the rest of the system.

  • Re:Cool (Score:2, Informative)

    by DragonDru (984185) on Wednesday October 07, 2009 @09:07PM (#29676467)
    ZFS is intended to prevent data corruption of *any* kind. Its use of double and shortly (now?) triple parity is just the start of it. One can also store up to 3 independent copies of the same data transparently. (One a mirrored array with two drives, this means 6 copies of the same file.)

    Having one system that provides the same interface and same capabilities across many sets of hardware is very handy.
    In action, ZFS is something to behold.
  • Re:Cool (Score:3, Informative)

    by X0563511 (793323) on Wednesday October 07, 2009 @11:42PM (#29677161) Homepage Journal

    This kind of thing does happen. I've reported a package that did so... we had a fix on the official repositories within days.

    Why this is considered a bad thing is beyond me. Debian on my server, other shinier toys on my desktop.

  • Re:Cool (Score:4, Informative)

    by X0563511 (793323) on Wednesday October 07, 2009 @11:44PM (#29677183) Homepage Journal

    You know about Debian-Volatile [debian.org] right? What's even better, is this is part of -stable and has been included in your default repository config since Lenny released.

    This is meant specifically for moving targets like ClamAV.

  • Re:Cool (Score:3, Informative)

    by drsmithy (35869) <drsmithy@@@gmail...com> on Thursday October 08, 2009 @05:25AM (#29678581)

    You might want to read up on ZFS. It's not just a simple filesystem; it also includes LVM and RAID features, all in one. I'm not a professional sysadm, but my understanding is that, unlike Linux where changing a RAID5 array to have more disks or more space requires messing with the logical volumes using LVM, then messing with the RAID arrays with mdadm, then redoing the filesystems with the e[34]fstools, whereas doing this in ZFS just involves a few quick commands without having to unmount the filesystem.

    ZFS can't resize arrays at all, so comparing it to the process in Linux isn't really relevant.

    ZFS's "volume management" is certainly easier than in any other OS, but it's real killer feature IMHO is the block checksumming.

    In fact, a quick Google search shows that resizing an ext3 partition is a bit of a pain, involving converting it to ext2 (removing the journal), running resize2fs, and converting it back. Obviously that's not good if the power cuts out while you're doing this. With ZFS, you should be able to resize arrays, add disks, etc., without even interrupting service.

    Whatever article you found is wrong. The process for growing a FS in Linux (with LVM and ext3) is (can be done online):
    Increase size of LV (lvresize)
    Increase size of FS (resize2fs)

    To shrink (needs to be done offline):
    Unmount FS, run e2fsck
    Shrink filesystem (eesize2fs)
    Shrink LV (lvresize)

    The process is straightforward and not difficult, though it *is* easier with ZFS.

  • Re:Cool (Score:3, Informative)

    by smoker2 (750216) on Thursday October 08, 2009 @06:49AM (#29678985) Homepage Journal

    I use ext2online [squarebox.co.uk] to resize my LVM based ext3 filesystem. To clarify, when I have added a new disk to the LVM [tldp.org] group, I use ext2online to extend the filesystem to cover the new disk. Also, I have never used lvresize. It's the same procedure as either lvreduce or lvextend. Here is my mini howto for adding a new disk to an LVM volume.

    adding a brand new disk to the lvm volume

    install the disk
    start system
    open terminal as root :

    check what disks (physical volumes)already exist as part of LV :
    pvscan

    run fdisk on the new drive :

    fdisk /dev/sdc # if this new disk is the 3rd sata or scsi disk in the system
                    # modify accordingly and use the same label throughout this # howto! (sdd, sde, sdf etc)

    create a new partition using the whole disk
    n
    p
    1
    when thats done enter the next command
    t
    partition will be 1
    hex code 8e

    write the partition table with
    w

    this exits fdisk

    then create a new physical volume on that disk
    pvcreate /dev/sdc

    then add the physical volume to the volume group

    vgextend my_movies_group /dev/sdc

    run pvscan again to check its in there

    then run vgdisplay and take a note of the allocated PE for the logical volume
    and for the free PE
    then add them together ! (this figure should already be showing in vgdisplay as Total PE )

    then run
    lvextend -l22222 /dev/my_movies_group/my_media /dev/sdc
        # where 22222 is the total you just calculated

    you can run vgdisplay -v again to check its been added ok

    lastly, run this, to resize the filesystem to cover the new drive

    ext2online /dev/my_movies_group/my_media

    That should be it !

  • Re:Cool (Score:3, Informative)

    by drsmithy (35869) <drsmithy@@@gmail...com> on Thursday October 08, 2009 @07:33AM (#29679211)
    Just for reference, if you're going to be using the whole device as a PV, there's no real need to create a partition on it - and in some cases it can be detrimental (eg: if it's a RAID device you will probably introduce partition alignment problems that will impact performance).
  • Re:Cool (Score:3, Informative)

    by Grishnakh (216268) on Thursday October 08, 2009 @02:42PM (#29684105)

    I'm no expert on this, but it sounds like you need to just start over: instead of adding new disks to your existing volume, just create an all-new volume and move everything from the old one to the new one, so you don't inherit any weird problems.

  • by evilviper (135110) on Thursday October 08, 2009 @04:13PM (#29685215) Journal

    So, here's the trick. FreeBSD only has one branch in ports, so even if you use an older -STABLE release branch of the FreeBSD core system you still get the newest releases of third-party applications via ports. That's why my *most* stable OS (FreeBSD) had caused me the most headaches lately, because it upgrades me to the newest Xorg *first*, not last like it should.

    Ummm. WHAT?

    Why are you installing all your software from the latest CVS snapshot of FreeBSD ports?

    You're supposed to use the RELEASE-tagged ports tree for your version of the OS (the tar.gz file on every FTP mirror server, everywhere). Then, install portaudit, and only when portaudit complains about security issues in a specific version of a specific port, should you CVS-UP that single port, and build the latest and greatest.

    Even if the package in question is dependant on 20 other packages, and 20 packages in-turn depend on it, it will work just fine.

    So I'll ask again, why do you think you need to CVS-UP the entire ports tree, and build all these new, presumably incompatible and/or buggy newer version of all the software you use?

Help me, I'm a prisoner in a Fortune cookie file!

Working...