Crowding out OpenBSD
lwn.net
lwn.net
"That, needless to say, is a recipe for irrelevance and, eventually, disappearance."
In the last eight+ years I've used OpenBSD extensively as the networking and firewall core for smart grid networks. I can, with confidence, say that 100% of the smart grid transactions on at least two $Billion+ utilities on at least two continents flow through OpenBSD servers.
We evaluated the full gamut of Cisco, Fortinet, and other Firewall technologies, but, from 2004 through 2010, only OpenBSD had the functionality and failover that we were looking for for < $100K/appliance. (And, when you want two for redundancy, plus another two for your DR center - Four appliances add up). It almost pained me to see how low-end a server could handle hundreds of thousands of IPv6 UDP states compared to what Cisco would have charged. (Note - and, regardless, Cisco didn't, until recently, handle IPv6 in fault-tolerant Active-Hot-Standby mode on their ASA platform)
For those that have a lot of experience with OpenBSD - the continued rock solid stability, almost 100% complete (and useful) _systems_ documentation (as opposed to the utility and library documentation you get on a linux system), consistent startup/configuration for 10+ years, plus, of course, very mature pf, makes the platform a continuing highly relevant product, that will not disappear for many years to come.
Sadly, due to the limited amount of time I have for IT these days, I have standardized on Linux for my new firewalls (because I need it for my fileservers and desktops too). After trying some other firewall setup systems, I'm currently using ShoreWall, which is... OK. I feel almost as safe, in part because of what I learned about TCP/IP networking while using pf.
So my reaction to not having good GUI support for OpenBSD is kind of "so what?". It is awesome for what it is right now.
I would suggest they throw their weight behind one of the smaller DE projects like LXDE or XFCE. In my mind's eye, the stereotypical OpenBSD enthusiast is not that impressed with whizzy GUIs with a dumbed-down interface that has significant compromises just so that it can also run on a tablet. I would guess that they just want a simple DE with terminal windows, a browser and PDF reader. Well, that's nearly all that I want, so that's probably why I run LXDE. Not that I'm a stereotypical OpenBSD enthusiast. All I really ask of my DE is that it supports auto-raise and doesn't steal my focus while I'm typing (grrrr, Windows 7, grrrrr).
That's true. There's not much out there in GUI land that isn't GPL these days though, from my brief survey.
I'd guess they're not completely satisfied with FVWM though, because they mention working on Gnome for OpenBSD.
OpenBSD WILL disappear if not supported, no matter how useful it is.
I want KMS, I want to be able to install Gnome and see what they are up to. Not that I care about Gnome, but it should work if at all possible. There are a lot of users and developers who want a well working modern desktop running OpenBSD.
4.8 and later introduced some syntax changes, so current OpenBSD docs aren't applicable to other systems.
I really wish pf had enough people to get the full "portable" treatment like OpenSSH, etc. get.
I agree. I'd rather use pf than ShoreWall on my Linux systems. If someone who had more time/energy for this wanted to start up that project, I could chip in at least a little money. I'm sure others could too, but I don't know how much that would add up to.
I did get a kick out of seeing my old Celeron Windows 95 machine now running a modern OS, browser and chat client.
By "Desktop" - though, I mean users who are planning on downloading/installing various productivity utilities, applications, etc... to do their job. Creating Reports, Slide Decks, PDFs, Spreadsheets, charts, diagrams, IM apps, Skype - whatever random app they want to use to do their Job.
I've never seen an OpenBSD user in 20+ years of supporting Desktops in Engineering and Corporate environments - Windows obviously, but lots of Macintosh OS, A nice run of NextOS, Lots of FreeBSD, umpteen distros of Linux (for a while, that's all people seemed to be running), many versions of Solaris, tons of Irix, a handful of HPUX users, and even a couple AIX users.
But, in that same time - I've seen OpenBSD squirreled away in all sorts of Appliance/Network/Firewall duties.
I think the average user could be satisfied with what's available on OpenBSD. The only bummer is flash.
``Creating Reports, Slide Decks, PDFs, Spreadsheets, charts, diagrams[...]''
LibreOffice is available on OpenBSD.
``IM apps''
Pidgin and a ton of other clients are available.
``Skype''
It used to work a few releases ago, I don't know if it still does now.
`` - whatever random app they want to use to do their Job.''
Yes, if you compare it to Windows in that regard then it's at a loss. But if you compare it to Liunx I'd say it's up to par.
The problem is that it's getting harder to keep up to date, which is what Marc is trying to explain in his email to tech@.
'Hacker' News, indeed.
A couple of years later I heard from an OpenBSD dev who noted the issue and recommended a workaround, which I implemented and hopefully means KDE works in OpenBSD now.
But other than that one dev I'm not aware of any OpenBSD users or devs noticing or complaining about that bug (which would have been quite noticeable from the terminal output at least).
Drawn whatever conclusions you will from that. ;)
We now have one, so there is quite some movement on this front in the recent months.
That's correct. Although I'm one of the few who actually seems to care about portability as a good practice I don't have the time to run 5 different OS'es to verify each of my volunteered contributions works on every feasible POSIX platform.
In the end someone who is interested in each of those platforms needs to help take on the task of ensuring that the software they use works on the platform they use (that is, if they wish for the software to work). This can be as simple as reporting bugs, helping with integration into platform-specific libraries (which KDE is usually very good about using through adapter libraries to ensure portability), reporting platform-specific bugs that need worked around, etc.
Some projects are already taking a WONTFIX attitude to portability bugs. I will push where I can to make sure that KDE isn't one of them, but I can't change the number of hours in a day... non-Linux developers need to contribute too if they want a great KDE on that platform.
Which is convenient, as then I feel less guilty about the issues I don't have time to triage, less alone fix. You don't think I personally care if you use KDE or not I hope... I contribute where I can, as time becomes available. If people find that useful, that's wonderful. If people don't find that useful, that's fine too.
I've heard from many people who have found useful those things I've found time to implement, so I'll keep plugging along for now.
As it turns out though, there actually is a build farm/continuous integration infrastructure that our wonderful sysadmins have setup for KDE by now: http://build.kde.org/
But CI isn't useful unless it results in actionable information, and it still requires developer action to make the fixes. We're accepting patches...
If you're saying OpenBSD users are in general pickier about what software they install based on what practices are used to develop that software I'd certainly believe it. I've certainly done no studies myself to figure out why there are so few bug reports so I can't say any one reason is better than another.
And NetBSD users, and minix users, etc, etc. That's exactly what I was saying.
It can be done, but with quite a bit of tweaking, battling strange inconsistencies, and in the end, missing some functionality compared to the same thing on linux. Possible, but not by any stretch a core value proposition or a major component direction of the projects (whatever they officially say). Or at least, not the successful projects.
Sucks to see a lot of things becoming linux-specific, but in a ton of these cases, the impact on the BSDs will be minimal.
I don't know anyone who uses it, nor do I really hear about it apart from the people developing it. Sometimes, people mention it, in a "Maybe you should try PC-BSD, I've heard it's good" kind of way, but that's as far as it goes.
There's a bit of nitpicking in the above. PAM may not be a new technology, but it's not used by every OS. The problem is the implicit assumption by many devs that it is being used. Multiply this by every choice that the Linux kernel and various distros have made differently than other Unix-like OSs and you end up with a ton of open source software that is effectively locked into Linux.
In my (limited) open source experience, most devs using Linux do NOT do this on purpose. They just assume that they're writing UNIX software when they are not. They end up using GNUisms, #defines only available in Linux, assume PAM and other things, ad nauseam. When I've pointed such things out, I usually get a bewildered look. Many Linux people think they're using vi when they're using vim. They don't understand that their sed scripts are really gsed and won't work on traditional sed. They don't know their sh scripts are really bash scripts and break on traditional /bin/sh. And C code is a similar story. In most cases these little things do not improve the code; they only introduce incompatibility. So when Espie uses scare quotes on "progress" and "modern" I get his point. When progress and modern mean an equivalent but incompatible system, then they deserve scare quotes.
http://news.ycombinator.com/item?id=4798791
The previous discussion is more informative.
How does it matter which platform HN uses? It is about the content, not the technology. 99% of HN visitors do not care if HN is running on a lemon powered Babbage engine or not.
I doubt those two are used to gain market share ... maybe openbsd is just pure fun
Linux is complex because sometimes it has too be, not just for the sake of it. systemd (which is great in my opinion) wouldn't be possible without cgroups. Should I also mention the better multi-processor support? Regarding the desktop, I strongly recommend watching "27c3 - Desktop on the Linux... (and BSD, of course) - Wolfgang Draxinger (+ Lennart Poettering)" [1].
Because I need to run windows applications.
>Why aren't you running a virtual machine of Windows 7 under OpenBSD?
Because my laptop already had windows 7 on it, why install two OSes when I can install one?
>Linux is complex because sometimes it has too be
No, using complexity to justify further complexity does not mean it has to be that way.
>Should I also mention the better multi-processor support?
That has nothing to do with simplicity though. NetBSD is also simple, and it has SMP support as good as linux does. I am just using openbsd because fine grained locking is un-noticable for a dev box, and openbsd comes with better package management than netbsd.
>Regarding the desktop, I strongly recommend watching "27c3 - Desktop on the Linux...
I'm not very far through, but I have no idea why you think I should be watching this? Is there a particular time I can jump to where something relevant happens?
The tests were performed using system defaults on each platform with pgbench as the test client with a scaling factor of 800. The test system in question was a dual-socket Intel Xeon X5650 with 24GB RAM.
NetBSD 6.0 was unable to complete the benchmark run.
That video shows that things aren't as simple as one might think, at least on the desktop.
[1] https://plus.google.com/101384639386588513837/posts/ZD5ZhZ2F...
It is pretty unfortunate that the dragonflybsd camp still insist on pushing deliberately misleading benchmarks, I must admit. They have a great OS and there is simply no need for them to be doing that shit. Refusing to adjust the default limits when you know full well netbsd and openbsd ship with conservative limits to prevent accidentally DoSing yourself on low end hardware is just plain stupid. "Oh look, netbsd mysteriously stops working right when we hit the default resource limits!"
So that benchmark is kind of wrong. What about the results for fewer concurrent clients? NetBSD seems to perform worse than (Scientific) Linux. Is it because of those resource limits?
The dragonfly benchmark doesn't give us any real info, so it is impossible to say what exactly the problem is. Clearly something is wrong though, given we already know netbsd made performance and scalability a major focus of the 5.0 release, and nobody has reported any regressions in 6.0: