Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Comment Re:Tokyo is tiny by comparison (Score 1) 103

I wonder if, in time, we will see a regression back to city-states once urban populations get big enough. Tokyo is basically its own country, and the same goes for SF, LA, and NYC.

I believe the limiting factor on country size is 1) communication ability, and 2) transportation (force projection) ability.

Roads were a major factor in the size of the Roman Empire, for example. City-states were common when there was no force regionally large enough to conquer the city. City states also needed to maintain farmland surrounding them, so they could remain fed.

Comment Re:Testing is not verification. (Score 1) 157

Bridges aren't designed and tested by "trial & error"--if they were then half of them would fall down within a few weeks. Neither are buildings or pacemakers or computer chips.

Should we also assume that rockets are programmed with the same careful methods you (conveniently) omitted?

Rockets are known to never fail, after all.

Comment Re:"Programmers" shouldn't write critical software (Score 1) 157

but they already have a far better safety record than the average human driver.

I want you to realize that the only source we have for this is Google. It's not from a scientific journal, or an independent research team, or an auditor, it is from the same people who want you to eventually buy their product.

Furthermore, I want you to realize that the Google team is very careful in what information they reveal. All the information they present is shaped in a way that makes them look good, and to increase demand for the car. Now, maybe they've built the perfect driverless car, and it somehow got off the ground running with a near-perfect driver record, but the information they've given us isn't enough to determine that.

Comment Re:Oh microsoft (Score 4, Informative) 140

I've written enterprise software, used by large banks and other corporations. Our software was so bad, I couldn't understand how it would help anyone, I'm sure the people who used it were slowed down by the process.

Finally I realized they did get one thing from it: accountability. If you've never been there, it's hard to understand how corporations are shaped by SOX compliance, and general accounting problems. If a $2000 purchase disappears at a startup, it's a minor problem. But at a large company, accountants will be looking for weeks to find what happened to it.

Those are the kinds of issues large companies deal with, and removing the accountability of the decision making process (of figuring out what software to use) and giving it to Microsoft is a real service for them. This is the same reason people use RedHat, even though RedHat gives their software away for free. It is one of those things that makes no sense to you until you've worked in that kind of environment.

Comment Re:Could have fooled me (Score 1) 221

No kidding. One of the scariest quotes of the article: "42 per cent of Canadians are able to read and understand newspaper stories detailing scientific findings."

The scary part is Canada is ahead of everyone else on that stat. Newspaper stories are not exactly deep in scientific detail and hard-to-understand words.

Comment Re:Final nail in the Itanium coffin (Score 1) 161

As the years have gone by, the x86 decode overhead has been dwarfed by the overhead of other units like functional units, reorder buffers, branch prediction, caches etc. The years have been kind to x86, making the x86 overhead appear like noise in performance. Just an extra stage in an already long pipeline.

And all that long pipeline takes power to run (recently this argument comes up in discussions of mobile devices more than in the server room, because battery life is hugely important, and ARM in the serverroom is still a joke). ARM chips sometimes don't even have cache, let alone reorder buffers, and branch prediction. When you remove all that stuff, the ISA becomes more important in terms of power consumption.

Of course, as someone else pointed out, they were comparing 90nm chips to 32nm and 45nm. Why that is a problem will be left as an exercise for the reader.

Comment Re:Mission Critical ... Red Hat... LOL.. (Score 1) 232

I started on RedHat, because it was the major distro at the time. Then because of the controversial RHEL/Fedora split, I switched to Slackware. The RHEL/Fedora split was a non-issue, but once I tried Slackware, I realized it was so much better, I never went back to Redhat.

My friend went to Gentoo around the same time. He never wanted to go back to Redhat either, for similar reasons.

Comment Re:effort, priority and severity. (Score 1) 98

I know how to engineer complex things. I looked at the eventual fix, and it should have been done long ago.

Furthermore, if regression tests are important (and they are), they need a suite of automated tests so those things aren't all being done manually.

Finally, it's not like the glibc team traditionally avoids breaking things.

Comment Re: microsofties here is your chance to party (Score 2) 98

It's an oldschool attitude to not touch things, from back in the day where software was so flaky that chances were someone had already 'exploited' the bug to do something non-malicious.

Ah, that actually makes sense, good analysis.

. It's pretty obvious from the description what the bug is, so saying you aren't going to fix it is, as you say, pure laziness.

This sort of thing worries me about glibc, and the attitude that 'bugs are no big deal' is a dangerous one that is infecting software developers all over.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...