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.)
really all that needs to be said.
I recently saw a video review of a new computer in a box that was too small have a CD-ROM drive but came with the drivers on a CD-ROM. *face palm* Fortunately, the drivers also came on a USB stick.
I still have a few spindles of blank CD and DVD discs lying around, but I haven't burned a disc in three or four years. Have USB sticks, will travel.
It's worth checking out in a VM. I've been enjoying GhostBSD quite a bit and have been thinking of installing it on bare metal instead of just using it in a VM. I will miss Opera though. At any rate, congrats and thanks - I'll have lots of fun poking at it. I've only played with FreeBSD and GhostBSD so I might as well give this one a shot too.
"So long and thanks for all the fish."
No, it doesn't have systemd.
If a Poettering-like asshole was detected anywhere near OpenBSD, they would be shot down like an aircraft flying over the White House without clearance.
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.
For variable values of "improvements". Some people (usually ones with a lot of experience and insights) think that the makers of systemd do not understand how Unix works or how to do professional system administration and hence view systemd rightfully as a step backwards.
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
GNOME depends on an dbus api, that logind implements, and logind is part of systemd. GNOME does not directly depend on systemd or logind. If you implement the API then GNOME will work just fine.
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.
I didn't say it did, I was pointing out that complaining to $DISTRO is a futile thing to do, I didn't mention the guy what so ever.
http://chimpbox.us
For variable values of "improvements". Some people (usually ones with a lot of experience and insights) think that the makers of systemd do not understand how Unix works or how to do professional system administration and hence view systemd rightfully as a step backwards.
So what? Use BSD, and revel in your superiority. If it is better, it will take over in no time.
From what I have read from y'all, it simply does not work, causes cancer, and will make your dog run away, and your wife either leave you or come back - whichever situation you don't want.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
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.
I doubt OpenBSD is going to even touch that until openlaunchd has been fleshed out.
As an engineer who knows the pain of debugging someone else's locking problems, I lost it when I read this release note:
This article isn't even about Linux, yet the comment section is filled with people who are pointing out serious flaws with systemd and the way it was shoved into every major distro.
In the articles that are actually about Linux, the comment sections look like war-zones. A significant amount of people voice their disapproval with systemd and the process by which RHEL shoved an extremely unpopular and major change into Linux. Yes, the distros did not have to adopt it. No, the distros can't defy RHEL's massive influence.
On official forums and mailing lists, moderators shut down rational discussion including technical criticisms of systemd. It has caused something akin to a Linux civil war.
At what point do you fucks admit that Linux has a systemd problem?
PC-BSD has GNOME 3.x as well, and it doesn't have systemd. However, GNOME crawls on a BSD. Maybe that's why GhostBSD has gone to MATE.
The Unix philosophy is about the userland, not the init system and other core components of the system
Who told you that? Or did you just come to this conclusion on your own? Either way, it's wrong.
If it was then Unix would have a micro kernel.
No, it wouldn't be Unix any more if it were microkernel-based. (OSX doesn't really use its microkernel, it's really just used as a HAL.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Lately there's been a backlash against GPL & RMS, who used to be highly praised around here. I think it has a lot to do with GPL3, but somehow the vitriol has been redirected toward his personal hygiene.
Linus is still held in pretty high regard, except for his sometimes-abrasive style. Lennart may well be the downfall of Linux fandom here.
Pretty much 3 main branches: FreeBSD, NetBSD and OpenBSD. OpenBSD is a fork of NetBSD. Dragonfly, PC-BSD and GhostBSD are all forks of FreeBSD.
Mac OS X/Darwin is a fork of 4BSD hybridized with Mach, and later sync'd with FreeBSD.
SunOS was BSD-based but replaced by the System V-based Solaris, with some BSD features folded in.
you can't just shut down everything every time you run into a bug and keep it down until you've fixed it.
Yikes.
Actually, you can bring it up again reliably until you've fixed the bug. I suppose you can have processes that keep pounding away at the system to try to force things to work, until the whole thing crashes. Or just nibbles away at resources until every part of the system is nerfed.
I may be wrong, but "power management (sleep/suspend/resume/hibernation) and hotplug/dynamic devices (plugging in/unplugging monitors, headphones, USB devices, Bluetooth, wired and wireless networks)" are not things that those running OpenBSD (or for that matter, Linux on a server) will be particularly interested in.
Perhaps what the controversy is about is really one of desktop vs server (with an OpenBSD firewall being more akin to a server than a desktop. OK yes, I realise that OpenBSD can run as a desktop, but I doubt it is marketed as a competitor for Ubuntu, Mint or even Fedora).
You never know what is enough unless you know what is more than enough. - Blake
Shows how little you know about what depends on what. do some research instead of relying on post of ignorant trolls
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
NetBSD has twm, and that's all that's needed, though an upgrade to fvwm2 is kinda nice. twm is a binary that you get automatically in the base install, from the 406MB iso if you're on an x86 platform.
Which is all well documented in the O'Reilly X11 manual set. (The User's Guide is Vol. 3, the Administrator Guide is Vol. 8)
I'm not sure why, exactly. AFAIK Unix doesn't dictate any particular kernel structure. NetBSD uses an 'anykernel' that is definitely Unixy but modular and more flexible.
It's not like the Unix kernel never changed. Mach was originally just an attempt to restructure the Unix kernel, and the microkernel philosophy emerged out of that as they abstracted more services out of the 'core' kernel.
Not exactly correct, since Core Foundation uses Mach calls directly. Strictly speaking, OS X doesn't have a microkernel - it has a modular monolithic kernel that supports traditional BSD interfaces plus Mach interfaces. IOKit replaced the traditional Unix driver interfaces.
Just 5 years ago there's no way we'd be celebrating 20 years of open bsd on slashdot.
Seriously? Even Haiku releases get celebrated here.
This space intentionally left blank
By no means am I an expert but systemd seems needlessly complicated. It seems that systemd was implemented for sake of change rather than addressing a true need. As others have pointed out, UNIX traditionally is a compilation of tools that each do a single thing well and play well together.
Just 5 years ago there's no way we'd be celebrating 20 years of open bsd on slashdot.
Yeah no shit, sherlock. That's because that would've been 15 years of "open bsd" (sic).
CLI paste? paste.pr0.tips!
VHS tapes aren't either. What's your point?
CLI paste? paste.pr0.tips!
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.
More accurately it's about tight versus loose coupling.
Under systemd, while there are many CLI commands, they are bound together and cannot be used independently. You can't really use journald, hostnamed, machined, timedated, etc., independently or replace them with something else that you've developed.
It's all very well to write a "better init", and maybe it has, but you're stuck with also running journald and can't put in rsyslog instead (only run in parallel). timedated may be good, and you want to use it on a SysV-based system... but you can't.
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.
However, package managers are not able to express dependency on APIs. The only dependencies they can express are on other packages, or libraries. Now, dbus as an independent package has been terminated, so as it stands at present the way package managers express GNOME's true dependency on the DBUS API is to just list a dependency on systemd.
If you want to know how Unix works, this is a good place to start.
If you want to know why systemd doesn't follow the Unix way (which means it's lousy), I discuss parts of it here.
"First they came for the slanderers and i said nothing."
twm is a Window Manager, not a Desktop Environment. As such, it has no start menu, taskbar, etc, and does not come packaged with a set of apps such as a file manager, print manager, etc. As such you will have a damn tough sell trying to get anyone used to using a DE to convert to a bare WM. If you want to run anything besides a shell command window, you're going to have to install apps which are not a part of twm. DEs come with basic apps.
Many would say twm is a primitive WM at that. The windows have no close, minimize, maximize, and restore buttons. Minimize doesn't even have meaning - there is nowhere to minimize TO. Resizing involves clicking on a resize button before you can drag an edge.
What you claim is not possible. You seem to be stupid. But actually, my guess is you are just a systemd shill working from its propaganda manual. Just es he is.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Exactly so. None of that crap has anything to do with a server. Maybe USB storage for backup, etc. For hotplug, besides USB, the only one I can think of is disk drive removal/insertion. My experience is with FreeBSD, and USB and disk drive hot plugging works just fine. The init scripts don't even play a part in this. The same in Linux before systemd reared its head.
You seem to be confuses as to the nature of a server OS. You also seem to not have read or understood what I wrote about restarts. I did not say to not do it, I did say that it is a service-dependent thing. Yes, you do it for buggy software, but that is even more specific, as it depends on the service and the bug. What you often need to do is service-specific cleanup before you restart. In fact, that is almost standard.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
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.
If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons.
A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.
The Biggest Myths
[2013]
You're beta testing this bullshit.
Then you are in damn good company.
Much of the debate about systemd is academic at this point because here's a truth that you'll discover in Debian 8, Ubuntu 15.04, and just about every other major distro around: systemd is here.
Debian 8: Linux's most reliable distro makes its biggest change since 1993 [May 1, 2015]
Red Hat is the inventor and primary booster of systemd, so the best distros for playing with it are Red Hat Enterprise Linux, RHEL clones like CentOS and Scientific Linux, and of course good ole Fedora Linux, which always ships with the latest, greatest, and bleeding-edgiest.
Understanding and using Systemd
If a Poettering-like asshole was detected anywhere near OpenBSD, they would be shot down like an aircraft flying over the White House without clearance.
Only one allowed per project (cough Theo De Raadt cough). I do grant that Theo's stuff works.
This page accidentally left blank
dpkg most certainly can express virtual depends, such as depending on a package providing a dbus api.
The point here is that if something else implements the api, then the package manager can use that.
Well, Android proved that Linux doesn't belong to the unix community. The good thing is, the unix community has never suffered from being a small subset of the entire computer-using public. And hey, then. This is a BSD topic so the fate of linux isn't central anyway. Personally I quit using linux and switched to NetBSD for my unix-like needs because of Red Hat 5.0 and the mess that was PCMCIA ethernet support at the time (a clown in a sidecar, when NetBSD had the drivers right in the kernel), and haven't looked back.
linux doesn't have a systemd problem, systemd has an ignorant trolls problem
I would say they do considering this IS NOT A LINUX/SYSTEMD story!
Shoot I feel like I am watching Foxnews comments or MSNBC where a dog gets run over by a car caught on video and somehow it all goes back to Obama's fault. It is alike an autistic obession with these trolls. ... also that rant has nothing to do with OpenBSD either I may add.
But I see parallels now with anti SystemD here. What's next? A story about a new NVMe SSD storage breakthru ... a comment comes up about systemD in that in how we wouldn't need these devices if SystemD was better or something stupid getting modded +5. Give it a break and moderators please do your job.
If I had any points I would mod down any talk of systemD in a story like this one.
http://saveie6.com/
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.
Here we go again.
Init is standard because it is the best and why change for the sake of change? Name one other OS that has switched away from init? ... uh ... hey wait a minute. It is still init ... well modules in its place. You edit those. Hmmm different and not the traditional unix way ... hey wait a minute pal! Ubuntu is cool and no way and you MR. GATES ARE A TROLL!! ... Linux is the 1st OS to replace the all so popular Init. Why change??
1. Solaris EMF (2008)
2. MacOSX LaunchD(2006)... well I guess it is not really Unix
3. NetBSD (2008?)
4. Ubuntu Upstart(2010?)
5, Linux (SystemD):
OpenBSD, FreeBSD, SCO, Irix, and HP-UX are the only holdouts. Oh Sco is dead and Irix has been done for 10 years. HP-UX is on life support etc. Leaves just FreeBSD and OpenBSD left unmodified.
If Init is sooo freaking awesome why is everyone switching to event driven replacements?
Well if you feel having processes launch processes which launch processes to tens of thousands of freaking PIDs and +200 lines of if ... fi scripts of every event which would spawn spawn another event to configure another event with over +3000 packages and probably over a dozen daemons running is a normal, unix way, right way to do something in 2015 then Init is perfect for you. Let's say you have a Macbook. It goes to sleep at your desk. You board a plane. You wake it open in a hotel room that evening. How would you program it to get on the network with init?
With an event driven system you do not have this problem which is why Apple invented launchedD it can do this automatically.
From what I read SystemD is modular and has separate components and follows the Unix philosophy more than Init. Is it any good? I don't know I am not a Unix administrator. But I am tired of seeing the hate and am intelligent enough to see why things are going the way they are. I am thinking of a scenario right now with an Apache or Ngnix box and with EMF on Solaris or SystemD I can write some event scripts in case a network connection goes down or what if it is hacked? That is some cool stuff with automation I can accomplish.
True the neckbeards running XP still probably have 20 years of scripts written for the old way described above who as a result of their effort who are fuming mad at the lost time and do not want to change but whatever. Actually I do not care about OpenBSD using the old way as OpenBSD tends to be for specific purposes with minimal configurations and changes running so the problems above are less problematic.
http://saveie6.com/
You are missing what is going on here: Making the boxes more "friendly" to novices and at the same time throwing out reliability, simplicity and security. Of course most users like that as most users do not have much of a clue how their box works. But when a distro like Debian (which is still regarded as the "rock solid thing for the server", but probably not much longer) does it, then this massive dumbing down and all its drawbacks start to affect people that actually have a clue and that is where the opposition to systemd comes from. This is also why the opposition only manifested itself when systemd was being made the default all around and applications started to depend on it. Before, competent people could simply ignore this abomination and leave its use to the clueless and hence they did not care. That seems to be about to change, and that is just not acceptable.
And this is not singular to Linux. Ask an experienced Solaris administrator what they think about SMF (that is the part analog to systemd) and you will get some pretty heated negative reactions or horror-stories. Ask some nil-whits that can barely use a commandline, and they may actually say it is a step forward. But when you have a real service management problem, all these nice "enterprise" tools turn out to make the problem worse and now you have to work around them in really stupid ways and have to fix utterly demented defaults, like binary logs.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Systemd does the exact opposite of that. One monolithic service doing everything
Presumably by "service" you're not referring only to what process 1 does by itself (rather than by services it runs) on a system with systemd.
Is XNU microkernel-based? That's one for the semanticists to debate. Arguably the Mach-based code is not performing microkernel functions.
I'm not sure that it arguably is performing them; it seems pretty clear to me that it isn't.
What is not debatable is that there are or have been Unix-"alike" OS'es baed on microkernels. Minix is one. Hurd is another.
The Hurd is definitely a better example.
OSX uses a microkernel. Besides, there are/were plenty of Unix that used microkernels: OSF/1, Digital Unix/Tru64, etc.
The point is moot any way, most of you aspies don't understand the debate is moot because Linux is not unix.
The debate is moot because too many people involved in the debate are using "Unix" as a hammer to beat down anything that provokes their nerd rage.
I'd say that "the Unix philosophy" is spelled out by the various documents that the Wikipedia "Unix philosophy" page cites. Whether it covers mechanisms such as the init system, much less the kernel-mode code, is, well, subject to debate.
And something doesn't have to "be Unix" in the trademark sense or in the "you can draw some line of descent by which the code derives from Bell Labs Unix" sense to be Unix-like enough for people to debate whether it conforms to the Unix philosophy or not. As far as I'm concerned, Linux is Unix-like enough for that, and it pretty much works as well as other Unix-like systems, whether they're "Unix(R)" or "V7-derived" or not, in that regard. (And most of those systems probably support the -v flag to cat. :-))
It seems to be the classical Windows/Unix split: Some people want a system that assumes they are dumb and does everything for them. Others want control and understanding. Traditionally, the dumb ones standardized on Windows. Now some of them have seen that Linux actually has advantages, and they demand that dumbing-down on Linux as well, hence systemd. That this removes the main reasons to use Linux completely escapes them.
Those on Linux because it gives them access and control, and even a thing like the userspace part of the boot system can be understood with not a lot of effort, understandably do not want that. At all. The nice thing about Linux is that it turns a desktop or even a laptop into a server-grade Unix-like system. Systemd is out to stop that and make it again a windows-like, fragile, insecure, closed system that addresses users, not people with a clue. Sure, it does not go all the way (yet), but the direction this thing goes in is painfully clear. The rabid, fanatical, clueless followers that come with systemd are also no surprise at all. Windows has had them for a long time, but usually they could just be ignored.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
And seriously, even USB hot-plug is not something that needs to be automatized. If you need to run some scripts manually anyways, just mount it manually. Udev has far too much "auto-mess" functionality for my tastes and I routinely find it making things worse instead of better.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You may have read that, but reality is shit like systemd hanging indefinitely waiting to detect a wireless mouse dongle (noticed it was hung booting and rebooted after five hours, then pulled the dongle and rebooted again). The parallel idea didn't happen.
The rage is due to it being perpetually a half finished sack of shit expanding into other areas before the existing ones are fixed. It's more rage at poor implementation than the idea itself.
I thought that was sorted out with Win2k, WinXP and Mac OS X? A server OS (WinNT or *nix) turned out to be far better for the desktop than desktop only shit like WinME.
From what I read SystemD is modular and has separate components and follows the Unix philosophy more than Init.,
That's not what's meant by the unix philosophy. None of those components is independent of systemd, they're all part of it. You can't for example swap out syslog for jounrnald on a Gentoo machine running OpenRC. This is not like having GNU AWK and MAWK installed and switching one for the other.
The systemd modules are just that, modules. Like the kernel. They're not separate components which do things independently in the way that the unix shell utilities are.
Now whether or not you believe that's a good thing is an entirely different debate.
Well if you feel having processes launch processes which launch processes to tens of thousands of freaking PIDs and +200 lines of if ... fi scripts of every event which would spawn spawn another event to configure another event with over +3000 packages and probably over a dozen daemons running is a normal, unix way, right way to do something in 2015 then Init is perfect for you.
One thing the world has been plagued with is people who can't write init scripts for crap. Redhat was particularly bad and ubuntu was only a little better. Arch, prior to switching had rather short, simple RC scripts, certainly nothing like you describe. Oh and it booted faster with it's RC scripts than systemD, so there's that too.
SJW n. One who posts facts.
That's a very well elucidated description of the problem.
SJW n. One who posts facts.
Which part? If you're talking about the journal entry, I've written several. Not all of them are negative, though.
"First they came for the slanderers and i said nothing."
Oh the one you linked. The bit about concentrating on code rather than interfaces. I'd not thought of it like that, but that makes a good deal of sense.
SJW n. One who posts facts.
I'm glad you liked it. Thankyou for mentioning it.
I remember you've written posts in the past about systemd that were rather insightful, too.
"First they came for the slanderers and i said nothing."
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:
They are not using Mach, the microkernel part, to do any of that shit. For example, they are not using it to do process management. That's done by the kernel, not the microkernel. That's the primary reason why XNU is not actually microkernel-based any more than NT is. It has a microkernel-like architecture, but then they underutilize it.
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.
If you actually used the microkernel, then you would have some processes managed by the microkernel, and perhaps some managed by the kernel. But they're not using the microkernel for any of the things you mentioned. That's all handled by the kernel. The whole point of a microkernel-based OS is that you don't have a megalithic kernel; you replace it with a series of services which are serviced by the microkernel. Instead of everything built in, blockdev access and network access are just more processes, and they get access to the actual hardware through the microkernel. Instead, blockdev and network access both happen through the kernel. Something goes wrong with either thing, the kernel explodes, and the system abends. In a microkernel-based system, something goes wrong with either thing, the daemon restarts, and you may not even notice.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The Hurd is definitely a better example.
Absolutely, since it actually is microkernel-based. And GNU's not Unix, and neither is The Hurd. It's a POSIX-compatible Unixlike operating system, but it ain't Unix or UNIX.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The Hurd is definitely a better example.
Absolutely, since it actually is microkernel-based. And GNU's not Unix, and neither is The Hurd. It's a POSIX-compatible Unixlike operating system, but it ain't Unix or UNIX.
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
However, it probably looks enough like actual Unix systems that one could ask whether it violates the "Unix philosophy"(TM) or not; given that its userland is GNU, Doug McIlroy might argue that it's been fed enough goodies to bring it to a disheartening state of obesity (joining Linux, for much the same reason, and, I suspect, most other Un*xes these days in McIlroy's opinion). On the other hand, the usual flavors of pipeline continue to work on it, Linux, and those other Un*xes, the obesity notwithstanding, which is good enough for me.
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
No, not Unix(R), but UNIX(R). Unix is the name for the family of Unixlike. UNIX is the trademark, or at least, that's the convention people use to differentiate between Unixlikes and UNIX. The convention was created by UNIX, which was emphatic about the all-caps until recently, and not by the community.
If you think The Hurd is Unix, then so is QNX, right?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
No, not Unix(R), but UNIX(R). Unix is the name for the family of Unixlike. UNIX is the trademark, or at least, that's the convention people use to differentiate between Unixlikes and UNIX.
There may well be people who use that convention, but I am not one of them. Another convention that people use is to refer to Unix-like systems, whether they passed the SUS validation suite or not and whether they contain code derived from Bell Labs UNIX code or not, as "Un*xes".
The convention was created by UNIX, which was emphatic about the all-caps until recently, and not by the community.
The convention was created by the people who created it. Eric Raymond claims that Dennis Ritchie says the all-caps version stems from being "intoxicated" by the ability to produce small caps with troff and the new typesetter, and that Ritchie later tried to get the spelling changed to "Unix" in some Bell Labs papers, but failed.
The "UN*X"/"Un*x" convention was created by other members of the community (I remember it being used in USENET postings), and it's the one I use.
If you think The Hurd is Unix, then so is QNX, right?
I don't think the Hurd is a trademark UNIX or a derived-from-Bell-Labs-code UNIX. I do, however, consider it Unix-like enough to consider it a UN*X, and consider QNX at least somewhat Unix-like, although it appears that there's a lower-level API below the POSIX API that can be used.
Just 5 years ago there's no way we'd be celebrating 20 years of open bsd on slashdot.
No, that wouldn't have made sense, as 5 years ago OpenBSD had only been around 15 years.
I am literally 3000 tokens away from the chaotic crossbow --Stephen
This bad? That is staggering. I think the following applies pretty well to the systemd team:
"Someone who considers himself too important for small jobs is often too small for important jobs" -- Jaques Tati
Solid engineering requires attention to detail. Rushing off to break even more other functionality before your replacement stuff works well is a sure recipe for disaster. Incidentally, while I do not have "rage" for them (they are far too unimportant to me), the defects of the idea itself may have something to do with these stupid problems. It seems they have replaced "Do one thing well" with "do many things poorly". As far as I can see, that is the main criticism against systemd, besides it being made default everywhere and things depending on it that have absolutely no business depending on an init-system, like Gnome.
That said, the worse their trash behaves, the sooner some people will wake up and will at least make sure viable alternatives stay maintained. I frankly could not care less if people use systemd as long as I can have a clean system without it without having to do the init-system myself.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
One thing the world has been plagued with is people who can't write init scripts for crap. Redhat was particularly bad and ubuntu was only a little better. Arch, prior to switching had rather short, simple RC scripts, certainly nothing like you describe. Oh and it booted faster with it's RC scripts than systemD, so there's that too.
Ah, yes. I have observed that too. Funny thing is the ones I wrote myself never gave me any trouble later. Of course, moving to systemd to fix that is about the worst thing they could have done. Hiding complexity does not make it go away, it just makes it so much worse when something breaks. Genuine simplicity can only be replaced by genuine simplicity and systemd has nothing of that.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
If your service is crashing there is something wrong with its code; respawning it does not solve core problem. That is somethig I've seen a Drupal-tard, for example do to make up for their shitty code running away every ten minutes. either that or put restart as cron job */10. So systemd is a bandaid for badly written shaky crap, thanks for clearing that up
Exactly what features or improvements would that be? restarting capability for badly designed crap code that keeps falling over (instead of robustly written services)? integrated firewall, masquerading etc that should be in a separate system (and IS in BSD)?
Your "problems" are not a need for systemd, they are a need for proper tools and methodologies that exist already.
Yes, there is a point in talking about Posix standards as the way Unix works.
Apparently the "upgrade" program on the CD twiddles with your routing tables, in case you're having problems getting packages to download. By default my system wouldn't connect to the network, so I chose the shell option, cleared the tables, used dhclient on a different interface, and then restarted the process by running "upgrade." This *still* didn't work and was kind of confusing. Control-C out of the program shows that the routing tables got changed somehow (it sets the default route to the _external_ IP, I assume some "smart" detection is making this genius decision).
Anyway, if you have this problem, use the ! in the package URL selection process to drop out and change the network settings back. It does this modification early enough in the process that this works.
It was enough work to figure out what the problem was, and I don't have enough patience to deal with a known-abrasive community to file a bug report and do back and forth. So, hope this helps someone searching.