To be fair there's some circular reasoning here. A contract itself is only valid and legal according to the law of a particular nation. Those pieces of paper had no equivalence of legal meaning in the Native American culture prior to the founding of the colonies and the forced application of English common law.
Well, a treaty is between nations and the Native American had agreements between tribes (and trade) before the Europeans showed up. The European (and later US) treaties were not a new concept, just a new form and some new, particularly scummy, tactics.
There's plenty of room for both. Many useful, worthwhile applications won't ever really push a machine to its limits, rather they primarily involve bringing structure and order to mounds of complex business logic. And that's OK. Not everything needs to be optimized.
On the other side of the same token, many useful, worthwhile applications will absolutely depend on this level of optimization. There are some problems which simply can't be solved in a practical manner without it. And that's OK too.
There is no "turtles" issue here. Pid 1 is special - if it dies, the system panics. It is good design to keep pid 1 as simple as possible and put the complex job logic in a sub-process. There are only two things on unix which init must do: reap any children it inherits, and start something else to do the heavy lifting.
Even sysV init works this way. The current sysV init is very simple -- the invocation complexity lives in /etc/rc and the related rc.d scripts which operate as subprocesses.
"Smart people" is a silly thing to say. We're all smart people and sometimes smart people make poor technical decisions. Let the matter lay upon its technical merit, not upon empty platitudes.
> There is no "turtles" issue here. Pid 1 is special - if it dies, the system panics. It is good design to keep pid 1 as simple as possible and put the complex job logic in a sub-process. There are only two things on unix which init must do: reap any children it inherits, and start something else to do the heavy lifting.
If the kernel fucks up the system dies and the kernel is much larger than systemd. Either way most of systemd's functionality is in other subprocesses.
This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd.
There's a little piece of insight which seems to escape many: there is no serious technical reason why systemd must run as init. Systemd could have been written to coexist in a number of various ways following previous models, running under init and doing things for init.
Systemd is winning this war because it created the war, by conflicting with sysv init.
> Systemd is winning this war because it created the war, by conflicting with sysv init
Except Upstart also has config files instead of shell scripts. And both of them support all your old sysv init scripts. And writing the config files is so much easier to get right the first time than rolling your own goddamn shell script by default.
On a sort of related note, I have never had an interaction with daemontools that wasn't miserable. I always find the fact that it gets waved around like a bloody shirt in these discussions terrible and terrifying.
The article specifically says what you're saying: I don't think any of them have really been developed with replacing SysV init in Linux distributions or elsewhere as a goal. DJB daemontools certainly wasn't
Systemd is winning this war because it created the war, by conflicting with sysv init.
Upstart predates Systemd, systemd just has more traction.
Several of the systemd developers worked on upstart or worked on porting fedora to upstart. Lots of the design decisions- socket based activation vs event based, cgroups integration- were made because of things that were (and still are) broken in upstart.
Sure. What I think is unclear that I intend to highlight is that systemd (and yes, upstart) have intentionally and unnecessarily created this technical conflict.
well, I wouldn't call the technical conflict unnecessary - if there wasn't a need for a more featureful init system, then there wouldn't have been a motive to write a new one. As for the social conflict, that's just what you get with social groups experiencing change.
Your assertion is strictly false. All features of this new process invocation system could be implemented without making a "new init system." That's my primary point in commenting here. It is a false dichotomy.
> All features of this new process invocation system could be implemented without making a "new init system."
Er, no. A major feature of systemd is that it is declarative. You have hooks for running custom commands, but a unit file is declarative and easy to parse.
If you want to acquire more intelligence about an init script, you have to resort to disgusting hacks like parsing comments in order to get a dependency system working. And socket-based activation? Sysvinit is a dead end. It's the counter to "keep it simple, stupid": when you fail to capture enough information in your "simple" model, you are going to end up with more issues than if you had created a slightly more complex system.
We already do. I think most people in this discussion aren't realizing that the current sysV init system is an extremely small pid 1 /sbin/init, and most of the logic in external rc scripts. Moving rc scripts to systemd declarative syntax is fine.
The important part with respect to software architecture is less complexity in pid 1. Subprocesses of init can be safely updated and restarted. More code in init is a real problem -- that's why systemd as pid 1 is controversial.
At the same time, there is a point to be made for having things in a single process - this makes it much easier to ensure that the crucial parts of the init system are available and working.
I'm not sure this was the point of parent, but anyway, why would you want something like that? It's not like sysvinit has any redeeming feature, and you would still want to have systemd .service files. I could understand an argument like "/bin/systemd does too many things and ought to be split up more", but the rationale for having bad old sysvinit launch /etc/init.d/systemd.sh escapes me. Not to mention that you definitely don't want both systemd and sysvinit to attempt to launch scripts in /etc/init.d, when they don't have a .service...
But if systemd was pid 1 and something killed it, you would have a kernel panic. How is that better than a system with a bunch of unmonitored processes? At least with the latter you can safely bring down the system, instead of having a hard crash.
It can crash due to bugs it can't handle, or it can voluntarily shut down.
Try it:
vidarh@opus:~$ sudo kill -9 1
[sudo] password for vidarh:
vidarh@opus:~$
No effect.
In the case of systemd, if it runs into a non-recoverable situation, crash() in core/main.c gets called, which then proceeds to try to create a core dump and spawn a shell as an absolute last resort to give an admin a chance to take corrective action, which is already a step up from your typical init assuming the manage to get the part of systemd that runs as pid 1 (by no means all of systemd runs as pid 1) as stable/bug-free as your usual init.
Of course there's an uncertainty there, and they'll have to prove they can keep that part rock solid or it'll be useless.
There are plenty of ways to kill pid 1. The major concern is simply software error, which is another reason why the current systemd design is poor. But if you'd like a concrete example, go ahead and attach gdb and use your imagination.
Systemd can run without being pid 1. In fact, systemd can run without being root, and by default systemd now starts a systemd user instance when a user session is started (there's a pam module to do this), or you can run systemd with "--user".
So if anyone wants to run systemd as a process monitor like Daemontools, separate from pid 1, they can do so.
But there are technical reasons for systemd to run as init: A key feature is to precisely track whether or not a service is running or not.
sysv init can not do this. It can track whether or not an individual process started from inittab is still running, but for large multi-process servers this is not all that practical as a process monitoring method. Hence the proliferation of process monitoring applications.
More importantly, since there's no ordering or dependency control, I've never seen a system rely on init for process monitoring this way for all its services. In practice, a bunch of pieces gets started in the init scripts, and all monitoring ends up placed externally or you then start a process monitor like Daemontools.
The problem is that all of these process monitors depends on a relatively benign environment where they are not messed with, and where they themselves are so rock stable that they never end up orphaning the services they start.
In practice, while Daemontools for example is well written and as stable as it can be, by virtue of running outside pid 1 it is not immune to the effects of the surrounding system. It can, and does, end up orphaning monitored processes in a variety of circumstances (say the OOM killer runs amok after your system ran ludicrously low on memory).
When that happens, unless your app was exceedingly well written, and the vast majority of server processes I have to deal with on a daily basis are not, your process is now unmonitored and you have no good way of controlling the process other than killing it and restarting. Finding pid-files have been overwritten, or are empty (say the disk ran full too, while it was being written) and multiple instances running is a fairly common scenario.
By running as pid 1, systemd is protected against being killed. By then applying cgroups it can precisely track whether or not what was spawned is still running, even if it forks more stuff. By applying this to the boot process, it can provide this functionality to everything that gets started during boot.
This is functionality that init does not provide, and none of the process-monitors running outside of pid 1 can provide.
It may not solve problems you have, but I've had to deal with the fallout of process monitors running outside of pid 1 more than I care to remember.
It's funny you mention the systemd pam module. I just recently was configuring a new Linux mint install and enabled ldap and all of a sudden noticed logging in via the desktop or ssh would hang for over a minute. I tracked it down to the pam_systemd module. Not sure what the problem in there was though.
"But there are technical reasons for systemd to run as init: A key feature is to precisely track whether or not a service is running or not"
This is not true. Tracking a running service doesn't require being init. Any process can do it.
"sysv init can not do this."
Nor should it. Services running under sysV init can, however.
"More importantly, since there's no ordering or dependency control"
Yes, there is -- it's implemented by the rc system. It's crude, but it's also just a bunch of shell scripts and completely pluggable. The systemd logic could trivially be inserted here either in place of /etc/rc, or by something that sits directly under init and drives the rest of the process.
"In practice, while Daemontools for example is well written and as stable as it can be, by virtue of running outside pid 1 it is not immune to the effects of the surrounding system. It can, and does, end up orphaning monitored processes in a variety of circumstances"
Any process can daemonize away from a process manager. systemd adds cgroups for tagging or containing process trees -- this is possible under runit/daemontools and it would only take minor changes to the supervise process to instantiate the cgroup and supervise accordingly.
To be clear: Any process can add cgroup support to track forked children. Solving this problem by adding cgroup support has absolutely nothing to do with becoming init.
"By running as pid 1, systemd is protected against being killed."
No, that is false. There is no such protection -- killing pid 1 is easy. Rather, by running as pid 1 systemd will cause a kernel panic and bring down everything with it.
"By then applying cgroups it can precisely track whether or not what was spawned is still running, even if it forks more stuff. By applying this to the boot process, it can provide this functionality to everything that gets started during boot."
sysV already exports most boot ordering into subprocess. It is trivial to achieve these tasks with systemd as a child of init.
"This is functionality that init does not provide, and none of the process-monitors running outside of pid 1 can provide."
It is true that init doesn't provide these features, nor should it. Your second statement is false -- a common misconception as I've hopefully explained.
If you have any further technical questions about how one CAN perform all these actions as a child of init I would be happy to explain in detail.
The thing that strikes me as the very weirdest about all of this is that many of the systemd proponents seem to be incredibly animated and aggressive about systemd, but most of their arguments are either non-technical or completely wrong. Like, what's the motivation? Why have so many people gotten to this mentality?
"In contrary to Richard Gooch, I suggest not to implement service dependencies and runlevel handling in the Unix process no 1, /sbin/init, keep it small and simple, that is why I wrote the runit package"
I have to say yes, I would have no problem with being known for inventing a toilet brush, or flappy bird. I'd be proud, even.
I know that people can have strangely fragile egos but the idea of being upset for being known for something, no matter how benign, is completely foreign to me.
Because I have found the internet in general to be at times crude, ignorant and destructive. I don't want to concern myself with considering self-censorship to ensure self-preservation. Instead I chose to contribute anonymously so that I may challenge the status quo or speak truth to power without personal concern.
I assure you it has nothing to do with embarrassment. It's unfortunate, but speech often has very serious consequences.
I'm sure our friend the flappy bird developer feels the same way. With insults thrown his way constantly over the game and a massive popularity he wasn't ready for, I'm sure he wishes he was anonymous as well.
We're discussing different things. You're talking about fame and internet comments which have no real impact, at least, not to me. I don't have a problem with people insulting the code I publish under my real name.
I'm talking about the potential for real life harassment (folks calling my employer, showing up at my house, swatting, etc) if I were to say something controversial. I am specifically concerned with being doxxed and criminal harassment.
There's a vast world of difference between people making comments in poor taste over a game and the level people sometimes go to if they engage in an argument and lose in an embarrassing way. I would not recommend that anyone freely engage in internet debates in a non-anonymous fashion.
It really does, in fact, work that way. Vulgar language is pretty common both in OSS and, perhaps surprisingly, in private codebases. I assume you don't subscribe to LKML, or have never read the linux kernel source? grep -ir fuck in linux, you may be surprised at what you uncover.
I understand your point and on a personal level I agree. I maintain a level of professionalism in my own work. I find that kind of language ultimately unproductive.
However, the OSS world has a good deal of engineering talent that swears like a sailor and is, at the same time, quite successful. This is simply an observable fact.
You're totally right. There are plenty of super talented and productive people out there of all kinds. But that doesn't mean none of them are giving programmers in general a bad name. Some of them very likely are.
I'm much more interested in protecting individual freedom of expression than I am with worrying whether there are people out there who are so crass as to collectively judge the entire field of software development.
Code is speech. Open source projects often have a subtext of affecting a political or social change either within a software community, or sometimes beyond. In this particular case, my reading of the text is that Zed wishes to create a baseline of ridicule for those who would prefer to alter software to support extremely old browsers. It's a fair position, and while he may be able to make that point without vulgar language he may also be effectively speaking to his audience with his crude humor.
As merijnv noted above, if you feel so strongly about language you're free to not use his project. He is free to speak and code as he wishes and you are free to support what you wish. This freedom of expression is extremely valuable, not because the word "fuck" has any particular intrinsic value, but because it's a culture of permissiveness which enables people to speak their minds and attempt to affect change even if they're clumsy and crude with language. Because it allows comedy -- and everyone's perception of comedic value is different.
> Open source projects often have a subtext of affecting a political or social change either within a software community, or sometimes beyond.
One time, I almost used a custom license in one of my projects which would have required my users to read a controversial book that supported my stance on something. It was intended to be half-joking and half-thought-provoking. But I decided to abandon this and use a standard free license, figuring that it's completely the wrong venue to try to effect social change, and it would prohibit people from deriving any utility from my project. I wish all public software projects would do the same. I know, it's a pipe dream, but a man can wish, can't he?
> As merijnv noted above, if you feel so strongly about language you're free to not use his project.
It's not practical to avoid using a project just because I disagree with its attitude. And it makes no sense to boycott it on principle, as I don't think so highly of myself to think my stance on something like this will actually have any kind of effect. I only wanted to comment on this to open discussion about the matter.
Sure. But do keep in mind that truly outrageous speech and behavior really does tend to have a devastating effect on the success of projects. We don't see that here because the speech really isn't outrageous or hurtful -- it's merely comedic and vulgar.
You may want to consider that your personal values aren't representative of the norm.
I think a better analogy are the kind of programmers who make the kind of sexist jokes that you'd find in an Eminem song. This attitude proliferates and becomes such a general stereotype about "programmers" that it gives rise to activists[1] who work hard[2] to fight it.
So what makes the analogy better isthatthey promote the stereotype that programmers harm people. I agree, this is the same kind of group self policing that Bruce Schneier would describe in The Dishonest Minority when for example local merchants screw tourists. Although individual reputation isnt affected, the group reputation is.
Price elasticity is strong, but the original comment is presumably assuming you can make a decent revenue with a non-minimum price tag.
For instance, imagine a game listed as free:
- a freemium model let you play 15 levels and asks for 4.99 to unleash 500 more levels, maybe let a 1.99 option for 100 levels; this should convert 3-5% with a million testing players; v.s.
- free-to-play with locking levels every 10 levels that are so hard you have to use bonus, that would convert 1% to pay for either a Golden Orb for 1.99, or a Golden Blast for 5.99, etc. each who may or may not make a difference, and appease your frustration, and work only once. You get a couple of whales (desperate, clueless players) who pay 50$ a month, but even with a larger distribution (two to three millions players) you don't break even.
The idea in the original comment is not that a price twice higher will double sales, but more that having a price tag (which free-to-play games deny having) makes sense for good games.
An overflowing food barrel represents very little in value, compared to the large cash donations made by wealthy techies. Cash donations are buying entire warehouses of food that you just aren't seeing.
My girlfriend volunteers full-time for the local food pantry. It was formerly an independent nonprofit, but a few years ago it was taken over by United Way.
Since then, any and all cash donations, given on site at the pantry itself, are funnelled to United Way. The pantry never sees a single cent of the money and United Way does not provide any food (UW employs two people and sends a truck periodically that delivers food from an unaffiliated food bank). No one who works there has any idea where the money goes or what happens to it. The employees there are not allowed to explain this to donors. The donors, of course, have no idea either.
The pantry is only allowed to keep tangible foodstuffs that are donated directly to them, which they can then give to people who need it. The pantry often runs out of certain types of food. When they do, there's nothing they can do but hope someone will donate more of that specific item, meanwhile watching as the cash donations that could be used to buy it get sent away.
I realize this sounds implausible and I can't cite any sources for it[1]. Just be careful about the assumptions you make regarding where the money goes. Food is food and people can eat it. Money can get funnelled or turned into other things, and unless you're there to watch it happen, you don't know what's going on.
[1]: Howevever, if you haven't already, read the Wikipedia page on United Way sometime and see if you can figure out what it is that they actually do, other than collect money, build bureaucracy and get involved in major scandals.
You could check http://www.charitynavigator.org/ to see what ratio of the money goes to programs vs. admin costs and funding costs. The navigator has many entries for United Way as it seems each region has its own organisation.
Understood and agreed with, but you know as well as I do that advertising matters. You said it yourself, people "just aren't seeing" the entire warehouses of food. Empty donation bin means a snap judgement to "heartless."
According to the weekly Kroger ad for their store in north Fort Worth (Texas), a can of Simply Organic beans (very tasty beans, I should add) is $1 with a Kroger card; the same goes for a can of Hormel chili (no beans in chili, please). My back-of-the-mousepad calculations say that approximately 37 regular cans will fit in a 55-gallon drum, the kind usually used for these food drives. That means that, in a regular 8-story office building with two deposit locations per floor, filling all of them to the brim will cost $592. If you go the other way and just put three cans in the areas visible to the public, that's $111 to make a small but visible impact.
Yep, it's advertising and showmanship, but that food also does go to people who will actually use it, so it has the benefit of doing a little bit of good, unlike most advertising.
I understand your argument but frankly I don't buy it. I don't think filling up inefficient bins of food on closed tech campus is visible to anyone outside the company; I don't see the potential for impact.
I'll be completely honest: I think much of this anti-tech sentiment (such as: tech people don't give) is wishful thinking and willfully divorced from reality. Most large tech companies have public giving foundations and publicize their donation programs. Here are a few examples:
These kinds of programs are strongly promoted at most tech companies. A large amount of giving happens outside these programs as well, but they do help establish a baseline well in excess of any food drive.
While trying to dig up the data for some of the bigger tech companies in the area I also stumbled across this report, which claims that area workers not only donate above the average but spend significantly more of their time actually going out into the community http://ef.siliconvalleycf.org/blog/bay-area-companies-giving... The article throws around the term "average" a lot which tends to raise my eyebrows, but it does mesh with my anecdotal experience that tech workers on the whole care a lot more about their community in the bay area than workers in general in other regions of the USA.
Companies do a fair amount of giving, but on an individual level, the Bay Area isn't particularly generous. San Mateo county is in the bottom 1/3 for '% of income given', Santa Clara in the bottom 1/4, SF is a bit better and is in the 42nd percentile for counties.
No, it's not dumb. It's merely suboptimal along the one metric you've chosen to measure. I'm including "show of good will" as a secondary metric, hence why it's perfectly sensible to donate in both forms.
It also creates expectations of help, which can also be very harmful in the long term. Helping others should be voluntary, not done because of expectations.
Pardon, but it's very clear. Take a look at the charitable donation foundations at various tech companies, many of whom publish their donation levels. Or get out and talk to some charities in the area and ask them where their money comes from.
I'm sympathetic to the issue of social equality, but depression resulting in suicide is not a rational process. Addressing class issues will not eradicate this problem. The wealthy become depressed and suicidal too, for example: http://www.ibtimes.com/eric-salvatierra-killed-caltrain-payp...
Yeah, but that just means that those with mental illness -- hi, btw -- probably require more treatment than they've been getting.
A story. Up here in Vancouver, the police recently released a study showing that the thing we did in the nineties -- ending welfare and closing institutions for the severely mentally ill -- actually cost us vastly more, because the police ended up doubling as nurses/counsellors/social workers, and the additional training cost vastly more than the original division of labour.
What is the annual cost of leaving the hurt hanging?
