"there's nothing in it": if you are fluent in a dozen programming languages and in Unity then I believe you should be more careful with blatant affirmations. While I could argue that development of C# is vibrant and rapid, with features that are unique to it and don't have correspondents in other popular languages (eg. LINQ, aka first citizen support for data query support), I would like to also put focus on features that weren't removed because "developers are stupid", which was the driving factor in designing Java. As a clear example C# preserved support for value types, in comparison to many modern languages that chose to drop them, and this is an enabling feature for performance computing, as needed in Unity.

I think comparing two different languages on two different architectures is an unfair comparison. My point is that "always on" dynamic dispatch/binding must have some penalty cost, compared to a language that does by default static binding. Anyway, it's not that I care too much about performance in a language like ObjectitveC: dynamic dispatch has also other disadvantages like signaling at run time programming errors that could be actually spotted at compile time. Good point that first-citizen "interfaces" in ObjectiveC predates Java, I didn't know as I worked only with ObjC 2.0.

Of course all modern language copy features from previous languages. For example "Properties", intended as language first citizen getter/setter(s): actually it was already there in VisualBasic, which to my knowledge is the first language with a clear syntax describing them. My point in correlating Objective C 2.0 to C# is that, in my opinion, they picked several key features that represents the "vision" of how frequent productivity tasks are supposed to be handled in C#.

My comment about GC is that it arrived very late, not that it would help with performance. Still, I don't like a method binding mechanism that has heavy overhead in default usage. With this regard they seem to have improved the situation a lot in Swift.

Dynamic dispatch by default is a punch in the eye for performance. The syntax to expose this "message" based method call/binding is just horrible and hard to digest. liked the idea of "categories", that can be used to create arbitrary levels of accessibility of the interface, and also to add extension methods: C++ would have needed something like this. Also with Objective C 2.0 some good ideas (properties, enumeration, ...) were copied straightly from C#. I don't know exactly the feature set when the language was introduced, to compare with others, but to introduce garbage collection in 2006 is just fantastic late. They could have it done in the early 90's to be truly innovative.

I will reply only on 1) cause I'm more confident on that matter:
systemd doesn't recommends "Require" nor "After" concepts. Required concept to express dependency between services is using socket-based activation or other kind of activation that offers similar means of syncronization. That said, the classical Lennart's example, Avahi daemon can start when D-Bus IPC sockets are available. Other ways to start services in a deterministic order often hide race conditions or serious limitations in the way the system answer to dynamic events. For example: until not much time ago Samba server had to be fully restarted when Cups printers were available to expose them to SMB clients. Cups failures or delays in launching prior Samba would lead the latter to be unable to serve printers until a full restart of the service. The same was needed when printers list was updated. This of course was a sign of poor integration between the two services but it should give the idea: IPC is the only mean to synchronize between different services start-up and to express a true dependency. Also it: 1) allows to be intrinsically more efficient cause it doesn't require user-space polling. 2) it allows for circular dependencies to be properly resolved. That is: Samba depends on Cups for local printers but Cups may want to be aware of remote SMB printers. Acyclic graph to express services dependency, as you say, is a too strict condition for complex systems and it's not really needed to ensure proper system start-up.

That article has been cited many times as the incontrovertible source of flaws in systemd. It can be short and crystal clear but this doesn't change the reality that many arguments in it just mention potential, and not factual, flaws and security concerns in systemd. If the author find real bugs and truly disruptive design choice in systemd he should do as any good open source citizen: report it. This has already been done recently for the "debug" command line switch controversy.

In my first message I was chatty but I cited some. Anyway: cgroups, reliable mount handling (boot time barrier and during system uptime), socket and filesystem based activation. These features alone remove plenty of race conditions in services life cycle.

I support modern and technically superior software. I supported upstart when it was a clear improvements over sysvinit. I stopped supporting it when I understood their were unable to fix their own bugs and rethink wrong design choices.

Ok. What if I agree with you? The linux ecosystem is extremely wide and there already mission critical environments that can benefit from reliability enhancements that are now possible with systemd. To stress it again: I'm taking about reliability features, not faster boot or fancy services status report. So yes: init system must be taken seriously, no doubt. And I firmly believe systemd developers are very serious about it. At the same time I conceive appliances where systemd is just not the right choice and something simpler and minimal should be used instead.

ewontfix article has been demystified several times. Instead of pointing you links of commentary against it, I prompt you to read it carefully. The author is basically saying: we shouldn't take the risk of writing complex software. Because it's complex it can be security flawed and it can breaks the system if we introduce bugs. Let's keep a minimal init and continue as we always did. What the author is not saying is that the init software of modern operating systems have to be complex, because we expect it to have more features so it will be practically more reliable: I expect filesystems to mount reliably at boot, and services depending on filesystems mount or network resources to start reliably and with no race condition being possible. cgroups is a way to ensure all processes of a service are grouped and can be killed all together, without a single one "escaping". Simple, minimal, compact init systems *can't* ensure this. The shame is that upstart itself can't ensure this basic stuff: with regard to these aspects it still has an enormous amount of bugs that has never been fixed. #406397 to name one: confirmed and never fixed in almost 5 years, and also not taken much seriously because it would be the admission that upstart just can't reliably stop the services it starts. Also, the arguments of the author are very poor with regard to the upgrade/reboot controversy. Saying that it's complex, so it will need upgrades, so it will introduce bugs that brick the system or force me to reboot the system is just like saying: we are monkeys, we are idiots, and we should do nothing complicated because we would do it wrong it anyway. I'm a software engineer and this is the most foolish argument, and what is even more sad is that I continue to hear it. My experience tells me a completely different story: we can be smart, we can conceive and code very complicated stuff that will solve a wide range of problems, that will work as expected in most practical situations and have extremely low amount of bugs. At the same time it can be very elegant and coded cleanly. It's only about discipline, quality expectation and, more important, testing.

I don't have an opinion about Mir and I don't want to express my opinions about last Canonical moves here. What I want to say is that it would be Canonical interest to delay LTS to not risk Mir to become marginal in the years to follow. There would be nothing bad about this move: people that like to stay cut-edge will enjoy a regular 14.04 release. People that need stability will just keep 12.04 another six months.

Chiptune rules.

Kryoflux does it as is specialized for sampling, not for reading as many as possible disk formats.

As far as I know, the Software Preservation Society [1] managed to acquire a great knowledge of diskettes mass replication techniques and developed an high resolution sampler controller (Kryoflux[2]) that permits disk imaging and reinterpretation of the read flux, often permitting to decode the original data stream when other standard controllers just give up and fail with an error. Recently, they added support for IBM PC disks. Please correct me if I provided wrong details. [1] http://www.softpres.org/ [2] http://www.kryoflux.com/