The declarative units are definitely a plus. No question.

I was anti-systemd when it started gaining popularity, because of the approach (basically kitchen-sinking a lot of *NIX stuff into a single project) and the way the project leader(s) respond to criticism.

I’ve used it since it was default in Debian, and the technical benefits are very measurable.

That doesnt mean the complaints against it are irrelevant though - it does break the Unix philosophy I think most people are referring to:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.

If you believe composability (one program’s output is another program’s input) is an important part of The Unix Philosophy, then ls violates it all day long, always has, likely always will. ls also violates it by providing multiple ways to sort its output, when sort is right there, already doing that job. Arguably, ls formatting its output is a violation of Do One Thing, because awk and printf exist, all ready to turn neat columns into human-friendly text. My point is, The Unix Philosophy isn’t set in stone, and never has been.

With all due respect[1], did your own comment hit your fingerprint detector? Because it should. It’s extrapolating wildly from one personal anecdote[2], and insulting a broad category of people without showing any actual examples[3]. Calling people “markov chains” is fun in the instant you write it, but contributes to the general sludge of ad hominem dehumanization. All your upvoters should be ashamed.

[1] SystemD arouses strong passions, and I don’t want this thread to devolve. I’m pointing out that you’re starting it off on the wrong foot. But I’m done here and won’t be responding to any more name-calling.

[2] Because God knows, there’s tons of badly designed software out there that has given people great experiences in the short term. Design usually matters in the long term. Using something for the first time is unlikely to tell you anything beyond that somebody peephole-optimized the UX. UX is certainly important, rare and useful in its own right. But it’s a distinct activity.

[3] I’d particularly appreciate a link to NeoVim criticism for being anti-Unix. Were they similarly criticizing Vim?

What is FUD is this sort of comment: the classic combination of comparing systemd to the worst possible alternative instead of the best actual alternative with basically claiming everyone that disagrees with you is a ‘slashdot markov chain’ or similar idiotic crap.

On the first point, there are lots of alternatives to sysvinit that aren’t systemd. Lots and lots and lots. Some of them are crap, some are great. systemd doesn’t have a right to be compared only to what it replaced, but also all the other things that could have replaced sysvinit.

On the second point, it’s just bloody rude. But it also shows you don’t really understand what people are saying. ‘I think [xyz] violates the unix philosophy’ is not meaningless. People aren’t saying it for fun. They’re saying it because they think it’s true, and that it’s a bad thing. If you don’t have a good argument for the Unix philosophy not matter, or you think systemd doesn’t actually violate it, please go ahead and explain that. But I’ve never actually seen either of those arguments. The response to ‘it violates the Unix philosophy’ is always just ‘shut up slashdotter’. Same kind of comment you get when you say anything that goes against the proggit/hn hivemind that has now decided amongst other things that: microsoft is amazing, google is horrible, MIT-style licenses are perfect, GPL-style licenses are the devil-incarnate, statically typed languages are perfect, dynamically typed languages are evil, wayland is wonderful, x11 is terrible, etc.

I think that the problem is fanboyism, echo chambers and ideologies.

I might be wrong, so please don’t consider this an accusation. But you writing this sounds like someone hearing that systemd is bad, therefore never looking at it, yet copying it. Then one tries it and finding out that baseless prejudices were in fact baseless.

After that the assumption is that everyone else must have been doing the same and one is enlightened now to see it’s actually really cool.

I think that this group behavior and blindly copying opinions is one of the worst things in IT these days, even though of course it’s not limited to this field.

A lot of people criticizing systemd actually looked at systemd, really deep, maybe even built stuff on it, or at least worked with it in production as sysadmin/devop/sre/…

Yes, I have used systemd, yes I understand why decisions we’re taken, where authors if the software were going, read specs of the various parts (journald for example), etc.

I think I have a pretty good understanding compared to at least most people that only saw it from a users perspective (considering writing unit files to be users perspective as well).

So I could write about that in my CV and be happy that I can answer a lot of questions regarding systemd, advocate its usage to create more demand and be happy.

To sum it up: I still consider systemd to be bad on multiple layers, both implementation and some ideas that I considered great but then through using it seeing that it was a wrong assumption. By the way that’s the thing I would not blame anyone for. It’s good that stuff gets tried, that’s how research works. It’s not the first and not the last project that will come out sounding good, to only find out a lot of things either doesn’t make a difference or make it worse.

I am a critic of systemd but I agree that there’s a lot of FUD as well. Especially when there’s people that blame everything, including own incompetence on systemd. Nobody should ever expect a new project to be a magic bullet. That’s just dumb and I would never blame systemd for trying a different approach or for not being perfect. However I think it has problems on many levels. While I think the implementation isn’t really good that’s something that can be fixed. However I think some parts of the concept level are either pretty bad or have turned out to be bad decisions.

I was very aware that especially in the beginning the implementation was bad. A lot got better. That’s to be expected. However next to various design decisions I consider bad I think many more were based on ideas that I think to most people in IT sound good and reasonable but in the specific scenarios that systemd is used it at least in my experience do not work out at all or only work well in very basic cases.

In other words the cases where other solutions are working maybe not optimal, but that aren’t considered a problem worth fixing because the added complexity isn’t worth it systemd really shines. However when something is more complex I think using systemd frequently turns out to be an even worse solution.

While I don’t wanna go into detail because I don’t think this is the right format for an actual analysis I think systemd in this field a lot in common with both configuration management and JavaScript frameworks. They tend to be amazing for use cases that are simple (todo applications for example), but together with various other complexities often make stuff unnecessarily complicated.

And just like with JavaScript frameworks and configuration management there’s a lot of FUD, ideologies, echochambers, following the opinion of some thought leaders, and very little building your own solid opinion.

Long story short. If you criticize something without knowing what it is about then yes that’s dumb and likely FUD. However assuming that’s the only possible reason for someone criticizing software is similarly dumb and often FUD regarding this opinion.

This by the way also works the reverse. I frequently see people liking software and echoing favorable statements for the same reasons. Not understanding what they say, just copying sentences of opinion leaders, etc.

It’s the same pattern, just the reversal, positive instead of negative.

The problem isn’t someone disliking or liking something, but that opinions and thoughts are repeated without understanding which makes it hard to have discussions and arguments that give both sides any valuable insides or learnings

Then things also get personal. People hate on Poetteing and think he is dumb and Poetteing thinks every critic is dumb. Just because that’s a lot of what you see when every statement is blindly echoed.

It violates unix philosohpy

That accusation was also made against neovim. The people muttering this stuff are slashdot markov chains, they don’t have any idea what they’re talking about.

i don’t follow your reasoning. why is it relevant that people also think neovim violates the unix philosophy? are you saying that neovim conforms to the unix philosophy, and therefore people who say it doesn’t must not know what they’re talking about?

The people muttering this stuff are slashdot markov chains, they don’t have any idea what they’re talking about

I’ll bookmark this comment just for this description.

Huh, that’s a really strange limitation and I don’t understand it. I’ve reviewed the settings pages and I can’t see anything like that. When I click “Start a conversation” or “Post a job” I’m prompted for a title and body, and the body text takes several hundred words of lorem ipsum without complaint. If you reload and still can’t post more than one line, please message your posting to me (here or on LinkedIn) and I’ll add it.

California has a long history of setting a higher (per-state) bar on things like vehicle emissions and mileage, forcing companies to either build two of everything (“49-state” cars) or follow the stricter set of rules for everything – usually they decide to do the latter. California’s lawmakers are probably hoping this will go the same way, since GDPR led the way.

It seems they’re doing it to get the ball rolling so to speak. Europe, now California, who next?

Remember to set up ntp when you set up your server.

I was at Twitter when we deployed the first production deployment of mesos. It did not use “containers” as they are understood in the docker sense. We shipped binaries, there was a shared filesystem you could see if you logged into one of the machines your service was running on, and mesos set up service discovery to connect the local ports you were randomly assigned at boot time in an (iirc) env variable.

For mesos, and, I believe, borg before it, containers came after to make things easier.

Because those are built for containers. Containers came first. Maybe I am missing your point…

Honestly, I think it wouldn’t be too bad.

Artifacts would be shipped around as e.g. .zip files downloaded from HTTP servers, instead of containers pulled from container registries. Those artifacts would be tagged with metadata to indicate which runtimes they require, and nodes in the cluster would be tagged to indicate which runtimes they provide; the scheduler would schedule jobs based on those constraints. Kubernetes, at least, already supports this. On balance, I think dropping containers for this aspect of things would actually make the overall system simpler.

Resource limits and namespaces would need to leverage underlying OS primitives directly, rather than going through the container abstraction. Probably a proto-container spec (like OCI?) would arise from these requirements naturally. This is where things would get more complex.

In terms of a framework that would allow you to programmatically deploy (virtual) machines, get applications installed then configure those and start them, it’s basically what I built at my last job. I didn’t get onto any advanced features like automatic load distribution and automatic machine setups when the environment needs more resources but it was completely possible on the back of the basic features as well as the fact that the system did set up distributed (peer to peer and mastered) services together with their own encrypted virtual networks.

I don’t know what other advanced features are possible in Kubernetes/Mesos that wouldn’t work without containers but AFAIK the security isolation is still better for VMs than containers and the networking should be easier since it’s simplified by not having a machine effectively be a router for the containers.

If you’re reading the kernel mailing list, it can be assumed that you have some familiarity with the subject matter, and if not, you’re not missing anything crucial to the discussion here. Torvalds has decided not to point and name the implied party, probably to avoid another heated flame war on the mailing list.

Some context to get you up to speed:

He is referring to what is currently the most popular init system on Linux, systemd. systemd is a relatively recent development of Red Hat, and has been adopted by all major distributions. Prior to systemd gaining popularity, the init system was a hodgepodge of shell scripts, which clearly had its share of problems.

However, systemd has been adding more features to its resume. Besides just being an init system, it has also absorbed the hardware abstraction layer udev, it implements its own dbus daemon (a popular Linux message bus used to communicate between different services and programs), it has taken control of some power management features such as suspend on lid close for laptops, it implements login and virtual terminal handling, it contains a dhcp client and server, and it provides its own system logger using a binary format that can in practice only be used through the tools provided by systemd.

This attitude of trying to do everything from a single piece of software has proven to be somewhat controversial among Linux users, because the old UNIX mantra for software was “do one thing and do it well”. This is especially controversial for something as central as the init system, because it is always running and runs with elevated rights.

The lead developer of systemd has also responded to a few issues with some unpopular comments, and has in the past been in conflict with the Linux kernel developers by refusing to cooperate on certain issues caused by Linux and systemd interaction. systemd has also, despite its widespread use, been hit by a number of fairly serious bugs, some of which had significant security impacts. The simplicity and potential impact of some of these bugs has left many people in doubt over the general quality of systemd and related projects.

[Comment removed by author]

I thought I remember hearing that it was a double-blind selection process – which is generally considered a Good Thing (tm). The problem is that when you have only a small number of boxes to fill, it’s easy for the margin to be swept out in a double-blind system. I don’t necessarily think that there’s wrong-doing in the case that they did follow a double-blind selection method. They declared a process, followed it, and got a result they didn’t like; but was ‘true’ to the process in some sense.

I can see why there was disappointment in that result, but I don’t think the takeaway should be “This process is fundamentally flawed” – the process is very fair (it chose in a way that modeled the distribution, if you have 100’s of submissions, and 10’s of slots, 3% is likely <1 total talk), but in this case your goal isn’t to be fair, it’s to encourage the distribution to go up. You need, in some sense, to take an affirmative action[1] to ensure that the minority gets some minimum of representation.

What might be better in conference planning, then, is to have a portion (say, 75%) of the talks be chosen blind, and the remainder split absolutely equally based on diversity characteristics (race, gender identity, etc). Do not publicly disclose which talks are which, this allows a conference organizer to get a good sense of actual representation (by examining the 75% after they’ve been picked), and also ensure that some minimum amount of diversity in speakership is achieved. The benefit of this approach is that that minimum amount will always ensure that leaders from the minority community[2] is represented, which encourages other members of that community to engage and generally increase the number of people belonging to that group. As the sample rates change, you can start to assign fewer ‘reserved’ seats to that minority, since they will be accounted for accurately in the blind process (assuming all else is equal).

I think this is a growing pain, ElectronConf was using a blind selection process, but found it insufficient. That’s a good thing. They postponed the event, that’s an unfortunate thing, but indicates they value diversity more highly than the disruption they caused, that’s also probably a good thing, or at least neutral. I think that as they, and conferences like them, go forward, they’ll find ways to balance the host of concerns around ensuring that underrepresented subgroups get to participate in a way that positively effects the community. I think the thing that will be hardest to realize in these processes is the fact that being diverse and being fair are, in some sense, opposed to one another in this situation. Being 100% biased toward fairness will result in a net zero change to the makeup of the community, it is a male-dominated industry, and when you sample fairly, you’ll get a male-dominated result. If you really want something to be diverse, you have to ‘tip the scale’ towards it, and that’s a really hard thing for people (especially, it seems, people in this industry) to accept.

[1] I believe I’ve just said some words that might make people mad, I trust lobste.rs will react better than most places, though.

[2] Because if you’re speaking at a conference, you are a de facto leader of a community, perhaps not the leader, but a leader for sure.

Forcing users to change the password is needed. If you allow the users to shoot themselves in the foot, they’ll do it and blame you.

That’s what GS, RS, and US are for! Group, Record, and Unit Separator, ASCII 1D, 1E, 1F.

That actually gave me an idea on what to do if my shell scripts' input delimiters start being problematic and need to be worked around to accept input that has them.

The solution might not be to drop something that isn’t being used but to start using it more because it does have a purpose.