How exactly is OBSD more secure than an equivalently configured Linux system? Is the kernel harder? Is the OpenSSH version in OBSD any different than the same in most Linux distros?
Kernel: Has a lot in-tree and constantly tested, things that Linux only has in grsecurity/pax patches, which are not tested anywhere near as much as the mainline kernel and so often have bugs (personally I found hardened-sources in Gentoo to be a nightmare to keep up for long periods of time, causing everything from plain panics to not syncing a ReiserFS journal for hours). Everything, including drivers, are all reviewed for security and cleanliness constantly. The developer team is relatively small and dedicated so this is practical. Also, silly things (FTP proxy, etc.) don't make it in to the kernel like in Linux, instead being left in the userland. Although this can sometimes leave more administration and mess for admins, they will be thankful for the security and stability that usually result. Although to be completely perfectly absolutely fair, I haven't yet had problems with iptables' own FTP helper.
OpenSSH in OpenBSD is built right on the secure libraries it has, without the 'glue' that comes with other systems. The last (3.7?) OpenSSH to have a security exploit had it in a PAM auth feature which was not even possible on OpenBSD because it, well, doesn't have PAM, because PAM is insecure by design and many implementations. So OpenBSD wouldn't have been affected at all, yet many other systems were.
OpenBSD's gcc also has the usual patches for stack protection, which not many Linux distributions bother with. So it makes an effort to mitigate the damage of sloppy coding all around.
So although you CAN administer a Linux box to high levels of security, there is much less to worry about in OpenBSD, which has a much much higher emphasis on the code level of security, not just default configs. While the out-of-tree security enhancements for Linux can also tighten things and mitigate damage, the number of in-kernel exploits is significantly higher (and there isn't even an official ticker to keep users informed) so it's just not the same.
I think his point is that a developer should never be asking a question in a comment - it implies that developer communication (and often individual competence) is at a low ebb. I don't know about all of the BSDs, but I have had the pleasure of witnessing developer discussions in #dragonflybsd (on efnet) and they always come to conclusions on where things should be and how they should be done, and can tell you volumes about it if you aren't convinced (but often won't because their time is precious).
Although there are many dedicated Linux teams getting the work done, there are also many individual hackers submitting things, and many inexperienced ones who aren't sure if something should work the way they did it - so questions come up. A sensible developer would at least ask before implementing, or a sensible committer would think/ask before committing. If a question like "Does this belong here?" emerged in a release kernel, it means somewhere the development process broke down.
Personally I wouldn't drop the whole system just off a comment like that, though. It probably means his code review was restricted to comments and their interpretation rather than what the code did and how it was put together. Which, okay, was probably not great either, but it would have been fair to look at that as well. I'd love to be proven wrong though.
Unless his hardware had an nVidia video card and it was the small alley of time in which nVidia released drivers for Linux but not FreeBSD, there should have been no such situation. The BSDs aren't often behind unless a vendor is being difficult, and sometimes ahead (in-tree Intel PRO/Wireless drivers are in the BSDs already, yet Linux still uses Intel's drivers and not in its own tree). I don't know about Solaris.
But sometimes Linux is the only thing that WILL work out of the box. On a certain Toshiba Satellite (exact model unknown: I have no idea where my friend got this, but it's still interesting to tinker with) Linux (2.6.11-gentoo-r9 via a LiveCD) boots just fine with some notes about what evil, twisted things the BIOS has done to the system, while FreeBSD 5.4 locks up before even a screenful of kernel messages, and NetBSD 2.0 a little bit later with at least the in-kernel debugger. So Linux won that fight. It surprises the willies out of me, but sometimes Linux actually does have more stable hardware support than -stable/-release BSDs. Or maybe Toshiba just sent in a patch to cover up their shoddy manufacturing. Either way...
Well, to be fair, it did say 'most', and since 'most' are stuck on 2.4 and i386-centric userlands and kernels made with some old compiler, and tack on the extra daemons and tools and rubbish, yes, it's entirely reasonable to suggest FreeBSD 5 will be faster than those. It's worth remembering that Linux has more distros than there are atoms in the sun, and 'most' of them are a load of shit. I don't need a benchmark to tell me that, exploration and experience has enough of it.
He did not say, for instance, that a tricked-out Gentoo with 2.6.42-fast-r69 would still be slower, in fact it would probably be lightning fast. His sentence was flawed, in that it confused people on his message (or at least, the message you got is very different from the message I got).
Re:This is my experience with FreeBSD
on
FreeBSD 5.4 Review
·
· Score: 1
Oh, it can handle high loads, and Linux 2.0 or something might have crashed:)
But admittedly recent (>2.4) has been no worse than FreeBSD in scalability, and 2.6 has often proven to be much better. There are some issues on both sides, but Linux seems to be doing a much better job now - large development team, simpler models for things, numerous corporations doing testing and reviews... hard to imagine any problem staying in for too long.
And yet, eth1394 is still a heap of shit. Somebody fix that. Please.
Re:Declare your bias, why don't you?
on
OpenBSD 3.7 Reviewed
·
· Score: 2, Insightful
What makes you think it's a war? BSDs harmonize with other projects. While it's rare that anything is given back to the projects, it does happen - Darwin gave back to FreeBSD in a few places.
So I highly doubt a BSD would care if, say, Windows inherited its own OpenSSH-based SSH daemon (though it might need a different SSL library). I quote from Theo, "Their security is our security", and if Windows machines are given boosts to security capabilities, the whole world benefits. There's no point in starving other projects of good code: in fact, the open source spirit is about reducing redundancy where possible! And despite occasional technical inadequacies, the BSDs are much closer to this spirit than GNU/Linux (which has much less code sharing, and a license that makes it difficult to import its code).
But I'm expecting a lot of 'omgtrol!1!!' in response to this.
Reiser4 goes against the grain of nix-centric file systems by fragmenting like NTFS and FAT* do. I don't know what solution has been developed for this but it definitely means there's a shortcoming in the design.
I respect UFS for being very well balanced: it scales okay, it is reliable even after crashes (with SoftUpdates anyway), it performs well on most tasks even without clever journalling, and the lack of journal means it is suitable for even very small volumes (whereas ReiserFS seems to carry a universal 50 meg journal, making it useless for smaller media). It also happens to be supported very well in every BSD and to a lesser extent in Linux, with a limited Windows driver available. Although I'm all for journalling file systems, I don't recommend relying on them like Linux often seems to do (this is a problem on lower-end systems which need reliable storage but can't afford the overhead of journalling).
Anyway, you present the points of high level emulation, but it's not really as easy as that: if people run in to performance troubles they'll think the new OS sucks, especially if they're gamesr. But WINE has been remarkably successful at preserving performance, so maybe it's still possible. It's cleanliness that should matter here, and stability - but if MS was to re-wrap their own layer around a BSD base there shouldn't be a problem. Heck, some of their own subsystems started out as BSD copy-n-hack jobs.
But it'd have to be the other way around. FreeBSD-like kernel with PECOFF and some brutal surgery to support Windows-like paths (conceivably like how WINE does it, only better, because Wine is a nightmare) and process management concepts. NTFS and FAT* would no longer be useful at all, so you'd have to either use UFS2 or develop another FS. UFS2 has ACLs which I imagine could be used to replace NTFS' admittedly useful ACL system. Sub-FS encryption and compression are ideas with little use but are still possible to replace.
But it would certainly be interesting to see anyway. A real 'BSD for WIMPs' would really be a sight. But if it doesn't match the corporate hardware support of Windows (including the native ability to use Windows drivers - but NDISulator/ProjectEvil is Good Enough For Now) it won't be useful to anyone.
Re:So what's 5.4 like for 4.x users?
on
FreeBSD 5.4 Released
·
· Score: 2, Interesting
With minimal/no tinkering I could get a full Apache2+MySQL+mod_php rig up from pkgsrc in DragonFly BSD. X is another matter, but it's been done.
There are worse problems than that though. I recall having mysterious behavior (also seen on mailing lists) when trying to forward things to a local FTP proxy, which is the only way to have transparent FTP NATting with PF (and IPFW/natd just didn't work at all, but I might have just missed something: it's been years since I last used it). So it has some caveats as a gateway, but if you're willing to work around them it's a great system.
Personally I'm waiting until all of the other important work is done first, finally revealing the power of their SMP and VFS implementations and so on. We could either have a strong contender for Linux' position of "does everything fast enough without being too complicated", or a depressing failure (which is more likely to be from lack of software support than any developer issues: there's little point running DFly if the package manager issue isn't resolved).
It would break the backwards compatibility users expect when upgrading to 'the next Windows', which Microsoft have managed to maintain since DOS days with surprising success (and resulting bloat). The NT kernelification made DOS direct hardware access fail and some other performance hacks, but what can you do?
While I'd love to see a highly usable layer on top of a highly usable base system, I'd rather see more sensible software come out for Windows. I have begun to admit that Windows is still ahead in a lot of usability aspects, at least for desktops, and as long as you're a creative administrator you can work around its security and flexibility shortcomings. On servers, run BSD or Linux. No problem.
If Longhorn was FreeBSD + GUI it would be pretty awesome but, unless they pull of something really spectacular, would no longer be Windows-like and hence drive away a lot of customers. This is a bad thing for them. How MacOSX manages to be so backward compatible boggles the mind. Microsoft can't match that.
You're right, I can't believe I forgot about that. I keep assuming that the entropy is fed in and immediately treated with timings and IRQs and other hard-to-predict (especially over network) things.
I hate that I only have one machine with a hardware random number generator under my administrative control, and it currently runs Windows, so I can't even import the entropy over to more important machines. But then there's always the "roll your own user-space entropy harvester" option.
You missed the point. Here you only need to copy the image once and then all subsequent writes are done on both images at once (the on-disk and the network one). That means that everything after the initial copy (assuming you begin doing this on an existing fs) is as efficient and real-time as possible, requiring no polling for changes or any scheduling. It is essentially RAID1 over a network. Although it doesn't do much against system crashes (since neither side will have the final syncs and umount writes) it does work very well against hard disk crashes, and it is also good to know that the same data is on another machine - so you can just boot into that system and get your server up, without needing to migrate disks over or reconfigure some things. Well, I don't know how close usual RAID1 is to that.
RTFA: It responds to heavy load by making a log (journal?) of the blocks that need backing up, and then does them when the load is lesser. If you do it on swap, then you're insane and deserve whatever you get:)
This is a good idea, even if its niche is small, but I'm interested in how it handles the encryption. If it doesn't allow key re-generation on the fly, HMACs, certificates (or at least PSKs) and other things we expect from modern (SSH, IPSec/IKE, etc) systems then it's not going to be very useful. And unless I missed something it's going to be difficult to tunnel through a system that does do these things.
Personally I use SSH to tunnel everything possible, especially from Windows where IPSec is a joke, and the thought of sending all of my disk writes over a security system that is any less secure is a worry. Just imagine the problems if a man in the middle (or just a sniffer) catches plaintext: they know what you're doing, they know the contents of what you're doing, and highly likely they know what to do to exploit what you're doing. It's a very good thing that system entropy under nix is stored in the kernel, not on disk:)
Well, technically it does. Its goal is to be more like many Linux distros in terms of ease of install for newbies. That's its goal, and no other BSD bothers with that (and if you talk to the devs, they will all agree that it's useless effort diverted away from the real tasks for the real users that actually/need/ a BSD).
If they are just re-packaing FreeBSD's latest (-STABLE) -RELEASE with their own toolkit/installer and the latest packages, then they're doing a lot with a little effort and duplication, which is a Good Thing. I don't think anyone will see a reason to duplicate this effort like many Linux distros do of each other, since one such distro should be enough. Maybe, at worst, somebody will make a similar NetBSD re-distribution for multiple architectures (but why exactly a newbie would want to install on a toaster is questionable).
It would be much much worse if they forked the project and tried to revamp kernel code, or made graphical frontends for kernel configuration or something (YUK). They shouldn't seek to reduce the advantages *BSD has over Linux, usually saner configuration of kernel and (often) userland, but since I don't see that happening here it shouldn't be a problem.
But if I'm missing something about this project that IS a very bad thing, please somebody tell me and then I'll know. But right now it seems like a noob-friendly interface to a proven operating system base, without any unecessary duplication of effort or draining of developer resources. As in, the division of which project is responsible for the base and which is responsible for the interface is still there.
If you listen closely it's almost a complete rip of elements (and even some exact note combinations) from Dark Side. Pre-Dark Side was significantly different, its 'noodley' quality (quoting documentary) was much more drug-induced than DSOTM which, in my opinion, fit much better with existing music in terms of blending Jazz with progressive rock and the usual Floydian "random awesomeness generator".
There are some bits and pieces that sound like non-DSOTM but I could swear they're closer to tracks made after that album. That's just my view though, it's open to interpretation because it's played so badly it's not too easy to recognize.
"3.7 was a 70s, Pink Floydesque rock song - Puffathy"
It scares me how true this is. It's almost a complete PF remix, played worse. I see definite elements ripped right from Dark Side, and small bits of others... but it's so notable and clear it's disturbing.
A bit of a travesty, but meh, at least their taste in music to rip off is good.
Why would 'ordinary' (read: clueless) people want to use it anyway? It's for those who want cleanliness or die-hard security without resorting to patches or self-bondage. I have never heard of it targetting end user systems. Linux and Free/DFly BSD seem more for that kind of deal. NetBSD is edging up too.
Honestly, if you can't use it, you probably don't need it. People who need real security are probably in paying jobs and are certified for use in operating systems, not GUI configuration tools.
Well, pf's syntax is much more flexible, it has advanced features like packet normalisation ('scrubbing'), implicit antispoofing, packet filtering by OS fingerprint (which appears to be completely unique to pf), and is the first packet filter I know to log in pcap format which means you can watch with tcpdump and see the whole packet and analyse it. All of these are things that iptables could learn from and bring to a bigger audience. But it'd be better, at this stage, to just write a new filter entirely. Maybe I should look at that and make it my contribution to Linux.
Yeah, Linux happens to be a flagship of open source these days, fair enough. If that keeps it in open testing then it's a Good Thing.
Out of curiosity, what was the really awesome security framework Linux has OpenBSD can't touch? Or is it one of the out-of-tree jobs? I'm disappointed in Linus for not wanting to merge in grsecurity patches - the instability they cause is minimal (but I have had some..) and could be removed with some decent testing, but they bring Linux up to no less a level of proactive security than any given BSD. A code audit would finish the final few meters of distance. And since a LOT of people go to BSD just for security, that means they can stay with Linux and a sufficiently well-tested distribution.
Well I'm sure it will happen eventually. Before that I'd still want to see a new packet filter. While iptables is pretty functional and not at all difficult to use, it could benefit from some syntax flexibility. You might be able to get away with writing just a new frontend, or a wrapper for the existing one. But sometimes you can write a one-line rule in *pf* that takes a dozen lines in iptables, especially where groups of addresses and interfaces and so on exist. If it wasn't for the multiport match it would be a real nightmare.
You know what? You're absolutely right. To be honest, this IPSec thing (which I insist I am not doing wrong, since even with years of iptables experience I could not identify anything wrong with my script that could have affected this) is the only real bug I've had with Linux, which is much better than anything I can say about ANY BSD I've used. I'm a whingy bastard who just tries to level the playing field and give BSD a chance.
Although it would still be nice to have this worked out. In the meantime I've worked around HTTP and POP3 by tunneling them through SSH (so now they work great), and running AMSN on the gateway itself and only tunneling the X component. Good enough for now.
Truth is I run Linux on my gateway (largely for performance and software availabliliy) and the laptop I spend my whole life on, but sometimes little nagging issues in design are a bit too uncomfortable. I'll post some shit on some forums or Slashdot that will make me feel better and run a BSD for a few days then go back. Pathetic but what can you do? At least I'm not a sex crime offender. Trolling is a relatively harmless hobby.
Actually, smartass, I DID test it thoroughly, and (in 2.6.11, and continuing to 2.6.12-rc2 - no other kernels tried) it consistently fails to connect the MSN protocol (any client) and POP3, and some HTTP seems to behave badly but mostly okay. It IS a bug in Linux because none of the BSDs exhibit this, and it is also a bug that isn't fixed in 2.6.12-rc2 despite numerous changes to IPSec (and related) components.
When you show me a BSD exposing a significant security hole (like the Linux signal exploit) or breaking long-standing network functionality (IPSec, packet filtering, etc.), then I might consider them somewhere close to buggy, but flawed hardware support is nothing compared to the breakages Linux experiences.
A Linux advocate I know said, and I quote directly, "I've had some corker problems on GNU/Linux-based systems that can only be attributed to poor development and testing, and implementing the same thing on OpenBSD had no issues at all. First thing that comes to mind as indicative of the difference in quality between the GNU/Linux and BSD's, is PAM vs BSDAuth.."
Honestly, it's no mystery and nothing new at all. Linux does not get tested. Shit, are you even listening to kernel devs? They've decided NOT to do any quality assurance, leaving vendors up to the task of testing and bug fixing (hint: they don't do a good job either). Find THAT kind of philosophy in any BSD...
How is it a good reason? It will only affect you if you want to use the few parts of software under the license in another project or embedded system. It doesn't make any difference to your usage or the quality of the operating system itself. I sincerely hope you're just trolling because you can't seriously believe what you say.
Well, it all depends how much security you WANT, short of not having a system at all. You can systrace everything and have a crack team of trusted, indoctrinated people constantly watching all traffic and analysing it for signs of attempted intrusion or investigation. Or you can trust the software quality and 'general practice' recommendations even outlined in the BSD handbooks.
It's definitely a fun job though (one I wouldn't mind having), as long as the software is good. The BSDs are good in this regard, and so is Linux with the right patches and tools. But then sometimes a bug will come up nobody expected and it's all for naught:(
I don't think that's what he meant at all (with the right/privelege for code reading). The assumption ulib is making is that people are smart enough to be able to understand what is meant, and he obviously gave/. readers too much credit.
What is wrong with his list? All of those links work and are from who they claim to be: the graph of FreeBSD's server growth is from actual data, and only as old as 2004. Maybe you just can't read Netcraft's page properly. Or are trolling and hope nobody else will bother.
OpenBSD's OpenSSH really is the most prominent SSH daemon out there, NetBSD really did set internet land speed records (even if it's recently been beaten by Linux on more powerful hardware), etc. It's all out there and for you to say "none of them check out" is either blatant trolling or, as I prefer to see it, unbelievable stupidity. Up to you.
pkgsrc rocks very hard, but currently only 2000 (out of 5000+) ports compile on DragonFly BSD (identified by a few bulk build attempts). While hackery can work around this, for most users it spells limited installs. Even gtk2 isn't happening.
But I can confirm that it IS enough to get a web server with extras (php, mysql, etc.) up, although I did have an unexplained error at the end of mysql4-server's install. Nothing tragic.
This will definitely improve over time and effort, but right now it's not MUCH better than FreeBSD Ports + DFly Overrides. You would really only be inspired to use it if you already have a pkgsrc tree for other systems on your network and don't want redundancy.
pkgsrc is best on NetBSD where everything gets first-hand testing, and virtually nothing breaks. The situation is similar on (decent) Linux distributions - it is rumored some are entirely pkgsrc-based, even!
Slashdot Mirror
OpenSSH in OpenBSD is built right on the secure libraries it has, without the 'glue' that comes with other systems. The last (3.7?) OpenSSH to have a security exploit had it in a PAM auth feature which was not even possible on OpenBSD because it, well, doesn't have PAM, because PAM is insecure by design and many implementations. So OpenBSD wouldn't have been affected at all, yet many other systems were.
OpenBSD's gcc also has the usual patches for stack protection, which not many Linux distributions bother with. So it makes an effort to mitigate the damage of sloppy coding all around.
So although you CAN administer a Linux box to high levels of security, there is much less to worry about in OpenBSD, which has a much much higher emphasis on the code level of security, not just default configs. While the out-of-tree security enhancements for Linux can also tighten things and mitigate damage, the number of in-kernel exploits is significantly higher (and there isn't even an official ticker to keep users informed) so it's just not the same.
I think his point is that a developer should never be asking a question in a comment - it implies that developer communication (and often individual competence) is at a low ebb. I don't know about all of the BSDs, but I have had the pleasure of witnessing developer discussions in #dragonflybsd (on efnet) and they always come to conclusions on where things should be and how they should be done, and can tell you volumes about it if you aren't convinced (but often won't because their time is precious).
Although there are many dedicated Linux teams getting the work done, there are also many individual hackers submitting things, and many inexperienced ones who aren't sure if something should work the way they did it - so questions come up. A sensible developer would at least ask before implementing, or a sensible committer would think/ask before committing. If a question like "Does this belong here?" emerged in a release kernel, it means somewhere the development process broke down.
Personally I wouldn't drop the whole system just off a comment like that, though. It probably means his code review was restricted to comments and their interpretation rather than what the code did and how it was put together. Which, okay, was probably not great either, but it would have been fair to look at that as well. I'd love to be proven wrong though.
Unless his hardware had an nVidia video card and it was the small alley of time in which nVidia released drivers for Linux but not FreeBSD, there should have been no such situation. The BSDs aren't often behind unless a vendor is being difficult, and sometimes ahead (in-tree Intel PRO/Wireless drivers are in the BSDs already, yet Linux still uses Intel's drivers and not in its own tree). I don't know about Solaris.
But sometimes Linux is the only thing that WILL work out of the box. On a certain Toshiba Satellite (exact model unknown: I have no idea where my friend got this, but it's still interesting to tinker with) Linux (2.6.11-gentoo-r9 via a LiveCD) boots just fine with some notes about what evil, twisted things the BIOS has done to the system, while FreeBSD 5.4 locks up before even a screenful of kernel messages, and NetBSD 2.0 a little bit later with at least the in-kernel debugger. So Linux won that fight. It surprises the willies out of me, but sometimes Linux actually does have more stable hardware support than -stable/-release BSDs. Or maybe Toshiba just sent in a patch to cover up their shoddy manufacturing. Either way...
Well, to be fair, it did say 'most', and since 'most' are stuck on 2.4 and i386-centric userlands and kernels made with some old compiler, and tack on the extra daemons and tools and rubbish, yes, it's entirely reasonable to suggest FreeBSD 5 will be faster than those. It's worth remembering that Linux has more distros than there are atoms in the sun, and 'most' of them are a load of shit. I don't need a benchmark to tell me that, exploration and experience has enough of it.
He did not say, for instance, that a tricked-out Gentoo with 2.6.42-fast-r69 would still be slower, in fact it would probably be lightning fast. His sentence was flawed, in that it confused people on his message (or at least, the message you got is very different from the message I got).
Oh, it can handle high loads, and Linux 2.0 or something might have crashed :)
But admittedly recent (>2.4) has been no worse than FreeBSD in scalability, and 2.6 has often proven to be much better. There are some issues on both sides, but Linux seems to be doing a much better job now - large development team, simpler models for things, numerous corporations doing testing and reviews... hard to imagine any problem staying in for too long.
And yet, eth1394 is still a heap of shit. Somebody fix that. Please.
What makes you think it's a war? BSDs harmonize with other projects. While it's rare that anything is given back to the projects, it does happen - Darwin gave back to FreeBSD in a few places.
So I highly doubt a BSD would care if, say, Windows inherited its own OpenSSH-based SSH daemon (though it might need a different SSL library). I quote from Theo, "Their security is our security", and if Windows machines are given boosts to security capabilities, the whole world benefits. There's no point in starving other projects of good code: in fact, the open source spirit is about reducing redundancy where possible! And despite occasional technical inadequacies, the BSDs are much closer to this spirit than GNU/Linux (which has much less code sharing, and a license that makes it difficult to import its code).
But I'm expecting a lot of 'omgtrol!1!!' in response to this.
Reiser4 goes against the grain of nix-centric file systems by fragmenting like NTFS and FAT* do. I don't know what solution has been developed for this but it definitely means there's a shortcoming in the design.
I respect UFS for being very well balanced: it scales okay, it is reliable even after crashes (with SoftUpdates anyway), it performs well on most tasks even without clever journalling, and the lack of journal means it is suitable for even very small volumes (whereas ReiserFS seems to carry a universal 50 meg journal, making it useless for smaller media). It also happens to be supported very well in every BSD and to a lesser extent in Linux, with a limited Windows driver available. Although I'm all for journalling file systems, I don't recommend relying on them like Linux often seems to do (this is a problem on lower-end systems which need reliable storage but can't afford the overhead of journalling).
Anyway, you present the points of high level emulation, but it's not really as easy as that: if people run in to performance troubles they'll think the new OS sucks, especially if they're gamesr. But WINE has been remarkably successful at preserving performance, so maybe it's still possible. It's cleanliness that should matter here, and stability - but if MS was to re-wrap their own layer around a BSD base there shouldn't be a problem. Heck, some of their own subsystems started out as BSD copy-n-hack jobs.
But it'd have to be the other way around. FreeBSD-like kernel with PECOFF and some brutal surgery to support Windows-like paths (conceivably like how WINE does it, only better, because Wine is a nightmare) and process management concepts. NTFS and FAT* would no longer be useful at all, so you'd have to either use UFS2 or develop another FS. UFS2 has ACLs which I imagine could be used to replace NTFS' admittedly useful ACL system. Sub-FS encryption and compression are ideas with little use but are still possible to replace.
But it would certainly be interesting to see anyway. A real 'BSD for WIMPs' would really be a sight. But if it doesn't match the corporate hardware support of Windows (including the native ability to use Windows drivers - but NDISulator/ProjectEvil is Good Enough For Now) it won't be useful to anyone.
With minimal/no tinkering I could get a full Apache2+MySQL+mod_php rig up from pkgsrc in DragonFly BSD. X is another matter, but it's been done.
There are worse problems than that though. I recall having mysterious behavior (also seen on mailing lists) when trying to forward things to a local FTP proxy, which is the only way to have transparent FTP NATting with PF (and IPFW/natd just didn't work at all, but I might have just missed something: it's been years since I last used it). So it has some caveats as a gateway, but if you're willing to work around them it's a great system.
Personally I'm waiting until all of the other important work is done first, finally revealing the power of their SMP and VFS implementations and so on. We could either have a strong contender for Linux' position of "does everything fast enough without being too complicated", or a depressing failure (which is more likely to be from lack of software support than any developer issues: there's little point running DFly if the package manager issue isn't resolved).
It would break the backwards compatibility users expect when upgrading to 'the next Windows', which Microsoft have managed to maintain since DOS days with surprising success (and resulting bloat). The NT kernelification made DOS direct hardware access fail and some other performance hacks, but what can you do?
While I'd love to see a highly usable layer on top of a highly usable base system, I'd rather see more sensible software come out for Windows. I have begun to admit that Windows is still ahead in a lot of usability aspects, at least for desktops, and as long as you're a creative administrator you can work around its security and flexibility shortcomings. On servers, run BSD or Linux. No problem.
If Longhorn was FreeBSD + GUI it would be pretty awesome but, unless they pull of something really spectacular, would no longer be Windows-like and hence drive away a lot of customers. This is a bad thing for them. How MacOSX manages to be so backward compatible boggles the mind. Microsoft can't match that.
You're right, I can't believe I forgot about that. I keep assuming that the entropy is fed in and immediately treated with timings and IRQs and other hard-to-predict (especially over network) things.
I hate that I only have one machine with a hardware random number generator under my administrative control, and it currently runs Windows, so I can't even import the entropy over to more important machines. But then there's always the "roll your own user-space entropy harvester" option.
You missed the point. Here you only need to copy the image once and then all subsequent writes are done on both images at once (the on-disk and the network one). That means that everything after the initial copy (assuming you begin doing this on an existing fs) is as efficient and real-time as possible, requiring no polling for changes or any scheduling. It is essentially RAID1 over a network. Although it doesn't do much against system crashes (since neither side will have the final syncs and umount writes) it does work very well against hard disk crashes, and it is also good to know that the same data is on another machine - so you can just boot into that system and get your server up, without needing to migrate disks over or reconfigure some things. Well, I don't know how close usual RAID1 is to that.
RTFA: It responds to heavy load by making a log (journal?) of the blocks that need backing up, and then does them when the load is lesser. If you do it on swap, then you're insane and deserve whatever you get :)
:)
This is a good idea, even if its niche is small, but I'm interested in how it handles the encryption. If it doesn't allow key re-generation on the fly, HMACs, certificates (or at least PSKs) and other things we expect from modern (SSH, IPSec/IKE, etc) systems then it's not going to be very useful. And unless I missed something it's going to be difficult to tunnel through a system that does do these things.
Personally I use SSH to tunnel everything possible, especially from Windows where IPSec is a joke, and the thought of sending all of my disk writes over a security system that is any less secure is a worry. Just imagine the problems if a man in the middle (or just a sniffer) catches plaintext: they know what you're doing, they know the contents of what you're doing, and highly likely they know what to do to exploit what you're doing. It's a very good thing that system entropy under nix is stored in the kernel, not on disk
Well, technically it does. Its goal is to be more like many Linux distros in terms of ease of install for newbies. That's its goal, and no other BSD bothers with that (and if you talk to the devs, they will all agree that it's useless effort diverted away from the real tasks for the real users that actually /need/ a BSD).
If they are just re-packaing FreeBSD's latest (-STABLE) -RELEASE with their own toolkit/installer and the latest packages, then they're doing a lot with a little effort and duplication, which is a Good Thing. I don't think anyone will see a reason to duplicate this effort like many Linux distros do of each other, since one such distro should be enough. Maybe, at worst, somebody will make a similar NetBSD re-distribution for multiple architectures (but why exactly a newbie would want to install on a toaster is questionable).
It would be much much worse if they forked the project and tried to revamp kernel code, or made graphical frontends for kernel configuration or something (YUK). They shouldn't seek to reduce the advantages *BSD has over Linux, usually saner configuration of kernel and (often) userland, but since I don't see that happening here it shouldn't be a problem.
But if I'm missing something about this project that IS a very bad thing, please somebody tell me and then I'll know. But right now it seems like a noob-friendly interface to a proven operating system base, without any unecessary duplication of effort or draining of developer resources. As in, the division of which project is responsible for the base and which is responsible for the interface is still there.
If you listen closely it's almost a complete rip of elements (and even some exact note combinations) from Dark Side. Pre-Dark Side was significantly different, its 'noodley' quality (quoting documentary) was much more drug-induced than DSOTM which, in my opinion, fit much better with existing music in terms of blending Jazz with progressive rock and the usual Floydian "random awesomeness generator".
There are some bits and pieces that sound like non-DSOTM but I could swear they're closer to tracks made after that album. That's just my view though, it's open to interpretation because it's played so badly it's not too easy to recognize.
"3.7 was a 70s, Pink Floydesque rock song - Puffathy"
It scares me how true this is. It's almost a complete PF remix, played worse. I see definite elements ripped right from Dark Side, and small bits of others... but it's so notable and clear it's disturbing.
A bit of a travesty, but meh, at least their taste in music to rip off is good.
Why would 'ordinary' (read: clueless) people want to use it anyway? It's for those who want cleanliness or die-hard security without resorting to patches or self-bondage. I have never heard of it targetting end user systems. Linux and Free/DFly BSD seem more for that kind of deal. NetBSD is edging up too.
Honestly, if you can't use it, you probably don't need it. People who need real security are probably in paying jobs and are certified for use in operating systems, not GUI configuration tools.
Well, pf's syntax is much more flexible, it has advanced features like packet normalisation ('scrubbing'), implicit antispoofing, packet filtering by OS fingerprint (which appears to be completely unique to pf), and is the first packet filter I know to log in pcap format which means you can watch with tcpdump and see the whole packet and analyse it. All of these are things that iptables could learn from and bring to a bigger audience. But it'd be better, at this stage, to just write a new filter entirely. Maybe I should look at that and make it my contribution to Linux.
Yeah, Linux happens to be a flagship of open source these days, fair enough. If that keeps it in open testing then it's a Good Thing.
Out of curiosity, what was the really awesome security framework Linux has OpenBSD can't touch? Or is it one of the out-of-tree jobs? I'm disappointed in Linus for not wanting to merge in grsecurity patches - the instability they cause is minimal (but I have had some..) and could be removed with some decent testing, but they bring Linux up to no less a level of proactive security than any given BSD. A code audit would finish the final few meters of distance. And since a LOT of people go to BSD just for security, that means they can stay with Linux and a sufficiently well-tested distribution.
Well I'm sure it will happen eventually. Before that I'd still want to see a new packet filter. While iptables is pretty functional and not at all difficult to use, it could benefit from some syntax flexibility. You might be able to get away with writing just a new frontend, or a wrapper for the existing one. But sometimes you can write a one-line rule in *pf* that takes a dozen lines in iptables, especially where groups of addresses and interfaces and so on exist. If it wasn't for the multiport match it would be a real nightmare.
You know what? You're absolutely right. To be honest, this IPSec thing (which I insist I am not doing wrong, since even with years of iptables experience I could not identify anything wrong with my script that could have affected this) is the only real bug I've had with Linux, which is much better than anything I can say about ANY BSD I've used. I'm a whingy bastard who just tries to level the playing field and give BSD a chance.
Although it would still be nice to have this worked out. In the meantime I've worked around HTTP and POP3 by tunneling them through SSH (so now they work great), and running AMSN on the gateway itself and only tunneling the X component. Good enough for now.
Truth is I run Linux on my gateway (largely for performance and software availabliliy) and the laptop I spend my whole life on, but sometimes little nagging issues in design are a bit too uncomfortable. I'll post some shit on some forums or Slashdot that will make me feel better and run a BSD for a few days then go back. Pathetic but what can you do? At least I'm not a sex crime offender. Trolling is a relatively harmless hobby.
Meh, it ends here. Thanks for the coercion.
Actually, smartass, I DID test it thoroughly, and (in 2.6.11, and continuing to 2.6.12-rc2 - no other kernels tried) it consistently fails to connect the MSN protocol (any client) and POP3, and some HTTP seems to behave badly but mostly okay. It IS a bug in Linux because none of the BSDs exhibit this, and it is also a bug that isn't fixed in 2.6.12-rc2 despite numerous changes to IPSec (and related) components.
When you show me a BSD exposing a significant security hole (like the Linux signal exploit) or breaking long-standing network functionality (IPSec, packet filtering, etc.), then I might consider them somewhere close to buggy, but flawed hardware support is nothing compared to the breakages Linux experiences.
A Linux advocate I know said, and I quote directly, "I've had some corker problems on GNU/Linux-based systems that can only be attributed to poor development and testing, and implementing the same thing on OpenBSD had no issues at all. First thing that comes to mind as indicative of the difference in quality between the GNU/Linux and BSD's, is PAM vs BSDAuth.."
Honestly, it's no mystery and nothing new at all. Linux does not get tested. Shit, are you even listening to kernel devs? They've decided NOT to do any quality assurance, leaving vendors up to the task of testing and bug fixing (hint: they don't do a good job either). Find THAT kind of philosophy in any BSD...
How is it a good reason? It will only affect you if you want to use the few parts of software under the license in another project or embedded system. It doesn't make any difference to your usage or the quality of the operating system itself. I sincerely hope you're just trolling because you can't seriously believe what you say.
Well, it all depends how much security you WANT, short of not having a system at all. You can systrace everything and have a crack team of trusted, indoctrinated people constantly watching all traffic and analysing it for signs of attempted intrusion or investigation. Or you can trust the software quality and 'general practice' recommendations even outlined in the BSD handbooks.
:(
It's definitely a fun job though (one I wouldn't mind having), as long as the software is good. The BSDs are good in this regard, and so is Linux with the right patches and tools. But then sometimes a bug will come up nobody expected and it's all for naught
I don't think that's what he meant at all (with the right/privelege for code reading). The assumption ulib is making is that people are smart enough to be able to understand what is meant, and he obviously gave /. readers too much credit.
What is wrong with his list? All of those links work and are from who they claim to be: the graph of FreeBSD's server growth is from actual data, and only as old as 2004. Maybe you just can't read Netcraft's page properly. Or are trolling and hope nobody else will bother.
OpenBSD's OpenSSH really is the most prominent SSH daemon out there, NetBSD really did set internet land speed records (even if it's recently been beaten by Linux on more powerful hardware), etc. It's all out there and for you to say "none of them check out" is either blatant trolling or, as I prefer to see it, unbelievable stupidity. Up to you.
pkgsrc rocks very hard, but currently only 2000 (out of 5000+) ports compile on DragonFly BSD (identified by a few bulk build attempts). While hackery can work around this, for most users it spells limited installs. Even gtk2 isn't happening.
But I can confirm that it IS enough to get a web server with extras (php, mysql, etc.) up, although I did have an unexplained error at the end of mysql4-server's install. Nothing tragic.
This will definitely improve over time and effort, but right now it's not MUCH better than FreeBSD Ports + DFly Overrides. You would really only be inspired to use it if you already have a pkgsrc tree for other systems on your network and don't want redundancy.
pkgsrc is best on NetBSD where everything gets first-hand testing, and virtually nothing breaks. The situation is similar on (decent) Linux distributions - it is rumored some are entirely pkgsrc-based, even!