Answer: So that when someone browses to your URL they don't get malware injected into their browser by a MITM.
If your browser is vulnerable to injected malware then you're pretty much screwed already - an attacker just needs to trick you into visiting their site (which can have a perfectly legitimate SSL cert), no MITM injection required.
Google should do whatever it wants. After all, if I get annoyed enough by Google Chrome, I'll just switch back to Firefox or Opera. Only the ChromeOS/ChromeBook/ChromeBox users may be screwed (because they've made the mistake of locking their hardware to a specific vendor browser).
IE taught us that this kind of thing doesn't happen quickly - web developers _still_ have to deal with IE's buggy rendering, despite good alternatives having been available for 15 years. Ok, IE has got better but it's still not great. Users don't see this stuff as a browser problem - if your website doesn't work right then the users see it as a problem with your website.
StartSSL.com gives free Class1 and is preinstalled in every modern browser
And whilst I use StartSSL, it's a pain that you can't get free wildcard certs for your domain...
Well, it is pretty much like real life, but I'm not sure we want to be teaching kids "this is the crap you can expect fom life" rather than inspiring them to do more.
I did take a slight exception to this though:
But Steven and Brian are also everything frustrating about the tech industry. Steven and Brian represent the tech industry assumption that only men make meaningful contributions.
As far as I can tell from the story, Steven and Brian did nothing wrong at all - clueless Barbie fucks things up and then asks them to fix it, which they do. This bit of the story would probably be pretty similar if you replace Barbie with any clueless person (male or female) who's just infected a bunch of computers with a virus. What were they supposed to do in this situation?
An elite crowd trying to force on everyone else what they think is the right way? Thats one of the many reasons people are against systemd!
The maintainers (you call them "an elite crowd") of some distros have made the decision to use systemd because they think that's the right thing to do - someone has to make the decision, and if not the maintainers, who? Or would you prefer that the maintainers decide to do something that they think isn't right?
No one is forcing anyone to use systemd - the source is there for anyone to use as they see fit; Some distros have decided that systemd is the right way to go, some have decided to use other inits, you can either choose the distro (from a wide selection) that suits your purposes the most, or you can even make your own, no one is forcing you to use one particular distro.
Note: I don't really have any opinions about systemd, I currently use Fedora and it seems to work ok, but if I have problems then I can switch distros.
One thing I don't understand is how in the hell it is considered ok to have this in Debian STABLE? Maybe, in Fedora or OpenSuse but Debian stable???!
Why not Debian Stable? Red Hat Enterprise Linux uses systemd, so it must be good enough for enterprise use, so why it it not good enough for Debian Stable?
"systemd does the right thing by stopping normal boot and just boot into a safe, minimal shell. A quick glace in the log file (journal) will instantly tell you (using red letters for emphasis) that fstab is broken in such and such a way. A quick edit with Vim can then solve the problem." - did you miss these lines in his comment? Just how "far" is "far enough" ?
Well that would depend... If its your desktop machine then popping a shell on the screen would probably work(*). If it's a headless networked device then you're going to need the NICs brought up and sshd started.
(*) This isn't especially user friendly though... how about firing X up and having a nice GUI thing to fix the problem?
This kind of tight coupling is unheard of in Linux history.
Not true at all - stuff has been tightly coupled plenty of times in the past. Lots of stuff is very tightly coupled with udev these days, for example. And whilst I will agree that tight coupling is bad, its sometimes hard to see how it could be avoided.
The use of System V init allowed Linux to be comfortablef for UNIX admins looking for a less expensive or more widely installable solution, and the end of the use of System V init means that Linux is starting to head away from the UNIX operating systems.
Linux has been heading away from Unix systems for a long time. As a long-time Linux user, on the odd occasion that I have to deal with the likes of Solaris I find it feels *very* backwards by comparison... It's almost like going back to the 1980s...
What if it was someone attacking your sshd and making it crash when it failed?
By automatically restarting it, you just allow the attacker to continue trying to exploit it.
By automatically restarting it, you don't solve the issue that makes it crashing.
By automatically restarting it, you, most of the time, don't even see it restarted, so really not giving you any way to solve the real problem.
It's not that I don't find process monitoring interesting, it's just that automatically restarting can bring more problems than it solves.
As with any service, the "correct" action upon a crash is probably dependent on what the machine is actually supposed to be doing. Take for example, a dedicated web server - having Apache do down when under attack and not attempt to recover would be bad since the attacker will have successfully caused a denial of service with very little effort. Compare to a private telephone exchange, for example, which is running a web server purely for management purposes - a crashed web server is not a disaster, the whole thing keeps doing its primary job without it, so automatically restarting the crashed web service _may_ not be the best plan.
So I guess the answer here is "it depends" and therefore the administrator should be able to choose either option, so selecting an init system that doesn't support one of the options would be bad.
In the case of sshd, since it is potentially the only way to safely fix a broken server, allowing it to die permanently seems like a bad option to me. A better option would probably be to restart it and firewall off all but a few "safe" IP addresses. That way the administrator can still access the server from one of those IPs and the attacker can't cause any more damage.
A well behaving daemon shouldn't be restarted (except maybe for rereading config files), it should start and stay that way. If it crashes randomly, then you might try to find the bug.
Whilst I agree that you should fix a crashy service rather than restarting it each time it breaks, there are nver the less reasons why you may want to auto-restart the service:
- In the real world, you can't just shut down a service until a bug has been fixed; you need to continue running it as best you can while the problem is being looked into and fixed. So a stop-gap measure may be necessary.
- Whilst you may believe some software to be bug-free, this may not be the case, and in some cases it would be disasterous to discover that thre is a bug by finding a service permanently go down. Far better to restart it and log the error.
- Bits _do_ occasionally get flipped in memory or registers, so software may well occasionally crash through no fault of its own. It is reasonable to have something in place to mitigate this should it ever happen.
So yes, I agree, if a service is crashing all the time then it needs to be fixed, but that doesn't mean that you should abandon all possibility of recovering from an unexpected crash.
You should be using a bicycle for short trips of 2 miles or less...
Comcast offered a $50 cash card if we signed up for internet service with them. We signed up in May, and the card never came. We called and they denied that they ever offered the card. A few more calls later, they agreed that they offered it and said they would send it. It never came. Last month, five months, a final call was made and the card arrived.
Clearly they have a strategy of screwing customers, either through intentional scripting or extreme negligence.
Not just telecomms companies - I'm currently being screwed over by Npower. I was a customer for 18 months, during that time I got a single correct bill and had to spend hours chasing them to get the others corrected. My original contract gave me a discount on the billing anniversary (January) - they never credited the discount, so I raised a dispute in January and they agreed to credit it. Except it never got credited. In the summer I left them as a customer, filed a complaint (about the shiteness of their service and about the unpaid discount) and refused to pay the final bill as it was incorrect. They responded to my dispute, replying to my complaint about the poor service but ignoring my points about the incorrect bill. I re-raised the complaint and got an automated "we'll respond in under 10 days" reply - never got an actual response so I followed it up 10 days later, again no response. The billing department are now threatening to take out a court summons against me for the unpaid (incorrect) bill. The billing department say they can't do anything about the disputed bill or the threatened court action and that I will need to raise a complaint with the complaints department, completely ignoring the fact that I've already tried to raise a complaint several times and the complaints department won't respond.
So now I've sent 50MB of paperwork and telephone recordings to the regulator in the hope that they can beat some sense into Npower before I have to waste yet more time defending myself in court.
I'm left wondering if this is actually incompetence, or if their corporate policy is to conveniently "forget" to pay discounts that were promised a year ago in the hope that most people won't notice.
What this country needs is a good five dollar plasma weapon.
