Wat.

Really, wat.

A living wage FREES UP people to work on WHAT THEY WANT. The exact opposite of your only way of thinking outside of raw capitalism. No central committee. No five year plan. Just people, working with what they like at the pace they like. You know, like those who invented modern science and made huge advances used to do, when they were not contrained by the need to sell their time for peanuts.

Seriously, at least learn the first thing about your opponents arguments before you barge off into la-la land.

Correct, I can't understand it as that, because that is not what it means. A vast majority of both goods and services provided are not needed but merely *wanted*. Your failure to understand the difference is key here.

And yes, implementing a living wage will reduce some availability of luxury goods. In exchange it will increase the availability of investment capital and improve scientific advance rates, especially over the long term, immensely.

If your reasoning is correct, then everyone working in restaurants, stores and other service oriented jobs are providing zero to what "we have", as they do not make anything.

Having a job and making something is not equivalent. The majority of jobs in the US are in the service industry, and are non-productive in the sense of creating part of "all we have". No games with money can change that, as you correctly point out.

Therefore, the change in providing a living wage will be minimal. Those who are motivated and burn to make things will still be making things, and in fact, many who today have a job adding nothing to what "we make" will change that situation and *get* a job making things, improving the economy.

Keeping people trapped in low skill, non-production jobs just to punish them for not getting out of the trap cannot survive much longer.

Special chips for offloading the CPU are standard today. Your PC has a sound chip, a GPU and various other chips (or even whole cards) which offload the CPU. It scales just fine. That was in no way the downfall of the Amiga. Commodore being inept was.

So where do I insist on anyone using any particular tool?

You have a maturity problem because it's not enough to dislike something; you have to justify it by calling it obsolete, and insulting people who disagree with your attempt at justifying your opinion.

Maybe when you get to be half my age you'll know better. But I'm not holding my breath, youngster. Now git off my lawn!

I am quite curious how it's dogmatic to simply use the best tool for the job, without trying to make the claim that one or the other is "obsolete".

You've got a serious maturity problem, kiddo.

The editor you use is just as obsolete as vi. This is what you fail to comprehend and acknowledge. You make this into some form of "newer exists so the older is inherently inferior", and this is precisely wrong. Just because something does not fit in your brain does not mean it is obsolete. If anything, it is likely to mean *you* are obsolete.

I refuse to believe you use whatever serves your current purpose best because you present a dogmatic attitude. That means you will choose based on incorrect criteria. That you do not even realize this makes your position worse.

Where have I "insisted" there's "One True Editor"? Your arguments against vi grow out of some kind of small minded misunderstanding you acquired back when I was selling my first software commercially (if, indeed, you used it during the 1970's), and that is what I reacted against. Nothing else.

Maybe by the time you act your age you'll realize how absurdly you're acting, spitting venom on an editor you last used as intended decades ago (if ever) on a /. thread where using IDE's and editors as intended is discussed. But I won't be holding my breath. Keep pushing your opinion on what is the best editor for occasional one line edits on a thread discussing heavy duty programming as if it's relevant, no skin off my back.

That is the whole point of git, that you're able to work that way. It's not like a centralized version control system. Using git you do indeed get multi-file undo, and the ability to keep your own version history on exactly what you did when, to a level which no IDE can match with its own built-in tools. All without affecting the branch you're developing against until you're ready to commit.

And when you work that way, you're not tied to any IDE or editor, and you can do all manner of interesting statistics and analysis on your change history. Heck, you can even work fully without an editor or IDE and just integrate code using git.

The "average user" does not use an IDE, does not do programming and will use neither nano nor vim, and thus has no relevance to this /. posting. The average *developer* is quite likely to find the need to perform changes or updates on embedded systems or over dicey connections, and therefore has quite valid reasons to use vi which has nothing to do with your dislike of anything well tested.

"The rest of the world" tends to use vi and emacs. You're the one stuck in some form of rut, and posting to get that rut validated. Get with the times, vi today is not what you remember from back when you (possibly) had a valid opinion on the subject.

So the proper way is for the IDE to intentionally break the code?

I can't even begin to fathom such an approach. Worst of all, it's probably considered proper by a huge chunk of the people working with C++. Small wonder software projects are perpetually late, over budget and bug ridden.

Are you trying to make the case that embedded systems requiring text file reconfiguration and low bandwidth connectivity to such systems is something *rare*?

Indeed you are.

Remind me never to pay attention to your quite uninformed opinion.

Oh, and anything on a command line is "obscure" and "unintuitive" until learned. I don't find vi to be either. That you do speaks more of you than of vi.

Must be nice to only work with systems having plenty of resources and huge default installs. and always over high bandwidth low latency connections. Not all of us have that luxury, and the one editor you can always count on exists on a limited system, and the best editor for use over high latency connections, is vi.

If you know it well, that is. Otherwise you simply can't work efficiently under those conditions. Which you evidently never have to do.

If they needed more than 30 days, they could have said so quite amicably without lawyers (or with them, but in a friendly request manner) within a week, and asked the researcher to withhold release until they were ready. Instead they barge in, lawyers blazing, trying to suppress any and all information release.

That is an attempt to sweep the whole thing under the rug, and deserves only information release and the Streisand effect as a response.

39 total vulnerabilities, 7 high severity, 27 medium severity, 5 low severity.

http://www.gfi.com/blog/most-v...

Couldn't find that. It's in NVD though, if you're really interested.

https://nvd.nist.gov/

No it's not. It's still under development, and there is almost nothing left of the codebase from the original XP when you have patched up an XP install.

Otherwise Linux is TWENTYFOUR YEARS OLD, but you know, writing that in all caps as if it means something just seems silly. Because it is.

And hardly any of the Linux vulnerabilities allow a web client attack, like a whole slew of the Windows ones do. Because Linux does not have a web browser with kernel access. Therefore, the low level vulnerabilities in Linux are not like the low level vulnerabilities you are used to.