...that it didn't melt down. We get it, MD, you don't like nuclear power.

He probably lives in the Northeast where everybody is doing what they can to bring on some global warming.

Failing to find what the theories predict is still an advancement in knowledge.

Failing to find what a theory predicts largely excludes it (assuming the experiment isn't faulty), and is a good result and useful science. Whether or not science reporters can grok that is a job for the PR department (LHC has a good one - c.f. Particle Fever).

The Supersymmetry folks did not expect to find a Higgs boson at 127GeV. ATLAS did find what looks like a Higgs boson at 127GeV.

If there were a guarantee that this particle is the Higgs, then there wouldn't be a need to continue upwards to test Supersymmetry. But it's not guaranteed - so not finding supersymmetric pairs at the higher energies will firmly rule out the Supersymmetry model (reassigning physicists to other models) and increase the confidence that the discovered particle is the Higgs.

Treat it like geometry. Everybody needs a semester of it, for exposure to an essential concept in logic/applied math, but anything beyond that should be elective. There's nobody who can't do basic programming who can pass geometry, but not everybody is cut out for it as a career nor enjoys it.

I wound up taking an extra year of trig in high school, but the most I've ever used it for is roof framing (actually the most approachable book on the subject I've encountered on trig is Roof Framing by Marshall Gross). But I took two years of Computers (mandatory for the nerd center I enrolled in) and use it every day. You never know what you'll pursue but it's certainly not going to be something you've never been exposed to.

If somebody winds up in accounting or some other ancillary field, they'll need the basics but not much more than that. Same goes for C&C programming, etc. - you don't need to go for a CS field to need some basic programming knowledge. But if you're going into cosmetology or horseshoeing you probably don't need any of it - fighting division-of-labor is a very poor economic premise.

5 years? Seriously? Sounds staged, like it's merely to give the APPEARANCE of being tough on Comcast instead of actually being tough when being tough is warranted.

Any student of history knows that corporate regulations are *always* written by the incumbent corporations, then the government passes them along with the veneer of incumbrance, to quell the angry populace (which ALWAYS falls for the ruse because the government schools teach an antagonistic regulating regime; e.g. Standard Oil). The proposed regulations are always the minimum level of concession that will assuage the People, until they forget about it next month, and then those controls are subsequently repealed, relaxed, or remain unenforced.

This is how the system is designed to work, so being angry at the actors only seeks to perpetuate it.

Redhat is based on Fedora. CentOS is as well - while CentOS base is the same as Redhat, they also take other Fedora features, such as Xen, when it's useful.

Isn't that beyond human perception?

No, its approximately the same resolution as my 24" desktop display (1920x1200) at 50".

I fully intend to replace my 4-arm LCD display rig with a single 50" panel as soon as a good 8K display hits $2000. I'm excited there's a connector for it now.

I believe I'll finally be done buying displays at this point, save for device failure. It's great when technology reaches the "good enough". I'm just not used to it after buying progressively better displays for the past 35 years (that 14" RGB display was so much better than the TV composite on the Apple ][ clone!). But, hey, I learned to program on a discarded 60's TV set, so some of this is simply a matter of comfort and productivity.

There's no point to the major version anymore, the only reason it's ever updated on the kernel is to make things more readable.

Agreed.

Having the year as the leading number doesn't imply major feature changes when you increment it, plus it solves the problem of huge minor version numbers.

It actually creates a problem where there is none. Same with the 2015.2 format, which I thought was the better plan before I read this thread.

Say we've got linux 3.20 now. It's easy for developers to think about what's on deck for 3.21 or 3.22 or 3.23 in terms of 'the next release', 'the one after that', and 'the one we're not really thinking about yet'.

When will those be released? I dunno - every other month, maybe? 2015.3 and 2015.5. Oh, but we slipped a week - now we're at 2015.6 and everybody has already been talking about 2015.5. It's just setting up a point of confusion in an environment without drop-dead release dates. The same applies for the work done in the December-January timeframe, just with the other digit.

What strikes me about that is that 21, 22, and 23 are meaningful for the developers but '3' isn't. So get rid of the 3. Do 22.1 if there's a revision, everybody can use (if $linux_ver > 22) without writing <=> overloaders, and then there's no arbitrary false semantic included any longer.

If releases continue on the every-other-month pace, we've got 322 years before '23' will be larger than '2015', so worrying about large numbers is still premature.

Did anyone ever use average to mean "mode"? I really truly doubt it.

Yes, usually when they're trying to sound smarter than everybody else (and then usually when they're not).

back to TFS's question: you know why Java is such a popular language? Because it's really helpful for helping the bottom 90% of programmers write stable code.

The 5% on the right side of the curve can go off in a corner and bicker about whether their Haskell monads or Python function decorators are more becoming of a "good" programmer, while industry gets back to work to churn out code that get potatoes from Boise to Omaha and helps grandma balance her checkbook.

Any reasonable economist doesn't want to see you using somebody who can implement Shamir's Secret Sharing from memory (on a napkin, just for completeness) writing the potato shipping-manifest code. The best thing you can do for a person is to place them in a position where they're being fully utilized and appreciated for the work they do.

To simply delegate removal by someone upon death?

Leave instructions and your password with your attorney? Or set of attorneys in disparate jurisdictions using Shamir's Secret Sharing, if you're totally paranoid?

AIX had this in 1990s.

and users too!

LISP machines had this in the 70's, so there's that.

So your use case allows for reboots - not every one does. And far more use cases allow for scheduled reboots, but not necessarily immediate reboots as soon as a security vulnerability is published.

Fedora-derived (e.g. EL7) and Ubuntu disros can use Redhat's kpatch support (but no patches provided in EL7 -updates yet) whilst SuSE has kGraft which as of November has had a real update stream available. People don't run these things because it's easier than rebooting.

Besides, fix your runtime problems, set up a test cluster, and monitor your systems better - relying on side-effects is never a good plan.

I love recompiling kernels and updating config files whenever I buy a new mouse.

Stop building your own proprietary PCIe mouse cards, knucklehead. You can buy a decent USB mouse for $12 now.

I can't possibly see this ever causing a problem with this because linux is very secure and there is absolutely no way for a malicious user to get elevated access on anything that runs linux. This includes android phones, which are totally invulnerable to hacking.

You should suggest to Linus that he make kernel features configurable so people can do different builds for different targets. Put it in a dot-config file or something. Maybe in a future release...

The Chunnel has been in or on the edge of bankruptcy for most of its existence.

Do you mean that it's been subsidized or that it's like a highly-efficient non-profit? The difference is pretty important relative to its perceived value. And I'm assuming they have a huge bond repayment, which would make any such endeavor challenging over a long timeframe (as with most worthwhile efforts).

It is a classic mistake to measure the benefit of infrastructure on the basis of "does it pay for itself in ticket sales?". The benefit to society may be much larger than the direct income generated.

If that's true, then the ticket prices can be raised - the amount people will pay for a thing represents how much they value it.

If it's a commercial benefit, then those costs are merely passed along to the next consumer in the chain on a given product.

Granted, this excludes unaccounted externalities where license have been granted to externalize (e.g. subsidies to airlines to fly out of Heathrow to Paris), but it's better to fix those problems than subsidize on a guess.