Slashdot Mirror
Celebrating 20 Years of OpenBSD With Release 5.8 (openbsd.org)
badger.foo writes: 20 years to the day after the OpenBSD source tree was created for the new project, the project has released OpenBSD 5.8, the 38th release on CD-ROM (and 39th via FTP/HTTP). This release comes with four release songs instead of the usual one, and a long list of improvements over the last releases. (Probably a good time to donate to the project, too, even if you don't use it directly, because of all the security improvements that OpenBSD programmers contribute to the world.)
No, I don't know of any OpenBSD 'features' that involve pissing off its userbase with half-functioning, amorphous garbage code like systemd.
That is as it should be. Restarting a service (or not) is dependent on the nature of the service and that nature of its crash. You can easily end up DoS-ing your machine by automatic unconstrained restarts. Hence service restart and service management has no place in an init-system or actually in the OS. Done right, it is a part of the service. It is also not hard to do and there are several packages that can serve as a basis for this.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You are mixing apples and oranges here. You should still give to both. By OpenSSH alone, OpenBSD has saved a lot of lifetime (although in smaller pieces than Doctors Without Borders) from getting wasted. And it is a critically needed fall-back if Linux continues to go down the train.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Unix is an evolving class of operating systems and they work the way we make them work. Sometimes we come up with new ideas that may or may not improve it. Almost no one agrees that Unix of the 90s was at perfection and that nothing would ever have to be changed again.
We did complain, but the minority in charge deleted threads and banned anyone that said a word against it, that happened at both Debian and Arch. It was a total fsck up and I'll happily go to bsd before having anything to do with that shit that is systemd and any users that use it deserve it, reboots and all.
http://chimpbox.us
That there's no point in talking about "how Unix works" since Unix has never been consistent unless you're talking about some of the really old AT&T releases. Once there were multiple Unix vendors things started changing all the time. What we're seeing now in the Linux space is no different from what has always been the case.
That is as it should be. Restarting a service (or not) is dependent on the nature of the service and that nature of its crash. You can easily end up DoS-ing your machine by automatic unconstrained restarts. Hence service restart and service management has no place in an init-system or actually in the OS. Done right, it is a part of the service. It is also not hard to do and there are several packages that can serve as a basis for this.
Crash management is probably the least interesting bit, it's the power management (sleep/suspend/resume/hibernation) and hotplug/dynamic devices (plugging in/unplugging monitors, headphones, USB devices, Bluetooth, wired and wireless networks) with dependency management that makes people want to turn the init process into a general service management system. Being able to restart a crashed process is just a spin-off and it's pretty easy to set generic constraints so it won't go in an infinite crash loop. Sure it's better to have software that doesn't crash but in the real world you often have to run the buggy software to keep availability up as downtime costs $$$ while you debug to find a solution. Maybe it was a wacky race condition that happens once a decade or a mystery bit corruption, you can't just shut down everything every time you run into a bug and keep it down until you've fixed it.
Live today, because you never know what tomorrow brings
The UNIX philosophy was always groups of simple tools that do one thing and do it well. You pipe them together and parse the data however you want. Systemd does the exact opposite of that. One monolithic service doing everything but poorly. None of these new ideas have undergone any real testing other than shipping the distro when they compile. You're beta testing this bullshit.
As an engineer who knows the pain of debugging someone else's locking problems, I lost it when I read this release note:
I've been using OpenBSD and FreeBSD for years.
They're different, but not horribly so. Most basic configuration is similar, and they both have excellent documentation. FreeBSD does have a lot of features that OpenBSD lacks, but I think that's a good thing; I use OpenBSD for network services (firewall, DHCP, DNS, etc.) and it's dead simple to deal with. That simplicity can make unusual things easy - getting my firewall to run diskless and boot off the DHCP server, for instance.
My basic rule of thumb: if I need ZFS or jails, I use FreeBSD - otherwise, I use OpenBSD.
I tried to set up NetBSD as a backup server (since it can act as a ISCSI target), but the monitor I use in the server room freaks out every time I boot it. It does it with OpenBSD too, but if I boot it with the KVM somewhere else and switch after boot, it works with OpenBSD. Oh well, maybe next upgrade cycle, I'll get a better monitor for in there.
I've never tried GhostBSD, nor heard much about it.
Those who can't do, teach. Those who can't teach either, do tech support.
Agreed 100% that post #50754359's AC is an uninformed blowhard ... however ...
XNU (OSX's kernel) does have a bunch of Mach-based code running in it, and it is being "used"; in fact it is performing critical functions:
Preemptive multitasking and multithreading
Memory protection
Virtual memory management
Inter-process communication
Interrupt management
Real-time support
Kernel debugging support
Console I/O
There is also a bunch of FreeBSD-based code running in XNU, implementing essentially all the other kernel functions, including POSIX support, filesystems
Is XNU microkernel-based? That's one for the semanticists to debate. Arguably the Mach-based code is not performing microkernel functions. What is not debatable is that there are or have been Unix-"alike" OS'es baed on microkernels. Minix is one. Hurd is another. They are as Unix-alike as Linux is. I would say POSIX defines Unix-ness, and there is absolutely nothing to prevent a microkernel from implementing POSIX just as fully and faithfully as a monolithic kernel.
Well, those that do not understand Unix are bound to re-invent its mechanisms, poorly. Systemd is a text-book example of that. Unfortunately, with the Linux community growing, far more idiots came in in recent years than people with a clue.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.