Is it just me or is page conflating SCO OpenServer and UnixWare as being the same product a bit? Yes, SCO bought UnixWare from Novell (a now infamous purchase), but that doesn't mean the products share a close lineage, or actually merged, as a result.
It's been so long since I've touched OpenServer (say, ~20 years) that I can't remember if the technical bits of the page are actually OpenServer or UnixWare (I'd say OpenServer). OpenServer had Xenix as a predecessor and, though I didn't work with UnixWare at all, what little I did play with it made clear there were some substantial differences.
All of this is all but historical trivia now, but I'm sure there are at least some OpenServer installs running out there... somewhere....
They did actually merge the products around OpenServer 6/UnixWare 7. No, the names don't make a bit of sense.
While SCO licensed Xenix from Microsoft and kept the port going through 386 support, SCO Unix/ODT/OpenServer/UnixWare all descend from a separately licensed SCO System V release 3 port, not Xenix.
Disclaimer: I worked for the company that wrote the (in)famous C2 security subsystem for SCO.
It probably is, it's been around for a while and is widely used by those of us who still have to keep legacy Unix boxen running As it's not like you get to touch your Unix box every month due to how rarely they fail or need updates after a decade of purely bugfix releases.
These things do not actually exist in systemd at all, outwith a few compatibility shims. And the same can be said of FreeBSD, too. They don't actually exist in FreeBSD, or indeed any BSD, at all, outwith compatibility shims such as FreeBSD's init command. (The FreeBSD init compatibility shim really is not recognizing the command-line arguments as runlevels in any real sense, especially since it does not recognize the numbers 2, 3, 4, and 5; the very numbers for which the run part of runlevel is appropriate.)
Note that the systemd compatibility shim completely ignores the actual "runlevel0.target" targets; that there is no "init table" of runlevel stuff; and that the separate run levels in /etc/rc[234].d are all combined into one by systemd's backwards compatibility service unit generator. This stuff genuinely does not exist in systemd.
It is fairly outdated. It says it was last updated in December 2014, but I'm not sure it's had much added.
(this is on Ubuntu, but anything with systemd should be similar)
You're correct about systemctl. If you do:
ls -lh /sbin | grep systemctl
you can see that `poweroff` and other commands are symlinks to `/sbin/systemctl`. The systemctl code shows it checks the name it's called with and chooses an action based on that:
There are almost as many glaring deficiencies and errors in that one as there are in the headlined page here. Just two out of the many problems that are similar:
* In one of the several systemd errors, it describes "system" and "package-related" service directories for FreeBSD; and "user, "system", and "package" service directories for SmartOS; but states that all unit files are stored in the /etc/system tree for the systemd operating systems.
* A whole bunch of stuff in the Ubuntu column is around 11 years out of date. Ubuntu switched from /etc/init.d/ to /etc/init/ in 2006, for example. And it has switched from that since then. "Updated for 2017" that page most definitely is not.
Thanks for your feedback. Both issues you mentioned -
the missing 'd' in '/etc/systemd' and Ubuntu being updated for systemd (and me forgetting that Ubuntu's old SysVInit was different than Red Hat's) are now fixed.
The doc was made from scratch last year with a massive amount of original research. SmartOS and OpenBSD folks have already contributed. Saying its 'almost as many glaring deficiencies and errors' is wrong.
On the contrary, it is alas very right. The problem appears to be that you do not see these many glaring deficiencies and errors.
Two examples are right here.
I pointed at the glaringly deficient systemd operating systems' columns, as compared to the FreeBSD and SmartOS columns, and you did not even see that, and simply changed a directory name. It's glaring because it's basic stuff that is right at the top of the systemd.unit manual page and in most of the introductions to systemd that one can find, as well as being one of the concepts that the systemd people tout about systemd.
I mentioned that Ubuntu switched to /etc/init and you talked about "Ubuntu's old SysVInit" and did not see a glaring error. Ubuntu stopped using van Smoorenburg rc, as I said, in 2006. Ubuntu's /etc/init for roughly a decade from 2006 onwards is not "SysV" anything.
Similarly, the OpenBSD column is glaringly erroneous as one can see by simply comparing it against the very page that its entries hyperlink to. The actual OpenBSD page does not say any such thing, and if this work began last year there was not the excuse that it began before OpenBSD worked the way that it now does. OpenBSD has worked this way since 2015. Again, "Updated for 2017" that page most definitely is not.
Incidentally, it comes up as a completely blank page without JavaScript. Bruce Hamilton's page headlined here has the distinct advantage of not requiring a more than 30-thousand-line 2.1MiB JavaScript program running on every reader's WWW browser merely in order to have some HTML text in an HTML table. The HTML text in the HTML table just works, even when there is no JavaScript.
And in the time since I wrote the first message it has started coming up as a blank page with JavaScript. Google Chrome tells me that you have a syntax error buried somewhere in the middle of a 527-character-long opaque single line of those megabinarybytes of JavaScript.
Uncaught SyntaxError: missing ) after argument list
> Ubuntu's /etc/init for roughly a decade from 2006 onwards is not "SysV" anything.
Yes but nobody has ever used Ubuntu's init as upstart. It was always used via SysVInit compatibility and documented even by Ubuntu as such. This explains why Ubuntu finally dropped Upstart.
> Similarly, the OpenBSD column is glaringly erroneous as one can see by simply comparing it against the very page that its entries hyperlink to. The actual OpenBSD page does not say any such thing
Which? Every single OpenBSD entry is wrong? Are you completely sure about that, or are you using hyperbole as an excuse not to contribute?
> it comes up as a completely blank page without JavaScript.
Yes. JS is required for behavior. That's what JS does.
26 comments
[ 3.0 ms ] story [ 63.7 ms ] threadYou learn something new every day.
Also learnt something new.
Here's another fun Apple Unknown: https://www.youtube.com/watch?v=-h4t33tOG60 [Linus Tech Tips] https://www.youtube.com/watch?v=Yz05U67NecI [Obsolete Geek]
As someone who thought Classic Mac OS was a pretty cool ui, I have to say it was fairly awesome.
It's been so long since I've touched OpenServer (say, ~20 years) that I can't remember if the technical bits of the page are actually OpenServer or UnixWare (I'd say OpenServer). OpenServer had Xenix as a predecessor and, though I didn't work with UnixWare at all, what little I did play with it made clear there were some substantial differences.
All of this is all but historical trivia now, but I'm sure there are at least some OpenServer installs running out there... somewhere....
While SCO licensed Xenix from Microsoft and kept the port going through 386 support, SCO Unix/ODT/OpenServer/UnixWare all descend from a separately licensed SCO System V release 3 port, not Xenix.
Disclaimer: I worked for the company that wrote the (in)famous C2 security subsystem for SCO.
Old way:
New way:* https://freedesktop.org/software/systemd/man/runlevel.html
* https://freedesktop.org/software/systemd/man/telinit.html
These things do not actually exist in systemd at all, outwith a few compatibility shims. And the same can be said of FreeBSD, too. They don't actually exist in FreeBSD, or indeed any BSD, at all, outwith compatibility shims such as FreeBSD's init command. (The FreeBSD init compatibility shim really is not recognizing the command-line arguments as runlevels in any real sense, especially since it does not recognize the numbers 2, 3, 4, and 5; the very numbers for which the run part of runlevel is appropriate.)
Note that the systemd compatibility shim completely ignores the actual "runlevel0.target" targets; that there is no "init table" of runlevel stuff; and that the separate run levels in /etc/rc[234].d are all combined into one by systemd's backwards compatibility service unit generator. This stuff genuinely does not exist in systemd.
* https://unix.stackexchange.com/a/196014/5132
* https://unix.stackexchange.com/a/233581/5132
* http://jdebp.eu./FGA/inittab-is-history.html
Arch Linux users don't even get the compatibility shims.
* https://unix.stackexchange.com/questions/389289/
(this is on Ubuntu, but anything with systemd should be similar) You're correct about systemctl. If you do:
you can see that `poweroff` and other commands are symlinks to `/sbin/systemctl`. The systemctl code shows it checks the name it's called with and chooses an action based on that:https://github.com/systemd/systemd/blob/aaa6732d7834c1dc0f93...
Well, they wouldn't want to break that kind of backwards compatibility, now would they?
https://certsimple.com/rosetta-stone
Including:
- macOS
- OpenBSD
- FreeBSD
- SmartOS
- Red Hat Enterprise Linux (and CentOS) 7
- Debian/Ubuntu
- Arch Linux
- Windows (assuming PowerShell per recent Windows versions)
This includes all the systemd commands where relevant, and current macOS as other posters have been mentioning.
* In one of the several systemd errors, it describes "system" and "package-related" service directories for FreeBSD; and "user, "system", and "package" service directories for SmartOS; but states that all unit files are stored in the /etc/system tree for the systemd operating systems.
* A whole bunch of stuff in the Ubuntu column is around 11 years out of date. Ubuntu switched from /etc/init.d/ to /etc/init/ in 2006, for example. And it has switched from that since then. "Updated for 2017" that page most definitely is not.
If there's anything else wrong, just edit: https://github.com/certsimple/rosetta-stone/blob/master/rose...
The doc was made from scratch last year with a massive amount of original research. SmartOS and OpenBSD folks have already contributed. Saying its 'almost as many glaring deficiencies and errors' is wrong.
Two examples are right here.
I pointed at the glaringly deficient systemd operating systems' columns, as compared to the FreeBSD and SmartOS columns, and you did not even see that, and simply changed a directory name. It's glaring because it's basic stuff that is right at the top of the systemd.unit manual page and in most of the introductions to systemd that one can find, as well as being one of the concepts that the systemd people tout about systemd.
I mentioned that Ubuntu switched to /etc/init and you talked about "Ubuntu's old SysVInit" and did not see a glaring error. Ubuntu stopped using van Smoorenburg rc, as I said, in 2006. Ubuntu's /etc/init for roughly a decade from 2006 onwards is not "SysV" anything.
Similarly, the OpenBSD column is glaringly erroneous as one can see by simply comparing it against the very page that its entries hyperlink to. The actual OpenBSD page does not say any such thing, and if this work began last year there was not the excuse that it began before OpenBSD worked the way that it now does. OpenBSD has worked this way since 2015. Again, "Updated for 2017" that page most definitely is not.
Incidentally, it comes up as a completely blank page without JavaScript. Bruce Hamilton's page headlined here has the distinct advantage of not requiring a more than 30-thousand-line 2.1MiB JavaScript program running on every reader's WWW browser merely in order to have some HTML text in an HTML table. The HTML text in the HTML table just works, even when there is no JavaScript.
And in the time since I wrote the first message it has started coming up as a blank page with JavaScript. Google Chrome tells me that you have a syntax error buried somewhere in the middle of a 527-character-long opaque single line of those megabinarybytes of JavaScript.
Yes but nobody has ever used Ubuntu's init as upstart. It was always used via SysVInit compatibility and documented even by Ubuntu as such. This explains why Ubuntu finally dropped Upstart.
> Similarly, the OpenBSD column is glaringly erroneous as one can see by simply comparing it against the very page that its entries hyperlink to. The actual OpenBSD page does not say any such thing
Which? Every single OpenBSD entry is wrong? Are you completely sure about that, or are you using hyperbole as an excuse not to contribute?
> it comes up as a completely blank page without JavaScript.
Yes. JS is required for behavior. That's what JS does.