I don't think people understand the Unix philosophy. They think it's about limiting yourself to pipelines, but it's not. It's about writing simple robust programs that interact through a common, relatively high level interface, such as a pipeline. But that interface doesn't have to be a pipeline. It could be HTTP Requests and Responses.

The idea of increasing concurrency in a web application through small, asynchronous event handlers has a distinctly Unix flavor. After all the event handlers tend to run top to bottom and typically produce an output stream from an input stream (although it may simply modify one or the other or do something orthogonal to either like logging). The use of a standardized, high level interface allows you to keep the modules weakly coupled, and that's the real point of the Unix philosophy.

I think he's off his meds again.

Never go full retard. X is not even remotely as important as init. For one thing, if X dies, who will restart it? And do we really want computers that explode when the GUI dies? I, for one, would like network services to terminate gracefully. The whole idea of TCP/IP networks, the dominant network used with Unix, is peer-to-peer. I may well run both services and clients on my machine. If X dies, the clients may die (if they're not text and running in screen) but the servers won't.

So the argument is that since the kernel is complex, we should add more complexity, or that more complexity won't matter? That's an ignorant, illogical argument.

Systemd still has to be more complicated so that it knows how to run these other processes, which wasn't even necessary. init was never meant to manage daemons. daemons were meant to manage themselves, or be run from inetd. If you want more complexity, inetd is the place to add it. And for handling daemons which don't adequately manage themselves, there's daemontools. There was simply no need whatsoever for this to happen.

It is bad, because PID1 is now responsible for a bunch of things which could have existed in any other daemon. And rather than roll the things which actually make sense in together, everything is getting rolled together. So now not only do we depend on a complex kernel, but we depend on a needlessly complex init system. There was no good reason to put all of this stuff into the same daemon.

Yes, yes I can. And I did.

Does nothing a script can't do

Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.

No. That is the virtue. They are simple. Simplicity is still a virtue.

Making PID1 more complex makes everything more fragile and opens up security holes.

NIH

This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.

Lifting which should not be done by PID 1. And PID 1 has to be more complex than it should be just to handle those external programs.

It does a lot of stuff the init system shouldn't do.

cgroups existed before systemd.

Up to the init script.

Already handled by several init systems.

We call it inetd.

That is ignorance at best, or perhaps a lie.

You have no idea about anything, that didn't stop you. I see why you didn't log in.

So to be clear, it's more awful to have 1 out of every 9 people have to pass two people if they want to use the bathroom than to have 2 out of every 6? Because that's typical economy seating plans are 3-3.

It's not a religion, it's a principle. When it makes sense, you put it aside and get work done. The argument against systemd is that it doesn't make sense. systemd is a simple case of NIH because it provides absolutely nothing which could not be implemented with the existing daemons and some small shell scripts.

That's right.

That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.

Bullshit, they're still letting licensed commercial vehicles use the HOV lane. The fact is that HOV lanes are shit. They're a waste of space which accomplishes none of the stated goals. Simply adding another general lane does more to reduce emissions, because it does more to reduce congestion, and thus reduces idling — where vehicles without start-stop systems get 0 MPG and thus are producing pure pollution. They're always trying to justify the existence of HOV lanes with bullshit like this, but they still are unjustifiable.

Phones have big screens now, so they need armor anyway. So since you're going to put armor on the phone, you want the phone to get thinner, so that the phone with a case on it is still thin. Just making the phone thin allows the user to put whichever case on it they like, so they get to personalize their phone and you don't have to try to anticipate their needs, instead letting the whole world do that. And that's why having the camera really doesn't matter. In fact, having the bezel around it protrude from the camera probably helps protect that side from scratches. What's the problem, planned to slot-load the phone?

Is there anything in this whitelist?

It depends on your design goals.

In Asimov's story universe, the Three Laws are so deeply embedded in robotics technology they can't be circumvented by subsequent designers -- not without throwing out all subsequent robotics technology developments and starting over again from scratch. That's one heck of a tall order. Complaining about a corner case in which the system doesn't work as you'd like after they achieved that seems like nitpicking.

We do know that *more* sophisticated robots can designed make more subtle ethical systems -- which is another sign of a robust fundamental design. The simplistic ethics is what subsequent designers get when they get "for free" when they use an off-the-shelf positronic brain to control a welding robot or bread-slicing machine.

Think of the basic positronic brain design as a design framework. One of the hallmarks of a robust framework is that easy things are easy and hard things are possible. By simply using the positronic framework the designers of the bread slicing machine don't have to figure out all the ways the machine might slice a person's fingers off. The framework takes care of that for them.

I don't think you've really grasped Apple's design sensibility. Job one for the designers is to deliver a product that consumers want but can't get anywhere else.

The "camera bulge" may be a huge blunder, or it may be just a tempest in a teapot. The real test will be the user's reactions when they hold the device in their hand, or see it in another user's hand. If the reaction is "I want it", the designers have done their job. If it's "Holy cow, look at that camera bulge," then it's a screw-up.

The thinness thing hasn't been about practicality for a long, long time; certainly not since smartphones got thinner than 12mm or so. They always been practical things the could have given us other than thinness, but what they want you to do is pick up the phone and say, "Look how thin the made this!" The marketing value of that is that it signals that you've got the latest and greatest device. There's a limit of course, and maybe we're at it now. Otherwise we'll be carrying devices in ten years that look like big razor blades.

At some point in your life you'll probably have seen so many latest and greatest things that having the latest and greatest isn't important to you any longer. That's when know you've aged out of the demographic designers care about.

No, no I don't. I have electricity, but I get water out of the ground and have gas brought in on a truck.

Right. Because someone is charging for something, they're not permitted to use the lane. That's prejudicial, since both people who are not charging and people who are charging but have a license to do so are able to use the lane. So it's not ANYONE, it's ANYONE YOU APPROVE OF.

Real animals have traction control.