No I am fully aware that systemd targets Linux and OpenBSD is, well, not Linux. But seriously, what's the status of init in OpenBSD? Last time I used it (around 5.2 for some odd sparc servers that didn't support anything else apart from Solaris) it was still/etc/rc.d scripts, and no respawn if a service crashed etc.
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.
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.
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.
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.
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.
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.
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 microk
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.
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 g [dartmouth.edu]
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?
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.
Does it have systemd? (Score:0)
No I am fully aware that systemd targets Linux and OpenBSD is, well, not Linux. But seriously, what's the status of init in OpenBSD? Last time I used it (around 5.2 for some odd sparc servers that didn't support anything else apart from Solaris) it was still /etc/rc.d scripts, and no respawn if a service crashed etc.
Re: (Score:1, Interesting)
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.
Re: (Score:-1)
Re: (Score:2, Insightful)
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.
Re: (Score:4, Insightful)
Re: (Score:1)
Your point?
Re: (Score:4, Informative)
Re: (Score:5, Insightful)
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.
Re: (Score:0)
Re: (Score:2)
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.)
Re:Does it have systemd? (Score:5, Informative)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 microk
Re: (Score:2)
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.
Re: (Score:2)
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 g [dartmouth.edu]
Re: (Score:2)
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?
Re: (Score:2)
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 [catb.org]