To be fair, I know what "kill -1" is for and I've never used it on purpose. Of course, that's because "kill -1" comes from the school of "fixing" the symptoms of the problem without understanding what's actually causing it.
Doesn't work for anything that changes a kernel data-structure. Only code-path changes. As a sysadmin, do you spend the time to know the difference?
But are they constructing additional pylons?
So much this.
The statement was very carefully worded "'It's clear that Brendan cannot lead Mozilla in this setting." The thing is, CEOs can have their career end in a heartbeat. Bad quarter? Stupid mistake? Bam! No more jobs. They are trusted to execute; no more, no less. This compromised that. He very likely wanted to leave, not because he was coerced by any action or inaction of the company--just because staying would effectively end his career (i.e. he could win the battle but lose the war, as it were).
There are two issues here--staying at Mozilla and getting hired somewhere else. The latter would have only gotten worse the longer he stayed. The former, well, his job just got infinitely harder no matter how you slice it. The sooner he got out the spotlight, the better off he is (and Mozilla is).
Is it fair to him? No. However, fair is not in the CEOs vocabulary. It's very likely this was his decision so he could go on to salvage what he could of the rest of his life.
Interestingly, the article says that, at the request of law enforcement, they added CAPTCHA support. The article then goes on to say that this must be a deception because they used a plural, it "doesn't make sense", etc.
Actually, it makes a lot of sense. How is every IED detonated these days? Cell phone. Buy a cheap, anonymous phone, wire it up, and call it to detonate it. Wifi that wasn't resistant to automated signup would make this trivial. They could just sign up with an anonymous phone and pre-paid Visa. Then, when it's in the air, *BOOM*
It also makes a lot of sense that they don't want to talk about it. Don't want to give people ideas.
Link to Original Source
Most programming confusion I've had to combat in the workplace comes from a fundamental misunderstanding of the two most basic facts of your program:
1. Where is your program's state stored? (NOTE: 90% of the time it's "the call stack" and 90% of the time that's the wrong place to put it.)
2. Where in your code is execution happening?
Threaded program generating weirdness? It's probably because you can't answer those two questions. Distributed program a mess to debug? I bet your state is smeared all over the place. Is your code a pain to port to an evented architecture? Bet you modeled your state badly. Can't map some failure to a certain, detectable set of circumstances? I guarantee your answer starts there.
For me, the answer to understanding these problems was found in functional programming. The no-side-effects stuff causes you to make all of your state concrete and also deeply understand what the call-stack does for you (or, more often than not, *to* you). The cruel reality, though, is that applying this hard-won knowledge *doesn't* seem lie in functional programming (or, at least, not LISP, Schema, Haskell, and crew).
If you're an academic, start with Hoare's Communicating Sequential Processes (http://www.usingcsp.com/cspbook.pdf), then learn Erlang (or Go, with a heavy emphasis on GoRoutines). If you're less Ivory Tower, try to grok this blog entry (http://blog.incubaid.com/2012/03/28/the-game-of-distributed-systems-programming-which-level-are-you/), then learn Erlang (or Go, with a heavy emphasis on GoRoutines).
This is so Fallout that it hurts.
I'm quite the proponent of researching molten salt nuclear. It's got some nice properties in terms of failure modes, is inherently anti-proliferation (so I hear), and has some nice options in the way of the thorium fuel cycle (the Chinese seem to have a real interest in this one, unsurprisingly).
Interestingly, molten salt SOLAR is actually quite nice for addressing the chief problem with solar (notably, the whole "sun goes down thing"). See here:
Right. You also get logging of the commands executed which can be nice, or can itself be a security problem.
However, unless you carefully restrict the commands, you can do what I do: "sudo bash" (or, if you prefer, "sudo -i")
A lot of companies aren't interested in full disk encryption and the like without key escrow. Basically, they don't want an employee to be able to lock them out without clearly displaying malicious intent (i.e. no "I forgot the password" defense).
This is entirely true. Apple is content to let the Nokia's of the world go out of business serving a market segment that pays less.
Is this socially irresponsible? Possibly. However, survival trumps social responsibility (in business as much as life). Apple almost died once, its success is effectively built on that core lesson.
Arguments about proprietary screws being a sign of corporate malcontent are as old as time. I, for one, don't see what's wrong about establishing a basic line of defense against casual intrusion. Having sat at the table with the lawyers and product guys, I recognize that no ulterior motive is necessary once the lawyers realize that an idiot with a screwdriver can dump a few ounces of lithium acid in his lap. They might actually request proprietary screws just to plausibly say that they tried to keep them out.
Said another way, this is like an ISP port-blocking the default telnet port. It doesn't stop people from hacking, but it does stop the dumbest and it makes it look like you tried.
TL;DR Perverse incentives are perverse.
Density. Most Apple machines are difficult to repair for the same reasons that Japanese cars are hard to repair. Once you hit a certain density, you just have to give up on making it easy to disassemble. To be fair to Apple, they just decided to go full out. If it's going to be hard to repair at the desired component density, embrace that fact and build it like it's not going to be repaired.
Now, recycling is another matter, but in terms of repairability, if you want a reparable Mac, get the desktops. They're perfectly easy to work on. If you want a mobile device, where weight, size, and battery-life are king--expect it to be hard to repair.