Forgot your password?
typodupeerror

Comment: Re:San Francisco is just an extreme example... (Score 1) 327

by evilviper (#46763399) Attached to: San Francisco's Housing Crisis Explained

There is a huge amount of land in California the middle class can afford: the Central Valley. The air is so bad you are almost guaranteed to experience asthma or allergies, but you can swing it on as low as 30k per year

That's not the only affordable area, by far. Half the state is desert, starting from just outside the L.A. Basin, and rent is extremely cheap there. The freeways make it possible to commute from bedroom communities there to large cities every day. And the air quality out there is great.

Those kids living in LA, SF, SD who make 30k per year? They basically live in squalor(for America). They value the coolness of those cities so much they are willing to live 4 to a 2-bedroom, or get their own place and live paycheck to paycheck,

People predominantly choose where to live based on family roots, or jobs.

Go out where land is cheap, and there's probably no jobs there. It may suck to spend half your paycheck on rent, but it's infinitely better than getting no paycheck... And there's always the American Dream aspect of it. Everybody thinks if they move to a rich area, they're going to strike it rich, too... Sort of an investment in your future that way. Never mind how few make it, and how many people move away after a few years.

"Roots" are pretty simple... if you've got lots of family in an expensive area, you're not likely to move too far away, even if you're struggling. It's a big scary break to leave all your friends and family, and the only area and culture you've known, behind, all for cheap rent you might not be able to afford on your lower wages, anyhow.

Comment: Re:Why spend another $700 for a car stereo (Score 1) 177

by evilviper (#46763263) Attached to: How Apple's CarPlay Could Shore Up the Car Stereo Industry

All I really need mounted in the dash is an AMP and speakers.

That's pretty much what ALL cheap car stereos have been doing for the past decade. Except they throw in a clock, USB & SD card slots for MP3s, and usually a radio.

How does $25 grab you:

https://www.amazon.com/XO-Visi...

Comment: Re:Closed source won here (Score 1) 518

by Eric Smith (#46762057) Attached to: How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?

Would you argue that if a Microsoft (or other vendor) SSL implementation was used by most of the world's web servers, this would have been less likely to happen? As far as I know, there's no reason to think that any other implementation, open or closed, would be any more immune to such problems. There is little or no evidence that closed source software is generally more reliable, or that substantial effort is made to audit it.

If you're arguing that it's bad that such a high percentage of the world's web servers use the same software, I might agree, but that is completely orthogonal to whether that software is open or closed.

Comment: Re:Honestly, the "OSS is safe" discussion is over. (Score 1) 518

by Eric Smith (#46762019) Attached to: How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?
That OpenSSL is open source is irrelevant. This bug could just as easily have happened in closed source software. Using closed source software does not give any higher confidence in the quality of the code; many studies (e.g., 2012 Coverity Scan Open Source Report) show generally comparable code quality, with some open source projects scoring substantially better than average.

Comment: safe languages (Score 1) 518

by Eric Smith (#46761973) Attached to: How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?

Heartbleed is a perfect example of why software should be written in "safe" languages, which can protect against buffer overruns, rather than unsafe languages like C and C++.

Of course, the problem is that if you try to distribute open source software written in a safe language, everyone bitches and whines about how they don't have a compiler for that language, and how run time checking slows the software down by 10%. Personally I'd rather have more reliable software that ran 10% slower, than less reliable software that ran faster. It's also crazy to turn off the run-time checks "after the software is debugged", as if the debugging process ever succeeded in finding all the bugs. As C.A.R. Hoare famously observed in 1973, "What would we think of a sailing enthusiast who wears his lifejacket when training on dry land, but takes it off as soon as he goes to sea?"

The "with enough eyes" argument, and "if programmers were just more careful" arguments don't justify continued widespread use of unsafe languages. Granted, safe languages don't eliminate all bugs, but they eliminate or negate the exploit value of huge classes of bugs that are not just theoretical, but are being exploited all the time.

I keep hoping that after enough vulnerabilities based on buffer overruns, bad pointer arithmetic, etc. are reported, and cost people real money, that things will change, but if Heartbleed doesn't make a good enough case for that, I despair of it ever happening.

Comment: Re:Caution (Score 1) 116

by evilviper (#46736293) Attached to: Linux 3.15 Will Suspend & Resume Much Faster

There's rather little point in suspending a server:

Those of us who do this stuff happen to disagree with you.

even ones that are off outside business hours are better off hibernating rather than suspending.

"Better off" HOW? Hibernation takes much, much longer on both ends, and the difference in power consumption between hibernate and suspend is nominal. When your cluster suddenly needs more power, you don't want to wait 10 minutes for POST, kernel booting, and copying quite a few GBytes from disk into RAM, when you can instead get up and running in a few seconds.

Comment: Re:Coupled with systemd and LinuxBios (Score 3, Informative) 116

by evilviper (#46736257) Attached to: Linux 3.15 Will Suspend & Resume Much Faster

The third big software factor is the BIOS. "coreboot", formerly "LinuxBIOS", is blazingly fast compared to most proprietary BIOS's. It has made some inroads but is still not available for any commercial systems I can find. So no matter what is done in the other two factors, the BIOS is still a limiting factor of suspend and restore delays.

POST has to be performed by the BIOS when restoring from hibernation, but NOT suspend. So no, the BIOS is NOT a significant "limiting factor of suspend and [resume]" operations.

Comment: Re:Rebooting is not a fix (Score 1) 136

by evilviper (#46727523) Attached to: Seven Habits of Highly Effective Unix Admins

On the flip side, spending six weeks fixing an issue on a single server running a non-critical, non-time-sensitive service which occurs once or twice a year and is 100% worked around by a reboot probably isn't an efficient use of your time.

In the long-term, it is. If you let issues like that continue to exist, then you'll get stuck with an unnecessary proliferation of servers, with each running just one service, so rebooting one doesn't take the others down.

Not to mention that you'll find that you get stuck maintaining multiple, overlapping services, because the first one wasn't reliable enough for the tasks some department decided to bring-in, later.

And also, I don't think I've ever seen a service that was non-critical and non-time-sensitive. Whatever it is, people won't even try to use it until the very last minute, when they need it to work immediately. It could be a damn web page that just hosts the phone extension list, and because HR needs to call someone about something simple, at 5pm on Friday, that server is now delaying everyone's paychecks. EVERYTHING ends up being varying degrees of critical.

Comment: Re:Rebooting is not a fix (Score 3, Insightful) 136

by evilviper (#46727321) Attached to: Seven Habits of Highly Effective Unix Admins

"Reboot does not fix anything, it just hides things".

That's not specific to rebooting... It's more a question of doing root-cause analysis, versus quick bandaids. I'm firmly in the RCA camp, but sometimes it's the companies that are to blame, rather than the individual admins. Some companies are heavily slanted towards always getting the quickest possible workaround, rather than ever actually finding and fixing the problem. It's one of those false-economies, like counting lines of code and similar.

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

Working...