No really. I have a Dell Latitude D600 with (what is labelled as) a Radeon 9000 Mobility, and although ATi's drivers *sort*of* work, inasmuch as having a completely mangled screen which just barely shows wdm's login prompt is working. Of course this is after a few re-boots trying to figure out exactly which kernel options they want in and out. And using *THEIR* X.Org configuration script, which is more confusing and only slightly more useful (only for ATi cards), which means nothing because the end result is worse than just SVGA.
Fortunately, between Linux 2.6 and X.Org I get DRM and OpenGL and all of that, so it's not a huge loss. But the performance (glxgears) on this card compared to a non-mobile R9000 is roughly 1/3rd. It renders nedit and aterm so I'm satisfied. I don't need to keep re-emerging the nVidia drivers with each kernel install either.
However, with or without the ATi drivers, xv output doesn't work at all on an external monitor (laptop screen works). Blank screen. I have to use vo=x11 in MPlayer to get any imagery, which means expensive software scaling and more broken frames. Somebody really messed something up there. Well let's be fair, in ATi's drivers it claims it HAS no xv support, so in that respect XOrg is doing much better (half support is better than none).
Still, I'd rather have a card that is supported in-tree in all my favorite operating systems (Linux and Net/Free/DFly BSD), than one I have to find and apply drivers to as is the case with nVidia. None of this would matter if I had an unusual architecture where hardware is well supported and relatively non-volatile. Mm. non-x86. *begins accepting donations*
This is FreeBSD. It's the second-least portable BSD (second only to DFly) and yet one of the most functional, depending on what you need. It was ahead of Linux with many features for a time and still has things it doesn't (e.g. clean tty snooping). You should try using systems before assuming they focus on the wrong things. Obscure hardware? FreeBSD has trouble running on some MAINSTREAM hardware, saying nothing of obscure.
...Are you sure you typed that all at once? It doesn't make logical sense.
Implementing kernel features in C++ requires ABI changes and extern"C" de-mangling and all kinds of hackish crap which would make the code and build processs messier, not cleaner. Writing some storage primitives to share around the kernel would (hopefully) clean it up instead.
BSDs are known for their cleanliness. While a fully C++ kernel could conceivably be good and clean, it adds little real value since the interface between kernel and userland can not be object oriented (it's not any real language - system call vectors bridge the gap between memory spaces and don't particularly care about language), and while inheritance might be just great for writing cleaner drivers or something, there hasn't been a significant need. And writing a brand new kernel from the ground up in this day and age would be way too much work - most projects these days are forks.
Read my post AND a reference before assuming I'm wrong. I did not say WPA used WEP. I said it used the same encryption algorithm, RC4 (called ARC4 in non-official implementations because of the license requirement).
AES is only in WPA2, which we were not talking about.
WPA uses the same algorithm as WEP, A/RC4, just it uses a more intelligently designed key distribution and regeneration system which makes up for a few of the algorithm's deficiencies. Since you probably don't believe me, "Data is encrypted using the RC4 stream cipher, with a 128-bit key and a 48-bit initialization vector (IV).".
I don't know where the misconception that WPA is based on AES came from. There was never any credible document to suggest it.
WPA still sucks compared to IPSec or OpenVPN, and I use the latter to make my wireless network (including Windows clients, which are very hard to support with IPSec) essentially a slow wired one, including strong encryption and authentication, and normalisation of out-of-order and replayed packets (the latter being particularly common for Wifi). This is especially good since OpenVPN doesn't care what your wireless device supports: your processor does the crypto itself. There's no need to buy new hardware because you want WPA, which some people actually do.
Power isn't everything. Not all users need to scale to 128 processors linearly. A lot of users need to install, run, update and manage their systems as a single robust unit that will always work, and not have to decide between a few thousand distributions and always feel they're missing out on something. In FreeBSD, you get all of the FreeBSD generation you chose: you don't have to think "oh, but distribution X has ACL support out of the box, and gcc 3.4..." because FreeBSD 5/6 have them as highly tested standards.
Some people want a powerful and consistent operating system, not just a powerful kernel. It's narrow minded to assume only hobbyists would want an easy-to-use and well documented system. This behavior is consistent with most Slashdot trolls.
Well, let's look at the big picture instead of the parts that interest you. FreeBSD is dropping 5.x because 6.x is of significantly higher quality, but their 'minimal surprise in incremental upgrades' policy requires a major version number change to accomodate the stable but new functionality. There is absolutely nothing wrong with this. It's a sign of positive growth and recovery from what some thought would be the death of FreeBSD (the less than impressive 5.3 release).
Companies use Linux because it's a market horse, not because it's the best technical option. Remember: corporations want money. If they can lose some uptime but gain a lot of PR and friendliness with developer communities, they'll do it. I can't believe people don't see this yet. It's capitalism, not technological idealism. Deal with it and move on. Linux does have its uses on extremely high-end machines where super scalability is needed, but DragonFly BSD will move in over it in due time.
BSDs are gaining journalling (DragonFly's work being particularly interesting and non-hackish), they all have SMP which is improving gradually (FBSD's system is becoming more fine grained, NetBSD will move to fine-grained locking in a major version or two, DragonFly is resolving the only remaining SMP-related issues and will thereafter receive more testing and acceptance, and I'm sure OpenBSD will move up later). If FreeBSD being one of the most present and reliable serving platforms noted by NetCraft itself is not a presence in corporate IT, what is? Are you telling me all of those sites are mom-n-pop stores that just happen to stay up for years and serve tremendous amounts of data? Not to say it compares with some of the things Linux is being used for these days: but it's definitely a presence it is unwise to ignore.
It helps to know what you're talking about rather than just to listen to what a few Slashdot posts and articles say. If you really believe that everything you read is objective and do no hands-on investigation, you run the risk of ignoring really good options and thinking your mediocre software is a golden fleece of IT. Linux is cool, it has its uses, but it's still nowhere near the universal kernel it aims to be, and its efforts to stabilise and clean up won't work out until the development model changes and the code quality standard is raised. The BSDs' academic nature and elitism may slow progress, but at least the progress (usually) goes solidly. I can't speak for some of the things that FreeBSD has done in recent years, but DragonFly BSD and NetBSD seem to be progressing really well where they want to go (not necessarily where you might want them to go).
All very valid points. I know there are some kernel-end security patches for Linux that give it some of OpenBSD's features, but I've had lousy luck keeping them running for more than a week, and they've usually been more for preventing local exploit than exploits in the kernel itself. I don't know if there are similar projects for a secure base-system userland though.
On a related note, DragonFly BSD is in the process of having its SMP bugs fixed, and afterwards will hopefully get wider testing on higher-end SMP systems. It's still only x86, but there are still numerous targets out there where it could be used in place of a Linux rig. And their devotion to security and good practices is impressive too: in my talks with devs via IRC, everything was about doing something cleanly, performantly, securely, and Rightly, not just getting it done fast to compete with somebody else.
OpenBSD is just code. A GNU/Linux distro is just code. Exploits happen in code. If you want to fix an exploit, you fix code. Exploits can be removed by fixing code. I KNOW OpenBSD is hardcore in security, but if you want a Linux distro to be secure, you can go through and audit all of its code. OpenBSD is not looked over by the Gods of security: it's still code. It has had exploits.
My point is that a lot of servers do NOT need perfect OpenBSD-like security, they need realistic security against any reasonable chance of attack. They DO need high performance and scalability, which OpenBSD does not yet provide (don't even argue: giant lock SMP). If I was running a low-end secure server, it'd be OpenBSD (or more likely Net or DFly). If I was running a 128-way SMP machine, it would pretty much have to be Linux or maybe Solaris. It's a tough world but there are horses for courses. And that's all I'm saying, so don't assume I'm flaming OpenBSD's security.
I may be mistaken, but larger institutions (e.g. a government datacenter) will be using hardcore SMP with terrifying amounts of RAM and disk space, and yet OpenBSD doesn't yet scale up that high. They're forced to use Linux just because it 1) is free AND 2) scales really well, at the same time. This is not a popular combination.
FreeBSD >=5 is meant to be able to compete, but I haven't heard many success stories personally. I imagine OpenBSD with its giant lock definitely wouldn't be able to compete in terms of SMP, and without a journalling file system, the super-reliability needs might not be met.
To be really honest though, most exploits against Linux do still happen in the userland (not that the kernel doesn't have its exploits: they're just usually fixed sooner and are harder to exploit), and there you can just port fixes from OpenBSD or find more clever ways of tightening every last bolt. So the security of a super-scalable Linux datacenter could be practically comparable to an OpenBSD machine, without losing the value of your hardware (which is easily up in the millions).
But DragonFly BSD is hoping to be suitable for super-scalable tasks without compromising security, and while it's not quite there yet (at least in that its only native port is x86), it should be soon enough. If corporations and governments don't consider BSD *then*, there's really something wrong.
Of course this is all just servers. For desktops (that still need healthy security) the BSDs are more than suitable, yet their use is mysteriously overlooked. But I suppose if there's a Linux distribution which does decent QA without remaining in the dark ages, it could be not-too-bad itself.
Yeah, probably. Thing is, when I first came to Gentoo, everything worked, and it's steadily been gaining more problems and fixing less of them ever since. But emerge wdm (x86 version) and TELL ME if you can log in without having to copy/etc/pam.d/xdm ro/etc/pam.d/wdm. I never could, even on a completely clean install with no hackery or funny business.
Portage is convenient and simple to use (even if very complicated under the hood), but my experience has been that a Gentoo system will often degenerate over time, especially if you're not super-careful about your upgrade procedure. FreeBSD with Ports seems to be much more tolerant and self-maintaining.
Typing from a Gentoo system, I can tell you that my XMMS randomly segfaults and my Firefox gives random xul errors if I even try to create a directory. This is only after a few weeks of the install existing. Before anyone can be clever about CFLAGS, I'm using -O -march=i686 -pipe, and a fully x86-marked tree.
BSDs don't have these problems unless you introduce them, but Gentoo seems to introduce them for you. In fact, some things are marked as tested even if they're known broken - wdm's PAM login script does not work at all, libusb does not create a symlink it should, and sometimes for no reason syslog-ng will reconfigure itself to show STATs every 10 minutes instead of hours. All of this in the tested branch.
Re:ICMP flaw #1 on Linux: it's in the kernel
on
Examining ICMP Flaws
·
· Score: 1
I'll try to be more useful than GP:
ICMP is almost completely necessary in the kernel because it is essential to proper operation of the TCP/IP stack (at least, when anything short of a perfect session comes along). Putting it in the userland will not save anyone from the exploits - these are not the kind of exploits that result in code execution (unless somebody *REALLY* messes up), they're just side effects of a near-sighted design. It seemed like a great idea to use the system from-boot clock to time TCP packets, until people realised this reveals your uptime and, if the system does not conform to the 1-per-second requirement, your clock granularity.
There is virtually nothing to gain from moving something as small (yet essential) as ICMP out of the kernel. I very much disapprove of the idea of putting a HTTP server in the kernel, and even an FTP proxy is really pushing it (Linux has both, and the BSDs laugh at this). However, there's no need to support micro-kernel designs by moving everything possible into userland. There are many theoretical reasons why this is the best thing possible, but then in practice it's not worth it.
In short: you won't gain anything moving it into userland, but you stand to lose because of the potential for increased latency or lossage in ICMP errors, which could fly in the face of standards or simply confuse/annoy clients. The security issues are resolved by running OpenBSD or being particularly skilfull with how you use pf (last time I checked, iptables' capabilities for packet manipulation weren't up to scratch).
1: This year is only half way through
2: Google hits do not indicate user base
3: ArsonSmith name only comes up with 7 pages worth of hits, clearly you have much less time left to live than Socrates who has countless. You think about it.
It's easier than that. Just compile a kernel with support for all hardware (as long as they don't conflict - which is rare enough not to matter) and leave it at that. Sure it might be a bit big, but heck most of these people come from Windows - IIRC the Win2k kernel was 50 megs WITHOUT additional drivers.
Some distros are VERY easy for newbies as far as the hardware goes. The trouble they have is adapting to the admittedly shoddy desktop environments. I have given lots of people lots of Linuxes to which they immediately respond "oh man this is so fast and pretty!", and in a few days "okay, this fucking shits me, I can't play more than one sound at once". While you can use arts or esd, do all programs and (especially) browser plugins support them? ALSA has done a very, very bad thing by not having software mixing, since hardware mixing is becoming a rarity with most users having on-board sound cards. By some remarkable coincidence most of the installs I have done for people have been on laptops, and the only sound card in laptops that I've ever seen ALSA mix on is the Maestro 3 (which does it in firmware, or something, but good enough).
But things like this *REALLY* set back newcomers who are used to everything working the same independently of hardware, and they will be much more interested in minor conveniences like this sound than in performance or stability. I had a person who just came from viruses, spyware, and crashes to the best Linux install I've ever done for someone say, "this shits me, Windows is better", all because of nags like XMMS/MPlayer not being able to get a lock on the sound device because the flash plugin in Firefox was activated by some advertising.
Of course this is all improving rapidly, with efforts for good Windows-style IPC and device abstraction (HAL+dbus being a flagship here), but at the moment it's too hard for some people. Drivers are hardly the issue any more.
Personally I don't have such problems (admittedly I have an SBLive and a solidly supported Radeon 9000) but the people for whom I do 'liberation' installs are often very ticked off, even if the environment is KDE or GNOME.
Unless you have some figures to prove otherwise, I've only seen BSD user groups swell even in this year. People coming from Windows/Mac seem to distribute mostly into Linux and, if not, into a BSD, which means that even though the proportion of people going to BSD is lower (for whatever reason - hardware/software support, lack of super-friendly magic interface to make life better, etc.), the numbers will still increase. And, if you look carefully, they are still increasing. Even with the popular 'exodus' from FreeBSD 5 to DragonFly or NetBSD.
Are you serious about this? I have never had problems with Linux drivers since I discovered you can configure your kernel (gives you in-tree drivers that automatically find and attach to all possible hardware without hassles or significant inconsistencies - try to say that about Windows) and package management that will download, compile and install the driver for you with a minimum of fuss (concept exists on Windows but almost never works, never for non-Microsoft drivers).
Firmware is another story, but for me that's only been for wireless devices, which I fortunately have been able to avoid using on Linux machines so far.
Shamefully you do have to do all of the X server stuff by hand where Windows does it for you (based on capabilities it reads from the drivers, and using the drivers, from your monitor), but this is a one-time thing which is still much more consistent and simple than all of the exotic and broken drivers under Windows. I don't know how it is on non-x86 but then most people don't use Windows on non-x86 either.
As a personal anecdote, I was asked to clean up a Toshiba laptop for a friend, and no matter how much I tried to install the CORRECT video driver, it simply refused to admit the card was even there (yes, the AGP bridge worked). I threw on a quick Gentoo I had brewed on another machine, added a couple of drivers to the kernel to make up for the difference, and on the first boot everything worked, including direct rendering for the card. When using xv output (e.g. in mplayer) it had blue lines in ungodly places, but switching to x11 and -zoom didn't hurt much either.
So while the setup phase was really simple and getting the card to work was clean and beautiful, the part of the driver that almost nobody seems to test (xv output..) was still flaky - workable but not pretty. I've seen similar issues using the XOrg native nv driver, which everyone already knows does not begin to compete with the official nvidia driver in terms of compatibility.
Honestly though, hardware support in Linux depends on two factors: whether you know what you're doing, and whether the particular Linux release has a working copy of that driver (a non-trivial caveat). But I have not found one single machine where installing Windows took LESS driver hunting and investigation than a decent Linux 2.6. Some exotic wireless devices are an exception but even they are showing up in portage or through ndis-wrapper.
What I heard from the developer responsible for the bug (crap, I have to start saving these links) is that it is too poorly specified, and this could lead to accidental implementation bugs. Besides that, the overcomplicated design opens avenues for errors and loopholes, including just having a weak auth system right next to your strong one that makes the latter rather useless. Since most admins won't know how to go about configuring a PAM rig, that's a Pretty Bad Thing.
OpenBSD does what Net did until 3.0: relatively monolithic password auth, with options for MD5, DES (legacy), Blowfish 2^7, etc. Although they don't bother with many of the fancy auth systems PAM has (e.g. auth with USB bar, run cryptsetup on login, etc.) the security is essentially flawless. And, since that is consistent with their primary goal, there is absolutely no reason to change at this point in time.
I wouldn't say it 'offers any alternatives', unless you were to install OpenPAM (which Free and NetBSD have now adopted) yourself and use that. The implementation is known to be secure and has been reviewed by the other projects.
Well, in an ATA topology, you can tell what your device will be named just by its position (e.g. primary master will always be hda), but with network devices where you can have virtual devices, busses on busses on busses on bridges on busses, and sometimes even arbitrary order (I have a motherboard where the PCI slots are enumerated in the opposite order to all others I've seen...), having more clues on which card is which is very helpful. In disks, who cares if it's the Maxtor or the Seagate? You should know by the capacity, and if not that, then the order you arranged them in your machine. But since there is much less consistency in the PCI world, all you have to go in is little bits of identification, almost all of which are stripped when you ifconfig (but fortunately some remains in kernel messages - if the driver is kind to you, which not many Linux network drivers are). Most distros will give you pciutils to investigate further. However, if you're not using modules,/proc/modules is useless, and/proc/bus/pci/devices isn't very handy either.
But all of this is relatively moot anyway: a competent admin will only be slowed by at most a minute by naming confusions (but they DO sometimes change later, for varying reasons), and there's also the chance of a BSD box having all PCI cards the same type (which is still better since virtual devices [fwe/fwip/etc..] are split out). The issue of/usr/local is much sillier still. These replies are much ado about nothing:)
Hard disks *do* it. A SCSI disk will be named differently to a loopback device which will be named differently to an ATA disk. Linux and BSD alike. The reason is that it's often very helpful to know what you can do with a device and what it is in your system given only its name.
If everything was hdX, and compiling an extra driver into your kernel changed the ordering (which does happen with Linux ethernet devices), you would be completely f'ed. You'd have to go grab a LiveCD and fix your bootloader and fstab and possibly other things in your rc scripts that deal with the drives directly.
Linux got one naming thing right: drives are named differently. But why they used letters instead of perfectly good numbers is beyond me. People might say 'omg what about bsd disk labels?!!1', that's to distinguish between the label and the partition (which is not possible in a purely numerical system - ad1s1e becoming ad1s11 is suddenly ambiguous).
Thanks, I knew I wasn't the only one that 'unlucky'. I once added eth1394 to a kernel config remotely and had to travel several kilometers to resolve the naming clash that arose because eth1394 decided to be eth0 (where in all previous cases it had been the last eth). Teaches me to keep backups of the last working kernel.
You can just say 'ifconfig' or watch the kernel messages. There is never a reason to look inside the machine. Even if a driver didn't claim the device, you can lspci.
Besides, the new FreeBSD 5 network stack (and now others?) can rename interfaces, so you can have your ethN if you want. But I much like the BSD naming system because I can select cards by their purpose (put the cards which require the least CPU use where they'd be used the most, for instance) and then write packet filter / etc scripts appropriately, without having to keep a mental list of interface names unless I actually end up with more than one of a kind of card.
In Linux, sometimes (not all the time, which is the worst part) eth1394 and other virtual drivers can allocate eth0 instead of a card, so injecting them into your kernel config means you lock yourself out of the system unless you know what to expect and hack ahead. Making it a module avoids this tragedy, but then that's just a hack-around. In FreeBSD there's fwe and fwip, neither of which coincide with existing interface names, and so injecting the new driver does not require *ANY* tweaking of your configs. Same for the others, of course, but Free is the only one which has *two* firewire networking drivers, as far as I know.
This is a Very Good Thing. Very, very good thing. And is very consistent with the 'graceful updating' philosophy the BSDs tend to stick to. An interface name change without a hardware change can be a real showstopper.
If there was one thing on my wish list, it would be for the BSDs to have consistent interface/driver names between each other - I dislike having to distinguish ex/xl, rtk/rl, etc. depending on where I am. It makes porting otherwise identical pf scripts more tedious than it needs to be, even IF it only requires changing the variables at the start.
The problem is that it is often used in places where something else would be much better, and the lesson is learnt at a cost. If a Linux setup is compromised (which happens all the time: most compromises over the net are actually Linux machines, look at any site that counts them) and a BSD in the same place wouldn't have been, an unecessary price was paid. If this is something significant (governments use Linux...) then the price is significant.
BSDs know what their code can and can't do: small dev teams who obsess over their own code night and day, and with decades of reputation and countless fanboys to continue to impress, all of it leads to knowing where the code is good to be used and not. While I doubt OpenBSD makes a super-convenient desktop system, it does make a hardcore fortress server. While you can (conceivably) hack and configure a Linux to be no less secure in practice, there's usually little point. Unless you *really* need the performance, for instance (and we'll see how DragonFly BSD takes up that challenge).
So really, it's about Linux being used TOO MUCH, in ways that can be harmful. It's not perfect, far from. Running everything everywhere doesn't necessarily mean it's the best way to go about it. BSD supporters usually DO have a horses-for-courses attitude (and have found courses that require BSD horses) and wish everyone else would too, instead of jumping on bangwagons or pushing politics into technology. Sometimes it's painful to watch.
Slashdot Mirror
No really. I have a Dell Latitude D600 with (what is labelled as) a Radeon 9000 Mobility, and although ATi's drivers *sort*of* work, inasmuch as having a completely mangled screen which just barely shows wdm's login prompt is working. Of course this is after a few re-boots trying to figure out exactly which kernel options they want in and out. And using *THEIR* X.Org configuration script, which is more confusing and only slightly more useful (only for ATi cards), which means nothing because the end result is worse than just SVGA.
Fortunately, between Linux 2.6 and X.Org I get DRM and OpenGL and all of that, so it's not a huge loss. But the performance (glxgears) on this card compared to a non-mobile R9000 is roughly 1/3rd. It renders nedit and aterm so I'm satisfied. I don't need to keep re-emerging the nVidia drivers with each kernel install either.
However, with or without the ATi drivers, xv output doesn't work at all on an external monitor (laptop screen works). Blank screen. I have to use vo=x11 in MPlayer to get any imagery, which means expensive software scaling and more broken frames. Somebody really messed something up there. Well let's be fair, in ATi's drivers it claims it HAS no xv support, so in that respect XOrg is doing much better (half support is better than none).
Still, I'd rather have a card that is supported in-tree in all my favorite operating systems (Linux and Net/Free/DFly BSD), than one I have to find and apply drivers to as is the case with nVidia. None of this would matter if I had an unusual architecture where hardware is well supported and relatively non-volatile. Mm. non-x86. *begins accepting donations*
This is FreeBSD. It's the second-least portable BSD (second only to DFly) and yet one of the most functional, depending on what you need. It was ahead of Linux with many features for a time and still has things it doesn't (e.g. clean tty snooping). You should try using systems before assuming they focus on the wrong things. Obscure hardware? FreeBSD has trouble running on some MAINSTREAM hardware, saying nothing of obscure.
...Are you sure you typed that all at once? It doesn't make logical sense.
Implementing kernel features in C++ requires ABI changes and extern"C" de-mangling and all kinds of hackish crap which would make the code and build processs messier, not cleaner. Writing some storage primitives to share around the kernel would (hopefully) clean it up instead.
BSDs are known for their cleanliness. While a fully C++ kernel could conceivably be good and clean, it adds little real value since the interface between kernel and userland can not be object oriented (it's not any real language - system call vectors bridge the gap between memory spaces and don't particularly care about language), and while inheritance might be just great for writing cleaner drivers or something, there hasn't been a significant need. And writing a brand new kernel from the ground up in this day and age would be way too much work - most projects these days are forks.
http://en.wikipedia.org/wiki/Wi-Fi_Protected_Acces s
Read my post AND a reference before assuming I'm wrong. I did not say WPA used WEP. I said it used the same encryption algorithm, RC4 (called ARC4 in non-official implementations because of the license requirement).
AES is only in WPA2, which we were not talking about.
"Get with it, moron."
WPA uses the same algorithm as WEP, A/RC4, just it uses a more intelligently designed key distribution and regeneration system which makes up for a few of the algorithm's deficiencies. Since you probably don't believe me, "Data is encrypted using the RC4 stream cipher, with a 128-bit key and a 48-bit initialization vector (IV).".
I don't know where the misconception that WPA is based on AES came from. There was never any credible document to suggest it.
WPA still sucks compared to IPSec or OpenVPN, and I use the latter to make my wireless network (including Windows clients, which are very hard to support with IPSec) essentially a slow wired one, including strong encryption and authentication, and normalisation of out-of-order and replayed packets (the latter being particularly common for Wifi). This is especially good since OpenVPN doesn't care what your wireless device supports: your processor does the crypto itself. There's no need to buy new hardware because you want WPA, which some people actually do.
Power isn't everything. Not all users need to scale to 128 processors linearly. A lot of users need to install, run, update and manage their systems as a single robust unit that will always work, and not have to decide between a few thousand distributions and always feel they're missing out on something. In FreeBSD, you get all of the FreeBSD generation you chose: you don't have to think "oh, but distribution X has ACL support out of the box, and gcc 3.4..." because FreeBSD 5/6 have them as highly tested standards.
Some people want a powerful and consistent operating system, not just a powerful kernel. It's narrow minded to assume only hobbyists would want an easy-to-use and well documented system. This behavior is consistent with most Slashdot trolls.
Well, let's look at the big picture instead of the parts that interest you. FreeBSD is dropping 5.x because 6.x is of significantly higher quality, but their 'minimal surprise in incremental upgrades' policy requires a major version number change to accomodate the stable but new functionality. There is absolutely nothing wrong with this. It's a sign of positive growth and recovery from what some thought would be the death of FreeBSD (the less than impressive 5.3 release).
Companies use Linux because it's a market horse, not because it's the best technical option. Remember: corporations want money. If they can lose some uptime but gain a lot of PR and friendliness with developer communities, they'll do it. I can't believe people don't see this yet. It's capitalism, not technological idealism. Deal with it and move on. Linux does have its uses on extremely high-end machines where super scalability is needed, but DragonFly BSD will move in over it in due time.
BSDs are gaining journalling (DragonFly's work being particularly interesting and non-hackish), they all have SMP which is improving gradually (FBSD's system is becoming more fine grained, NetBSD will move to fine-grained locking in a major version or two, DragonFly is resolving the only remaining SMP-related issues and will thereafter receive more testing and acceptance, and I'm sure OpenBSD will move up later). If FreeBSD being one of the most present and reliable serving platforms noted by NetCraft itself is not a presence in corporate IT, what is? Are you telling me all of those sites are mom-n-pop stores that just happen to stay up for years and serve tremendous amounts of data? Not to say it compares with some of the things Linux is being used for these days: but it's definitely a presence it is unwise to ignore.
It helps to know what you're talking about rather than just to listen to what a few Slashdot posts and articles say. If you really believe that everything you read is objective and do no hands-on investigation, you run the risk of ignoring really good options and thinking your mediocre software is a golden fleece of IT. Linux is cool, it has its uses, but it's still nowhere near the universal kernel it aims to be, and its efforts to stabilise and clean up won't work out until the development model changes and the code quality standard is raised. The BSDs' academic nature and elitism may slow progress, but at least the progress (usually) goes solidly. I can't speak for some of the things that FreeBSD has done in recent years, but DragonFly BSD and NetBSD seem to be progressing really well where they want to go (not necessarily where you might want them to go).
All very valid points. I know there are some kernel-end security patches for Linux that give it some of OpenBSD's features, but I've had lousy luck keeping them running for more than a week, and they've usually been more for preventing local exploit than exploits in the kernel itself. I don't know if there are similar projects for a secure base-system userland though.
On a related note, DragonFly BSD is in the process of having its SMP bugs fixed, and afterwards will hopefully get wider testing on higher-end SMP systems. It's still only x86, but there are still numerous targets out there where it could be used in place of a Linux rig. And their devotion to security and good practices is impressive too: in my talks with devs via IRC, everything was about doing something cleanly, performantly, securely, and Rightly, not just getting it done fast to compete with somebody else.
OpenBSD is just code. A GNU/Linux distro is just code. Exploits happen in code. If you want to fix an exploit, you fix code. Exploits can be removed by fixing code. I KNOW OpenBSD is hardcore in security, but if you want a Linux distro to be secure, you can go through and audit all of its code. OpenBSD is not looked over by the Gods of security: it's still code. It has had exploits.
My point is that a lot of servers do NOT need perfect OpenBSD-like security, they need realistic security against any reasonable chance of attack. They DO need high performance and scalability, which OpenBSD does not yet provide (don't even argue: giant lock SMP). If I was running a low-end secure server, it'd be OpenBSD (or more likely Net or DFly). If I was running a 128-way SMP machine, it would pretty much have to be Linux or maybe Solaris. It's a tough world but there are horses for courses. And that's all I'm saying, so don't assume I'm flaming OpenBSD's security.
Yes, because a post answering an off-topic post must be even more off-topic than the post it answers. I hate Slashdot moderators.
I may be mistaken, but larger institutions (e.g. a government datacenter) will be using hardcore SMP with terrifying amounts of RAM and disk space, and yet OpenBSD doesn't yet scale up that high. They're forced to use Linux just because it 1) is free AND 2) scales really well, at the same time. This is not a popular combination.
FreeBSD >=5 is meant to be able to compete, but I haven't heard many success stories personally. I imagine OpenBSD with its giant lock definitely wouldn't be able to compete in terms of SMP, and without a journalling file system, the super-reliability needs might not be met.
To be really honest though, most exploits against Linux do still happen in the userland (not that the kernel doesn't have its exploits: they're just usually fixed sooner and are harder to exploit), and there you can just port fixes from OpenBSD or find more clever ways of tightening every last bolt. So the security of a super-scalable Linux datacenter could be practically comparable to an OpenBSD machine, without losing the value of your hardware (which is easily up in the millions).
But DragonFly BSD is hoping to be suitable for super-scalable tasks without compromising security, and while it's not quite there yet (at least in that its only native port is x86), it should be soon enough. If corporations and governments don't consider BSD *then*, there's really something wrong.
Of course this is all just servers. For desktops (that still need healthy security) the BSDs are more than suitable, yet their use is mysteriously overlooked. But I suppose if there's a Linux distribution which does decent QA without remaining in the dark ages, it could be not-too-bad itself.
Mod parent up, first intelligent thing I've read on Slashdot ever
Yeah, probably. Thing is, when I first came to Gentoo, everything worked, and it's steadily been gaining more problems and fixing less of them ever since. But emerge wdm (x86 version) and TELL ME if you can log in without having to copy /etc/pam.d/xdm ro /etc/pam.d/wdm. I never could, even on a completely clean install with no hackery or funny business.
Portage is convenient and simple to use (even if very complicated under the hood), but my experience has been that a Gentoo system will often degenerate over time, especially if you're not super-careful about your upgrade procedure. FreeBSD with Ports seems to be much more tolerant and self-maintaining.
Typing from a Gentoo system, I can tell you that my XMMS randomly segfaults and my Firefox gives random xul errors if I even try to create a directory. This is only after a few weeks of the install existing. Before anyone can be clever about CFLAGS, I'm using -O -march=i686 -pipe, and a fully x86-marked tree.
BSDs don't have these problems unless you introduce them, but Gentoo seems to introduce them for you. In fact, some things are marked as tested even if they're known broken - wdm's PAM login script does not work at all, libusb does not create a symlink it should, and sometimes for no reason syslog-ng will reconfigure itself to show STATs every 10 minutes instead of hours. All of this in the tested branch.
I'll try to be more useful than GP:
ICMP is almost completely necessary in the kernel because it is essential to proper operation of the TCP/IP stack (at least, when anything short of a perfect session comes along). Putting it in the userland will not save anyone from the exploits - these are not the kind of exploits that result in code execution (unless somebody *REALLY* messes up), they're just side effects of a near-sighted design. It seemed like a great idea to use the system from-boot clock to time TCP packets, until people realised this reveals your uptime and, if the system does not conform to the 1-per-second requirement, your clock granularity.
There is virtually nothing to gain from moving something as small (yet essential) as ICMP out of the kernel. I very much disapprove of the idea of putting a HTTP server in the kernel, and even an FTP proxy is really pushing it (Linux has both, and the BSDs laugh at this). However, there's no need to support micro-kernel designs by moving everything possible into userland. There are many theoretical reasons why this is the best thing possible, but then in practice it's not worth it.
In short: you won't gain anything moving it into userland, but you stand to lose because of the potential for increased latency or lossage in ICMP errors, which could fly in the face of standards or simply confuse/annoy clients. The security issues are resolved by running OpenBSD or being particularly skilfull with how you use pf (last time I checked, iptables' capabilities for packet manipulation weren't up to scratch).
1: This year is only half way through
2: Google hits do not indicate user base
3: ArsonSmith name only comes up with 7 pages worth of hits, clearly you have much less time left to live than Socrates who has countless. You think about it.
It's easier than that. Just compile a kernel with support for all hardware (as long as they don't conflict - which is rare enough not to matter) and leave it at that. Sure it might be a bit big, but heck most of these people come from Windows - IIRC the Win2k kernel was 50 megs WITHOUT additional drivers.
Some distros are VERY easy for newbies as far as the hardware goes. The trouble they have is adapting to the admittedly shoddy desktop environments. I have given lots of people lots of Linuxes to which they immediately respond "oh man this is so fast and pretty!", and in a few days "okay, this fucking shits me, I can't play more than one sound at once". While you can use arts or esd, do all programs and (especially) browser plugins support them? ALSA has done a very, very bad thing by not having software mixing, since hardware mixing is becoming a rarity with most users having on-board sound cards. By some remarkable coincidence most of the installs I have done for people have been on laptops, and the only sound card in laptops that I've ever seen ALSA mix on is the Maestro 3 (which does it in firmware, or something, but good enough).
But things like this *REALLY* set back newcomers who are used to everything working the same independently of hardware, and they will be much more interested in minor conveniences like this sound than in performance or stability. I had a person who just came from viruses, spyware, and crashes to the best Linux install I've ever done for someone say, "this shits me, Windows is better", all because of nags like XMMS/MPlayer not being able to get a lock on the sound device because the flash plugin in Firefox was activated by some advertising.
Of course this is all improving rapidly, with efforts for good Windows-style IPC and device abstraction (HAL+dbus being a flagship here), but at the moment it's too hard for some people. Drivers are hardly the issue any more.
Personally I don't have such problems (admittedly I have an SBLive and a solidly supported Radeon 9000) but the people for whom I do 'liberation' installs are often very ticked off, even if the environment is KDE or GNOME.
Unless you have some figures to prove otherwise, I've only seen BSD user groups swell even in this year. People coming from Windows/Mac seem to distribute mostly into Linux and, if not, into a BSD, which means that even though the proportion of people going to BSD is lower (for whatever reason - hardware/software support, lack of super-friendly magic interface to make life better, etc.), the numbers will still increase. And, if you look carefully, they are still increasing. Even with the popular 'exodus' from FreeBSD 5 to DragonFly or NetBSD.
Are you serious about this? I have never had problems with Linux drivers since I discovered you can configure your kernel (gives you in-tree drivers that automatically find and attach to all possible hardware without hassles or significant inconsistencies - try to say that about Windows) and package management that will download, compile and install the driver for you with a minimum of fuss (concept exists on Windows but almost never works, never for non-Microsoft drivers).
Firmware is another story, but for me that's only been for wireless devices, which I fortunately have been able to avoid using on Linux machines so far.
Shamefully you do have to do all of the X server stuff by hand where Windows does it for you (based on capabilities it reads from the drivers, and using the drivers, from your monitor), but this is a one-time thing which is still much more consistent and simple than all of the exotic and broken drivers under Windows. I don't know how it is on non-x86 but then most people don't use Windows on non-x86 either.
As a personal anecdote, I was asked to clean up a Toshiba laptop for a friend, and no matter how much I tried to install the CORRECT video driver, it simply refused to admit the card was even there (yes, the AGP bridge worked). I threw on a quick Gentoo I had brewed on another machine, added a couple of drivers to the kernel to make up for the difference, and on the first boot everything worked, including direct rendering for the card. When using xv output (e.g. in mplayer) it had blue lines in ungodly places, but switching to x11 and -zoom didn't hurt much either.
So while the setup phase was really simple and getting the card to work was clean and beautiful, the part of the driver that almost nobody seems to test (xv output..) was still flaky - workable but not pretty. I've seen similar issues using the XOrg native nv driver, which everyone already knows does not begin to compete with the official nvidia driver in terms of compatibility.
Honestly though, hardware support in Linux depends on two factors: whether you know what you're doing, and whether the particular Linux release has a working copy of that driver (a non-trivial caveat). But I have not found one single machine where installing Windows took LESS driver hunting and investigation than a decent Linux 2.6. Some exotic wireless devices are an exception but even they are showing up in portage or through ndis-wrapper.
What I heard from the developer responsible for the bug (crap, I have to start saving these links) is that it is too poorly specified, and this could lead to accidental implementation bugs. Besides that, the overcomplicated design opens avenues for errors and loopholes, including just having a weak auth system right next to your strong one that makes the latter rather useless. Since most admins won't know how to go about configuring a PAM rig, that's a Pretty Bad Thing.
s g00213.html
OpenBSD does what Net did until 3.0: relatively monolithic password auth, with options for MD5, DES (legacy), Blowfish 2^7, etc. Although they don't bother with many of the fancy auth systems PAM has (e.g. auth with USB bar, run cryptsetup on login, etc.) the security is essentially flawless. And, since that is consistent with their primary goal, there is absolutely no reason to change at this point in time.
I wouldn't say it 'offers any alternatives', unless you were to install OpenPAM (which Free and NetBSD have now adopted) yourself and use that. The implementation is known to be secure and has been reviewed by the other projects.
Well, here's something: http://www.monkey.org/openbsd/archive/tech/0305/m
Well, in an ATA topology, you can tell what your device will be named just by its position (e.g. primary master will always be hda), but with network devices where you can have virtual devices, busses on busses on busses on bridges on busses, and sometimes even arbitrary order (I have a motherboard where the PCI slots are enumerated in the opposite order to all others I've seen...), having more clues on which card is which is very helpful. In disks, who cares if it's the Maxtor or the Seagate? You should know by the capacity, and if not that, then the order you arranged them in your machine. But since there is much less consistency in the PCI world, all you have to go in is little bits of identification, almost all of which are stripped when you ifconfig (but fortunately some remains in kernel messages - if the driver is kind to you, which not many Linux network drivers are). Most distros will give you pciutils to investigate further. However, if you're not using modules, /proc/modules is useless, and /proc/bus/pci/devices isn't very handy either.
/usr/local is much sillier still. These replies are much ado about nothing :)
But all of this is relatively moot anyway: a competent admin will only be slowed by at most a minute by naming confusions (but they DO sometimes change later, for varying reasons), and there's also the chance of a BSD box having all PCI cards the same type (which is still better since virtual devices [fwe/fwip/etc..] are split out). The issue of
Hard disks *do* it. A SCSI disk will be named differently to a loopback device which will be named differently to an ATA disk. Linux and BSD alike. The reason is that it's often very helpful to know what you can do with a device and what it is in your system given only its name.
If everything was hdX, and compiling an extra driver into your kernel changed the ordering (which does happen with Linux ethernet devices), you would be completely f'ed. You'd have to go grab a LiveCD and fix your bootloader and fstab and possibly other things in your rc scripts that deal with the drives directly.
Linux got one naming thing right: drives are named differently. But why they used letters instead of perfectly good numbers is beyond me. People might say 'omg what about bsd disk labels?!!1', that's to distinguish between the label and the partition (which is not possible in a purely numerical system - ad1s1e becoming ad1s11 is suddenly ambiguous).
Thanks, I knew I wasn't the only one that 'unlucky'. I once added eth1394 to a kernel config remotely and had to travel several kilometers to resolve the naming clash that arose because eth1394 decided to be eth0 (where in all previous cases it had been the last eth). Teaches me to keep backups of the last working kernel.
You can just say 'ifconfig' or watch the kernel messages. There is never a reason to look inside the machine. Even if a driver didn't claim the device, you can lspci.
Besides, the new FreeBSD 5 network stack (and now others?) can rename interfaces, so you can have your ethN if you want. But I much like the BSD naming system because I can select cards by their purpose (put the cards which require the least CPU use where they'd be used the most, for instance) and then write packet filter / etc scripts appropriately, without having to keep a mental list of interface names unless I actually end up with more than one of a kind of card.
In Linux, sometimes (not all the time, which is the worst part) eth1394 and other virtual drivers can allocate eth0 instead of a card, so injecting them into your kernel config means you lock yourself out of the system unless you know what to expect and hack ahead. Making it a module avoids this tragedy, but then that's just a hack-around. In FreeBSD there's fwe and fwip, neither of which coincide with existing interface names, and so injecting the new driver does not require *ANY* tweaking of your configs. Same for the others, of course, but Free is the only one which has *two* firewire networking drivers, as far as I know.
This is a Very Good Thing. Very, very good thing. And is very consistent with the 'graceful updating' philosophy the BSDs tend to stick to. An interface name change without a hardware change can be a real showstopper.
If there was one thing on my wish list, it would be for the BSDs to have consistent interface/driver names between each other - I dislike having to distinguish ex/xl, rtk/rl, etc. depending on where I am. It makes porting otherwise identical pf scripts more tedious than it needs to be, even IF it only requires changing the variables at the start.
The problem is that it is often used in places where something else would be much better, and the lesson is learnt at a cost. If a Linux setup is compromised (which happens all the time: most compromises over the net are actually Linux machines, look at any site that counts them) and a BSD in the same place wouldn't have been, an unecessary price was paid. If this is something significant (governments use Linux...) then the price is significant.
BSDs know what their code can and can't do: small dev teams who obsess over their own code night and day, and with decades of reputation and countless fanboys to continue to impress, all of it leads to knowing where the code is good to be used and not. While I doubt OpenBSD makes a super-convenient desktop system, it does make a hardcore fortress server. While you can (conceivably) hack and configure a Linux to be no less secure in practice, there's usually little point. Unless you *really* need the performance, for instance (and we'll see how DragonFly BSD takes up that challenge).
So really, it's about Linux being used TOO MUCH, in ways that can be harmful. It's not perfect, far from. Running everything everywhere doesn't necessarily mean it's the best way to go about it. BSD supporters usually DO have a horses-for-courses attitude (and have found courses that require BSD horses) and wish everyone else would too, instead of jumping on bangwagons or pushing politics into technology. Sometimes it's painful to watch.