SoylentNews is people
SoylentNews
joekiser writes:
"Antoine Jacoutot has given a status update for GNOME users of OpenBSD, including a short video. The GNOME release has been updated to 3.10.2, and auto-mounting of devices is now supported through a new helper program, toad. Now is a great time for desktop users to test the upcoming OpenBSD release. The ports tree was recently locked for stability testing ahead of the 5.5 release, meaning that recent -CURRENT builds are very close to what will be released in May. Antoine also addresses the upcoming issues non-Linux systems face with GNOME, such as the upcoming hard dependency on systemd."
[ED Note: I ran an OpenBSD router box years ago when tinkering about with an old PII with four NICs seemed worthwhile. The OS lived up to it's rep, but it never occurred to me to use it for a desktop system. Are any Soylentils using OpenBSD for a GNOME-based workstation?]
(Score: 5, Interesting) by evilviper on Friday February 21 2014, @12:06PM
I don't see any reason to use OpenBSD as a workstation, instead of FreeBSD. Many years ago I did, and it was a valuable learning experience, but occasionally quite painful. Some of that pain is gone, but so, too is some of the simplicity and other benefits I admired, and few people any longer need that kind of learning tool...
OpenBSD's advantage is in startup scripts simpler than FreeBSD or Slackware. You really have everything in /etc/rc, and configure everything in rc.conf... Great for a noob to learn, and nice if you're massively messing around with startup. But really, FreeBSD is only slightly worse. FreeBSD also has some ACPI support for power management that OpnBSD lacks, drivers for FAR more hardware, a considerably more extensive collection of ports/packages, and vastly more configurability with ports.
These days, OpenBSD has a pretty good collection of ports, but they're not configurable, every package gets built with ALL options and dependencies, pulling in obscene numbers of unrelated packages to be built first, like ALL OF GNOME when you want a calculator...
I used-to love how plug-and-play it was, just autodetecting and loading drivers for any hardware it knew of (which wasn't that much) years before Linux got things like Kudzu that took the black art out of it, and when FreeBSD required manually configuring which modules to load.
But the world has changed... There is less hardware variety, other platforms have done better at identification and automatically enabling devices, and it always seems like OpenBSD hasn't added a new sound card driver in a decade... OpenBSD was never ahead, but they seem to be lagging even further behind as their user-base shrinks, and their funds dry up.
Some of the most useful experience I specifically gleaned from OpenBSD was figuring out how to compile software on crufty old Unices, using out-of-date versions of GCC, and similar. This helps tremendously when your company wants to standardize on one software package to provide a given service, but your crufty old legacy Unix boxes aren't officially supported, and the code won't compile due to missing typedefs, fast ints, conflicting headers all around the place, and more.
I still slightly prefer OpenBSD's boot manager... Very simple command-line tool, which lets you enable the serial console right there (blindly typing-in the command if needed), enabling verbose boot debug info, and RECONFIGURING the kernel, to change driver parameters, or disabling trying to detect a certain driver, all of which makes getting OpenBSD booted on a finicky machine with weird bugs substantially easier than the more polished yet less functional systems out there. You might not think you want/need that in a desktop OS, but years ago, my Laptop wouldn't boot with anything else, and my non-x86 workstations were never fully functional using any other open source OS.
Hydrogen cyanide is a delicious and necessary part of the human diet.
(Score: 0) by Anonymous Coward on Friday February 21 2014, @12:28PM
That beautiful piece of Unix simplicity has been in FreeBSD for decades and is still there to this day. Without it, FreeBSD is worth a lot less. All default configs in /etc/rc.conf makes life so simple.
I have never understood this need to improve the speed of the boot process by a few milliseconds. How often do people boot their systems? In my case, once every few years.
(Score: 4, Informative) by TheRaven on Friday February 21 2014, @02:46PM
FreeBSD has /etc/rc.d and /usr/local/etc/rc.d, where packages can install scripts to start, stop, and control daemons. You use rc.conf to define which ones should be started (and what other arguments they're given). On OpenBSD you just have /etc/rc.local, which is a shell script. This means that there's no way for a package uninstall to remove an rc entry, so you end up having to bracket everything in tests to see if the daemon that you're trying to start exists, which means that turning on a service in OpenBSD involves copying a few lines of shell script into rc.local. In FreeBSD, you just set the {package name}_enable variable to YES and it runs. When it's uninstalled, that line is dead code, but it's just setting a variable, so it's safe (it just slows things down slightly).
While speeding up the boot is nice, the most important reason for replacing init systems is that you want something that can be managed at scale. Adding and removing files is easy, as is running a command that (atomically) updates some structured format. Modifying a text file, especially one that contains code written in a Turing-complete language (e.g. POSIX shell), is not something that scales well when you're trying to manage thousands of machines.
sudo mod me up
(Score: 0) by Anonymous Coward on Friday February 21 2014, @11:20PM
Running services from packages is not something you do on a regular OpenBSD system. Anything I care about can be set as a variable in rc.conf.local. Of course the article is about Gnome, so you are going to get everything and its grandmother running as an insidious service. Good luck.
(Score: 0) by Anonymous Coward on Saturday February 22 2014, @01:15AM
Your information is out of date. OpenBSD also has scripts in /etc/rc.d, and enabling, say, saned is just a matter of setting "pkg_scripts=saned" in /etc/rc.conf.local. rc.d scripts first appeared in OpenBSD about three years ago.
(Score: 2) by TheRaven on Saturday February 22 2014, @10:30AM
sudo mod me up
(Score: 0) by Anonymous Coward on Friday February 21 2014, @08:35PM
> FreeBSD also has some ACPI support for power management that OpnBSD lacks
OpenBSD is generally considered to have better ACPI support than FreeBSD, especially on laptops (including suspend/resume and hibernate). Also, OpenBSD's KMS support is further along, and other BSDs tend to pull in the fixes from OpenBSD first.
(Score: 1) by evilviper on Saturday February 22 2014, @02:20AM
You got that completely, totally, and utterly BACKWARDS and wrong.
OpenBSD didn't get ACPI working until 2011:1 00802212025 [undeadly.org]
http://www.undeadly.org/cgi?action=article&sid=20
FreeBSD's ACPI support dates back to at least 2001:o pos=0&sektion=4&manpath=FreeBSD+5.0-RELEASE&arch=d efault&format=html [freebsd.org]
http://www.freebsd.org/cgi/man.cgi?query=acpi&apr
Maybe so, but not by much, and IMHO KMS is a misfeature, anyhow, that I'd prefer to be without, even on Linux.
Hydrogen cyanide is a delicious and necessary part of the human diet.
(Score: 0) by Anonymous Coward on Saturday February 22 2014, @03:37AM
If you had read the post you replied to, you'd know he didn't mention temporal precedence, just better quality. You could have asked him for some evidence to back his claims.
Paying so little attention it's no wonder you favor a slow, outdated and insecure system.
(Score: 1) by evilviper on Saturday February 22 2014, @05:32AM
I listed dates only because it demonstrates how laughably ridiculous the claim was. I know quite well that he's completely wrong. I wouldn't ask for sources from someone who claimed the moon is made of cheese, either. At best, that would make it seem that there's any possibility he's no utterly wrong, which he is. He was free to provide citation up-front, and is still able to provide them now, even though I didn't ask for them.
Hydrogen cyanide is a delicious and necessary part of the human diet.
(Score: 1) by Anthony J. Bentley on Saturday February 22 2014, @04:26AM
Why would KMS be a misfeature? It allows for faster graphics drivers and better security: graphics hardware access gets restricted to the kernel instead of the X process; and X is something you want to have as little privilege as possible, as described for example in this talk [media.ccc.de]. (If you have the time, that talk is definitely worth watching all the way through.) In current OpenBSD snapshots it's already possible to disable aperture access [openbsd.org] while using KMS drivers.
(Score: 1) by evilviper on Saturday February 22 2014, @05:40AM
KMS is a misfeature, because restarting X11 doesn't reinitialize the graphics driver anymore. If your video card driver has ANY bugs at all, you have to reboot the entire system, rather than being able to restart X11. I've seen this first-hand with older Intel graphics.
It's patently anti-Unix philosophy to have booting-up to a text console depend on something as large and complex as graphical video card drivers. Now instead of an upgrade possibly breaking graphics, it renders your system entirely unusable even from the command-line where you might fix it. Prioritizing graphics performance over system stability is utterly wrong-headed.
Hydrogen cyanide is a delicious and necessary part of the human diet.
(Score: 1) by ld a, b on Friday February 21 2014, @11:05PM
Leaving aside the points raised by other people, I think you are forgetting why someone would consider OpenBSD for anything in the first place.
I don't know enough about network security or RNGs to criticize, but FreeBSD exploit mitigation is abysmal. They are just now starting to consider implementing ASLR. Stack smashing protection is only available for the base system(ie. not your desktop). This means that about just any stack corruption bug can be trivially exploited by a stack smashing aficionado in a few minutes real time.
Even if we assume that their jailing system is able to and actually set up correctly to prevent the exploit from taking over more processes, I can tell you I wouldn't like to run a Desktop with say an pwned web browser running arbitrary code.
In TFA case, he has to provide desktops for clueless users who, for all we know, will attempt to download porn and angry birds at any chance they get, from their nuclear plant controlling terminals. I can see why they would go with OpenBSD.
10 little-endian boys went out to dine, a big-endian carp ate one, and then there were -246.