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.

This is pretty outdated, Netinfo Manager hasn't been part of Mac OS X since 10.4 almost a decade ago: https://www.macworld.com/article/1061097/netinfo.html

Also, Linux filesystems list ReiserFS, but no ext4.

Updated for 2017:

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.

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.

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.

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.

Lack of Plan9 so I leave it here: https://9p.io/wiki/plan9/UNIX_to_Plan_9_command_translation/...

Plan 9 is not a UNIX as such, rather an evolution of it given all the differences, specially when its last iteration was Inferno with Limbo.

Windows (cmd.exe or PowerShell) and OpenVMS aren't mentioned either.

I feel like this was meant to be printed off and hung on a wall.

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.

For shutdown, I use "sudo systemctl poweroff". I thought the other syntaxes were still working only for legacy support.

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:

https://github.com/systemd/systemd/blob/aaa6732d7834c1dc0f93...

This guide is severely outdated - I can't see any indication of systemd recognition in any of the Linux examples.

Yup. I mean as filesystems for Linux it listed Ext2, Ext3, and ReiserFS. A webpage like this is excellent to be managed via a wiki.

Runlevels still kinda-sorta exist in systemd.

Old way:

  # Change default runlevel
  sed -i -e 's/^id:.*/id:4:initdefault:/' /etc/inittab
  # Shut down
  telinit 0

New way:

  # Change default runlevel
  ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target
  # Shut down
  systemctl list-unit-files
  systemctl isolate runlevel0.target

The systemd people themselves state them to be "obsolete".

* 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/

Great overview! Very handy, however very poor layout in my opinion, I have to note that. Could really use some css

"This custom drawing feature now works in Mozilla/Firefox, in Opera 7.0 or better, and in IE 5 or better."

Well, they wouldn't want to break that kind of backwards compatibility, now would they?

> A/UX

You learn something new every day.

I've looked at this web-page several times.. never noticed that.

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]

When I read about a/ux sometime in the early 2000s I eBay'd a Mac quadra (you need one of the 68k models with an mmu) just to try it out.

As someone who thought Classic Mac OS was a pretty cool ui, I have to say it was fairly awesome.