Become a fan of Slashdot on Facebook


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×

Comment Re:Stackoverflow didn't invent buckethead programm (Score 1) 167

Agreed. And while people might complain that it makes "buckethead programming" easier, the thing that's not stated is that it also makes it easier for good experienced programmers, which is a significantly better gain. After all, most of those "buckethead" newbies will eventually stop being such.

Comment Re:What a maroon... (Score 1) 387

Well, he did give a reason right there. Rather than slinging mud at the NASCAR crowd, he should be trying to anchor his message in a way that gets them excited about the scientific aspects of it.

I feel like Nye is generally really good at doing the latter, and this was just an unfortunate break in his cool. It can't be easy staying calm when you're debating morons. Everyone's got a breaking point.

Comment Re:Cargo cult programming and Stack Overflow (Score 3, Insightful) 129

But, there are a lot of low skill programmers and sysadmins out there who lean on these tools way too much.

The low-skill people would have been low-skill regardless. Tools do not make the person, they only help them to be slightly more useful. People said the same thing about IDEs ruining programmers, but I think they've shown to be a net positive.

Comment Re:Rampant closure of questions (Score 2) 129

Many closed questions have what I'd call "false nuance" --- the person did not boil the question down to what is actually breaking. Their questions are scattered -- something like "I'm doing X and Y using Z library, and it doesn't work". The experts reading them can identify the problem as nothing to do with X, only a tiny bit of Y, and not in anything related to Z. They know what should have been asked, and that it's an obvious duplicate had the problem been reduced.

I don't think anyone would argue that this is helpful to the person asking the question. The real question is how far should someone go to answer a lazily written question. Especially with SO's gamification shtick, people are less likely to want to deal with questions that waste their time.

Do questions with merit get closed occasionally? Definitely. I try to reopen them when they do. But far more often than not, closed questions really should stay that way. There's this great old document How To Ask Questions The Smart Way . While StackOverflow is significantly more lax than it would have them be, it's still good reading for anyone deciding to post.

Comment Re:Release now patch later give CEO big bonus (Score 3, Insightful) 367

Release now patch later give CEO big bonus for laying off QA (we have end users that pay to due that)

I've talked with enough folks in QA to know that in the majority of cases all these game-breaking bugs are known and reported by QA prior to a game's release. The problem is marketing has promised a specific date and they're damned well going to meet it even if it means putting out a day-zero patch and dozens of patches over the next several weeks.

Knowing this is why I'd be perfectly okay having reviewers down-rate a game for a buggy release. It's the only way we'll be able to show them this toxic behavior isn't what we want.

Comment Re:This article is pure FUD (Score 4, Informative) 291

No kidding. The thing continually suggests that Linux is insecure on all number of ways (none are mentioned specifically), and that Linus is indifferent toward security. It has this completely useless statement to try to create a false association between Linux and the Ashley Madison hack:

Versions of Linux have proved vulnerable to serious bugs in recent years., the Web site that facilitates extramarital affairs and suffered an embarrassing data breach in July, was reportedly running Linux on its servers, as do many companies. Those problems did not involve the kernel itself,...

Comment Re:Not a problem (Score 1) 161

The problem with the language they used is that any protocol they can't explicitly classify can be assumed to be encrypted. You run the risk of an unencrypted Youtube video getting prioritized over games, or whatever else is using custom protocols.

They should not be the ones to hold these reins. And I think that's the whole hold-up -- their focus is obviously that they want control, not so much that they want to limit bandwidth. Really, pretty much everyone involved who they consider a bandwidth hog would be happy to cooperate if tech was there to facilitate.

We should instead mandate that ISPs support an opt-in depriortization through some QoS extension to IPv6. I'm sure Netflix/etc. would cooperate marking their traffic as bulk if they could actually specify best-effort latency/throughput guarantees and configure their software to buffer/etc. to work with it. P2P software would probably be a good citizen too.

Comment Re:Say what? (Score 1) 392

The code for differing emissions profiles has a valid reason to be there (different rules for different markets, plus test tunes that stress various components, so there will be many tunes in the codebase).

Logically you are correct -- tunes are made up of a lot of different maps, and each region gets its own set of these maps. These maps are just tables that get interpolated -- e.g. for this RPM and this amount of air, use this much fuel and this timing.

However, each tune only contains a single region. If you look at it economically, there is no reason for them to put all the regions on a single ROM -- this just takes more space. They already need to configure by region, so why not make the entire ROM the configuration and save space?

I can't speak for all car makers, but the ones I'm familiar with do this.

Comment Re:You really make it hard (Score 4, Insightful) 308

I just had to post something against the classic /. hivemind. What do I do to myself. You see, I mentioned APIs specifically, because I was talking about their APIs. Not Office. Not their latest shiny UI throw up. Their APIs. I'm a dev, I've been using their APIs extensively for close to two decades, and that's the perspective I wanted to give. I wasn't commenting on the quality of Linux vs Windows IOT, or the benefits (or lack thereof) of backward compatibility.

you can go look up how .NET's incompatibilities between versions cause havoc. Don't forget to look up Win32 System API calls, especially in the security area.

Yes, you can.

Newer .NET versions tend to, in the vast majority of cases, be backwards compatible with apps compiled for older versions. They have broken this in some very niche cases, but only where strongly justified. Their wont for backward compatibility is so great, they will leave in bugs and even keep the internal structure of objects the same to ensure any apps relying on that continue to work. I've submitted my share of bugs that ended up in the "won't fix" pile due to this.

Their Win32 API is probably the single largest working example of "backward compatible" you'll find in an API. The thing is for better or worse riddled with deprecated functionality, "Ex" functions to replace it, and structs which need to know their own size. Run an old Win32 app from the Windows 95 days and there's a really good chance it'll still work today. There are very few cases where they've made something specifically not work, and that has sometimes been because people have been using it wrong to the detriment of the user (i.e. retrieving the Windows version).

Their driver side tends to fluctuate a bit more as they make performance or safety enhancements by replacing the various APIs, but there's really no way around that.

Comment Re:You really make it hard (Score 1, Interesting) 308

Dumping a system that works and does what I want for a system that spies on me and will change at the whim of its maker with but a "swallow bitch" if I complain.

You jest, but Windows is far and above king of backward compatibility as far as APIs are concerned.

One does wonder how efficient it is compared to Linux, though.

"Survey says..." -- Richard Dawson, weenie, on "Family Feud"