The English language has such a large vocabulary that no one may possibly be expected to simultaneously comprehend the whole of it...

Yet it is possible to express yourself concisely in the subset of your choice.

Write-only code is not the fault of the language, but that of the programmer.

So, Blue Origin just decided one day; "Hey wouldn't it be cool if we could land space ships at sea?" and went ahead and patented the idea without the foggiest notion of how this might realistically be accomplished?

And now there's a patent that provides the "what" but absolutely no detail about the "how" one might go about doing this?

I think we need to take a lesson from the past: bring back the law where before a patent may be filed it must first be backed by a valid working prototype. That should fix all those millions of spurious software patents filed each year too.

The current patent system constricts technology rather than acting as the enabler patents are supposed to be.

From this comment we know you are 45+ years old, as anyone younger doesn't have a Clue

Sorry, but this "just ain't so". On April 10 2010, in his article entitled "Rethinking PID 1", Poetering wrote:

Facts are facts, and we can't bend them to suit our purpose, or make up history as we go along.

That's the sort of apathy which could smile at you gently until it turns around and kicks you in the teeth.

Systemd changes a lot of things you take for granted. If it kept everything the same, no-one would be complaining, but then again there would be no reason for it to exist then either.

Well, actually, the issue was never whether or not Microsoft could ship it's own version of the JRE. The issue was rather that Microsoft had extended the Java API with it's own functions. Developers had started to use those functions, making applications written for the Microsoft JRE not backward compatible to Sun's JRE, and was thus subverting the standard.

Sun used the court to assert it's ownership over the standard, and the court ruled that Microsoft could not extend the standard. Microsoft, finding itself unable to embrace and extend with the ostensible view to usurping ownership of Java, decided instead to build their own competing product. Hence the birth of C# and the common language runtime.

The issue around Google's use of the API for Android is very different. The article says that the argument was that the Java API's are "needed to write compatible code" and so should not be copyrightable. If you followed the court case, you would know that the actual argument was that API's are not works of art, but rather a way to define a standard interface, and since copyright law covers works of art, API's should not be subject to copyright law. There were also a bunch of patents covered in the same court case, but these were ruled out relatively early on- with the exception of the rangecheck() function which was debated to death.

Android API makes no attempt to sell itself as a language suitable for back-porting apps to Java. Google did not copy Oracles implementation code for the Java API's, but does copy some of the Java API (definition, or application interface) code.

Android apps are initially compiled to Java ByteCode, but upon installation the Java Bytecode is compiled to another instruction format suitable for the Dalvik VM. There was another big hoo hah raised about Google copying the byte code, until it was realised that every Java developer on the planet does this too.

Google literally used the existing Java ecosystem as a working base, giving them a language and a compiler that produced Java Bytecode. They then built an installer that compiles Java Bytecode to their own Dalvic VM code format, and added a bunch of Android-specific libraries and API's on top if that. Oracle feel that although Java was made free by Sun, that there is "free", and then there is "free". They want their slice of the pie, and perhaps even deserve it. However, one gets the feeling that they may have had more luck by approaching Google directly with some sort of Java support contract than going to the courts on this one.

Command Lines? Where we're going, you don't _need_ Command Lines!

This one highly opinionated fellow, all on his own, wants to change the rules of the Internet??? Even if, by some miracle, he managed to change the IP laws of one country, what about all the others? The height of arrogance IMHO.

Ted Tso is not an "occasional person" by any stretch of the imagination. He has contributed hugely to the Linux development effort and is well respected for his technological prowess as well as his opinion. Look him up for his involvement since the early 90's in projects such as e2fs, /dev/random, and more recently the C++ ABI specification.

That's crazy. A great many of the "Myths" in the article were never under dispute to start with.

For example:

Postulate:

"Myth: it was not written in C"

Rebuttal:

"It was written in C. In fact ...."

You:

"Unless someone is going to dispute his responses to the myths..."

To which the only reasonable answer is: "No one said it wasn't written in C in the first place!" (sounds stupid, no?)

One can prove the merit of just about anything with this kind of roundabout argument.

The whole "Debunking the myths" article is one big red herring.

Systemd may be a great technological accomplishment, and may have many amazing features- and here we are using some silly "false myth" debunking article to try to prove it's technical merit. It's demeaning.

It's not, actually, The kernel is statically linked and has no dependency on glibc after it is compiled.

That, my dear fellow, is simply horrible. Ever heard about how the use of whitespace improves readability?

Biggest myths of systemd:

Systemd is a necessary replacement for init.d

Systemd is not necessary at least not for the greater majority of Linux users, nor is it a simple replacement for init.d. Systemd does far more than replace your system startup, replacing just about every system daemon it can- including inetd, logind, syslogd, udevd, and it does so in as incompatible way as it possibly can. Binary log files for example break every utility or app which depend on scanning log files (eg. tail -f logfile | grep ...).

Systemd is a result of careful needs analysis and planning by a mature team of developers

Nope. In Poetterings on words (Apr 2010) initial announcement: "Well, the current code-base is mostly my work, Lennart Poettering (Red Hat). However the design in all its details is result of close cooperation between Kay Sievers (Novell) and me. Other people involved are Harald Hoyer (Red Hat), Dhaval Giani (Formerly IBM), and a few others from various companies such as Intel, SUSE and Nokia."

In other words, the requirements specification, scope, analysis design, initial implementation all belong to Mr Poettering. Quite impressive for one chap.

Systemd is similar to upstart

Upstart did a small fraction of what systemd does, as described a year after the initial announcement. Upstart was restricted to indeed simply replacing init.d, and did so in as unobtrusive a manner as possible. You may as well compare apples to oranges, as compare upstart to systemd.

It seems to me that the referenced article, ostensibly debunking systemd myths, is an exercise in raising red herrings in quick succession, and just as quickly flattening each one. The real problems are brushed under the carpet.

That just has to be a Freudian slip