how does systemd compare to solari's SMF?
I did not at all get along well with SMF. Too cumbersome for the little bonus it brings.

...except for shellshock.
that's a bug and got fixed.
prove me wrong.
and not with the classic file '-rf' as that's not executing but just plain parameter passing (which really should get fixed to be less likely to break stuff, i.e. fix GNU getopt)

is this from an old Microsoft presentation? Sound like it.
Yeah, systemd will make linux into windows, i.e. it will die. because if you want unmaintainable OS, just use windows, it has all the softwares.

systemd basically transforms linux into windows.
If you want to use windows, with it's hidden startup, binary logfiles and other cumbersome and useless administrator (non-)functionality then just go ahead and install windows. Don't shovel those silly concepts down the throats of millions of happy linux users.

I have seen similar stuff on other unixes, like AIX and Solaris. It's a headache, non controllable and impossible to debug. After linux goes to systemd, the only OS left with a file-based philosophy will be BSD and... HP-UX!

Maybe we can hope that HP-UX gets ported to x86 after Itanium is dead. And that HP never gets the idea "oh everyone else uses databases/xml/binary for system relevant data, let's just fuck it up and do the same"

Well my next linux is going to be non-systemd, and if there's none, well then it's to be a BSD.
After linux for the desktop never happened, linux in general will not happen.
It was a nice time, I'll move on.
Which BSD is the best "distro"?

well, looks like awk borrowed stuff from everywhere.
Like the invisible string concat reminds me of what echo does with it's parameters in the shell.

and it's still my preferred way of doing things.
I solved a lot of problems on codeeval.com with awk, and got quite good results. The code is really fast.

I love all languages which do not require the ;
So why bash, ksh and javascript listed?
If you do one liners, you need the ; but on separate lines the newline does the job as well.
Probably a reason why I may try to lean python. No ; there.

and this SMF may be coll and fancy, but it's a horrible headache for a "normal unix" sysadmin.
Why can't it just be simple files? Oh no, we need a frontend to dump in and out unreadable XML data.

Same goes qith AIX and it's internal database hiding stuff from the users.

So finally every unix and linux has it's own, incompatible "I want to do horrible registry like windows" hack just because it's cool and hip, but it's not useable.

Does systemd present a virtual filesystem where you can edit text files with vi and get the thing configured? That would be one idea with which I could still use my beloved broadcast sed commands to change configs on 100 servers.

subway cars? come on!

And how many libraries of congress?

you are not precise on one point

In unix world, this long known issue was only about the first filename. Typically with classig usage of tar, the first file is your archive, and all others are just filenames. unix/bsd treat them as filenames.

Now comes GNU getopt and "suddenly" decides that from now on it would be cool to have options anywhere on the command line. Result is that in GNU-world, tar is now vulnerable (and many many other commands) which had had no issue at all previously.

I would really like that getopt changes back to "if we see filenames, then consider being after --" or rather: stop parsing options if you find a parameter which does not match any option. That's the last one. Just stop there, do not continue. Leave the rest as it is.

the "first file in the list" problem is known to anyone doing unix since 30 years.
What's new here is that now the option can hide anywhere in the list.

Funny: in unix, the -file is lexicographically globbed onto first position (- comes before a, typically LANG=C)
in linux, you have some other oder... and it's first "a" then "-a" so the problem file does not come first. This would save one or the other exploit.... but getopt makes it so that the exploit works in any case.

it's not the bash problem
the problem is that getopt gives tar that there is a parameter.... which is in fact a filename hidden somewhere deep in the file list.

tar cf archive.tar file1 file2 -v file3 # is verbose on linux, is NOT verbose on UNIX (complains about inexisting file "-v")

GNU is wrong, GNU broke the inherent security in options parsing by allowing options anywhere. GNU is insecure.

It will still work... as it did in the pre-GNU world of things.
See this:
UNIX (tries to archive file -v instead of becoming verbose):
$ tar cf /tmp/a.tar a b -v
tar: cannot stat -v. Not dumped.

LINUX (suddenly is verbose, thanks getopt):
$ tar cf /tmp/a.tar a b -v
a
b

> If the first file name starts with a dash, how do you know it's a file name?

here all the other poster's arguments are valid. The first file being a -file has always been a concern in the unix world and programmers worked around that.
But what's new with GNU, is that if you hid a command swithc in a long list of filenames, it won't be seen as a file but as a command switch. And that's where you shoot yourself in the foot.
On old unix system this will never kill you: rm /tmp/file1 /tmp/file2 *
On linux, you are ready for losing all in you current directory's subdirs (or any other trickery of the original post)

no it does not
The shell is not doing the -rf
But it does the pipes, the rm does not do the pipes.
So a pipe charater will not open a pipe
And I also tested it, to be sure what I say.