But, why can't I just rip out systemd? Oh - because so many service projects/distros are only supporting systemd today that you have to have it around if anything you download in the distro happens to use the API of the non-POSIX POS that is systemd.

systemd core files are not written to disk as files - they are written to the binary log file - you have to extract the data first to run debug.

systemd log files are binary; you can't run grep or other text parsing tools against it for automation - unless you extract the data first.

systemd encourages abandonment of POSIX compliance - which is a key component of the interoperability between various flavors of Unix and Linux (I loved being able to write a shell script on a Unix machine, and copy it over to a Linux machine with little to no modification). Dennis Ritchie must be spinning in his grave right now at this bastardization of his brain child.

The only way to avoid this is to roll your own distro - or support distros that stay clear of it (I was shocked to hear even Slackware was considering support for systemd - given that it has always been as close to SystemV Unix-like that you could get in the Linux world. Thankfully - so far they have not succumbed.)

For people who run desktop machines for their own use - running applications in user space for the most part - systemd may be fine. For those of us running servers, with many man hours of system administrative automation in place - this spells catastrophe in the form of forced obsolescence of our custom code and automation.

As I read in one article - if systemd is allowed to prevail, then we can all kiss the days of an administrator controlling his system his own way goodbye. It will split the work of people who do development - and at some point they will not be able to continue; one case in point: http://alien.slackbook.org/blog/on-lkml-an-open-letter-to-the-linux-world/

From that article:

Last week I asked the SDDM developers to reconsider their decision no longer to support ConsoleKit because Slackware does not have systemd or logind and thus we need to keep using ConsoleKit. The answer could be expected: “answer is no because ConsoleKit is deprecated and is not maintained anymore” and therefore I had to patch it in myself. Of course, the ConsoleKit successor systemd-logind, written by the same team that gave us all the *Kit crap, depends on PAM which we also do not have in Slackware. One of the fellow core developers in Slackware, who is intimately familiar with the KDE developers community, has heard from multiple sources that KDE is moving towards a hard dependency on systemd (probably because they are going to need the functionality of systemd-logind). We all know what that means, folks! It will be the day that I must stop delivering you new KDE package releases for Slackware. That’ll be the day.

So this turn of events might be nice for some script kiddie sitting in his mother's basement....but for the rest of us who have to get work done with and through Linux - this is a royal pain in the arse.

While you say you aren't going to wield your patents offensively, we can't be absolutely sure you won't. It really comes down to an ethical choice to avoid them altogether, and fight them vigorously when they do come knocking on your doorstep, or to embrace them in the sake of 'defense'.

Power corrupts - and so does the power acrued from misapplied patents.

/AGREED/ If you are patenting software you are wrong.

I suppose people like this think Kernagan and Richie(sic) should be collecting royalties on every C application written since the dawn of time?

IBM also made an ergonomic buckling spring keyboard: the model M15 -

http://www.clickykeyboards.com/index.cfm/fa/items.main/parentcat/12675/subcatid/0/id/125888

Why won't anyone make a copy of that? (nudge-nudge Unicomp!)

I don't disagree with your overall premise: bureaucratic 'big design up front' methods don't work except for an exceedingly small subset of problems in the real world.

However, you largely ignore a key point that I think the IEEE is (belatedly) trying to address: our focus from a design perspective to this point has been first meeting the functional design criteria, and lastly security (if you have time to deal with that at all - which in my experience ends up being the first thing that gets cut when time is at a premium and pressure mounts to ship).

Security has to be seen as a core function of every application that plans on communicating across a network, and also for many that don't by necessity, due to their incestuous relationship to other systems running on a machine that do. I also think that if you start your overall design with security in mind - that will influence various factors of the design - from API construction, to modularity, to the design of the tools, and operating systems the resultant applications live on/in.

To do that well without any framework or controls would require every application programmer to be a top notch systems developer. In my experience the vast majority of professionals in the application development space will never rise to that level of expertise. But code must be written - and applications deployed as the appetite for more and more automation does not abate. There are not enough programmers competent in systems development to do the job without any help. So, what do we do?

I have a pretty good idea about what I think should happen - but I'm curious, what you would do given that reality (assuming you can't guarantee deep competency)?

This brings to mind the purposes of creating and using code in the first place:

Where you are the only person that needs to see and understand it - this is fine; it serves your purposes happily for you.

On the other hand, where the purpose of creating and using the code extends beyond one person, this structure does not serve that need effectively. This is primarily because, while it may function, it is too brittle to be maintained by a team of developers over many years through many iterations in design without considerable time and errors generated in the process.

From seeing things like this, I would argue that there are way too many clever programmers - and not enough smart ones.

Your assumption there is that the youngsters turn out new ideas exclusively. The best ideas I have seen came from people who were over 40; youth does not infer a monopoly on ideas.

Holy Christopher Columbus! Was it bring your favourite programming language to work month?

Seriously, this is a clear indication to me that this thing probably had all the halmarks of bad projects:

1. Design by committee - definitely little thought given to KISS. No unifying approach/structure.

1. No central control of the implementation standards.

1. No thought of manageability/longevity/lifecycle of the code base - expediency at the expense of resiliency.

Managing that brittle monstrosity is going to be painful over the long haul. I feel for whoever gets that job.

The questions for those of us in the business: Why do we continue the cycle of poor craftsmanship/performance? What can we do about it?

500M for a website isn't possible. Period.

Anything is possible. The real question: is it probable?

"The lack of a standard library however makes things just repetitious and error prone", doesn't follow. Why would you copy the same code over and over in your application? Are you 'copy-paste' programming? That isn't very smart. Even as minimalistic as C is - it still has subroutines - you could even put them in a separate file from your main application to be reused in more than one program. Code reuse isn't a magical property of OO languages exclusively. Your statement actually illustrates the point - people don't have a fundamental understanding that carries over into all other languages as your abstraction level increases. You don't run before you walk - but in teaching computer science and programming we seem to be trying to do just that with our students today - and the failure of this approach is starting to be obvious in the real world where the rubber meets the road - at least for those of us who have to waste time and resources fixing the results.