The legends on the main graphs appear to be wrong: According to the caption for Fig. 3, the blue curve should be 30-day plots, but the legend calls that 90 days. The legend doesn't make sense when you consider which numbers should be included in the others, e.g. that 0-day patches are also included in 30-day etc. Thus the green line is 0-day, the blue line is 30-day, the red line is 90-day, and the grey line is 180-day. MS has been around 60% 0-day +- 10% for much of the interval, except a dip to below 40% in most of 2004, and they are now up to almost 80% 0-day patches. The 90% 0-day patches in 2002 is impressive almost to the point of being suspicious. Apple has been climbing from 0% 0-day patches before 2003, managed to be above 60% for most of 2006, but fell to about 40% in 2007. For total patches within 180 days, MS has been in the 90% area most of the time, above 95% at the end of the study. Apple has been above 80% 180-day fixes most of the period, but only briefly above 90%.
I never knew the days when MS was liked as an underdog. Compared to Amiga, Atari, Mac etc their stuff has always been crap, their policies always been deplorable, and Gates has always been hated. Basic assumption of article wiped out.
As for Apple, I'm currently trying a switch from Ubuntu, and I'm only partially happy. Some of it may improve when I get some hacks installed (e.g. to get click-anywhere-in-window-to-drag and other real conveniences), but I'm quite worried about their closedness in general. They may have better bling-bling than MS will ever get, but there's very much a "we design it all" attitude towards third-party work.
The ability to climb poles (and legs) is cute, but apart from that, Xerox PARC had a modular robot in 2000 that could not only be a snake, but could reconfigure itself into a ball or a spider to go faster or to traverse difficult terrain. It was extremely nifty, but like so much else from Xerox PARC, they never capitalized much on it.
Part of the Ethernet spec is to wait 9.6 microseconds after the medium appears to be idle before sending, then resend if it collides. Light moves about 3 kilometres in that time. Making an Ethernet of 2550 km pratically guarantees nothing but collisions. So while this is a hunkin' heap of net, it's not Ethernet.
It'd be cool if TFA's headline was actually correct: Then we'd have a machine whose performance actually accelerated by a 10^15 floating point operations per second *per second*. That gets to be a lot of FLOPS real fast.
OTOH, it might just be the singularity happening. We wouldn't notice until it was too late.
Actually, the eureka moments are neither at the head end or the tail end. First comes a lot of digging into the field in one way or another, then at some point you get the "perspective change", then a lot of hard work is required to get it to something that works. However, that moment where the accumulated mountain of knowledge, ideas, intuitions etc collapse into a single new thing is exhilarating and noticeable.
Innovation is about as much sudden flash as making love is orgasm: It's the high point, but fairly brief. The rest is mostly perspiration -- and hopefully a lot of fun, too.
There, that analogy should derail enough nerd workforce that I can get my "innovation" out first.
Last time I bought an extension cord it had 4 different warning labels I had to take off. I wonder how many warning labels this flashlight will carry? Welcome to the Nanny Nation. I bought a folding step ladder while I lived in the US. It had eleven (11) warning labels on it. I think two or three of them were the same, but still... There's nothing mysterious about a step ladder like there is about electricity.
A torch makes perfect sense. They used torches before electricity and lanterns to light up dark areas. And to set fire to things before sticking in the pitchforks.
Amen. Any time you pick one language, no matter how brilliant or versatile, and only teach that, you're crippling your students. Noone would expect a carpenter to only know how to use a powerdrill. Some assembly is a must, to understand the lowest level of the machine. One each of procedural, object-oriented and functional languages should also be in the toolbox of anyone with a CS degree. We can discuss all night which ones they should be, but that's like quibbling over which textbooks to choose for a subject. Irrelevant.
What? Do they now have a CD drive that can read any part of the disc with no moving parts? Cool! No, but I don't expect my laptop to have an internal CD drive, for as rarely as I need it I'm fine with an external one. Also saves space and power, not to mention the internal "gotta spin up the CD just for fun" symptom.
I would give you the data on the direct comparison, but they haven't been published yet. Even over RAID-5, we get twice the speed without any warm-up time. And once you're talking high-performance HDD + RAID controller + extra disks for RAID + extra power for HDD + extra power for cooling, the savings on HDD are minimal if not gone.
Just looking at newegg.com, I find the current sweet spot of SSD to be 32GB, at $250. $7/GB, half down from what Wikipedia mentions for "late 2007". The price is not just falling, it's plummeting like a jumbojet with both wings shot off. I love it. Can't wait to get the last mechanical pieces out of my computers.
We have already been running tests showing Lucene to be several times as fast on large indexes and realistic queries using SSD than using normal drives. I'm going to have a smallish SSD in my new laptop combined with an external drive for my large data. Faster, more solid, and less battery usage. Doesn't matter if I get 32GB rather than 160GB on board. I agree fully with the OP, SSD will really break through in 2008. Dell already offers it as an option. It's all a matter of usage patterns right now, in the long term I am prety sure hard disks will die.
My now-wife and I actually did this back when we were still dating & in the US -- the portions there are just so fricking huge that we couldn't always finish them even when we split them. Loose weight and save money at the same time, woohoo!
I think the greatest obstacle to 'great' code is 'language fascism'. Some languages are better than others, that's true, but they way some people carry on you'd think it was only possible to write 'great' code in their language of choice. This behavior is generally exhibited by those that can code in one (or at most two) languages only. Having used over 2^4 programming languages, I frequently get the 'this could be done more nicely in X' feeling. In particular, my Java programs could benefit from having Scheme-like macros that allows actual extension of the language.
My code style has improved a lot the four years I've been out in the workforce. We were fortunate enough to have somebody at the start of the project who really cared about methodology, metrics and style, and it has paid off. We've been using unit tests and code reviews all the way through, together with fairly powerful tools (IntelliJ has nice refactorings). While my coding quality still varies, it is no longer where I'm embarrased, and some of it I can plainly say 'this is the way to solve this problem.' The three practices I have found the most useful are:
1) Always document your functions and variables[1]. I don't agree with Use The Source, Luke. The source says what's being done, not why, and if the code has an error, you'll translate that error into your thinking about the program rather than fix it. Documenting the code *before* writing it lets you think about it first and forces you to be explicit rather than clever.
2) Write unit tests first (this is the one I find the hardest to follow). This encourages smaller portions of code and clarifies what the code should do. Plus, it gives you a place to do cowboy programming:)
3) Refactor mercilessly. Any time I cut-and-paste a chunk of code, I regard it as a candidate for refactoring, even if it's just a couple lines. Making it a new method adds testability, reduces cut-and-paste errors, increases documentation and makes it easier to use that third time.
I'm applying it as I go along to the OSS project I'm maintaining, and it helps both me and others.
The issue is not backup up, but how to access it. I'm pretty sure I have many, many more bits of data in my brain than I can easily access. If anyone comes out with a product that improves recalling ability, I'm all over it. But not if it has Windows written on it.
Unfortunately, none of these tests are very relevant to my normal usage. Where are the compile tests? I spend significant time compiling various stuff, and that's a lot of reading fairly small files from different places. SSD should really shine there.
Hard disks are not reliable above 10000ft (2 miles). That covers a number of interesting places, including many observatories. At the distance and speed that happens inside a HDD, the Bernoulli effect is what keeps the heads from turning your data into slightly magnetic dust. See http://en.wikipedia.org/wiki/Hard_disk#Integrity
From empirical data in the current Danish election, I can tell you that counting 8000 votes takes about 3 hours for 25 people, so 1 to 2 votes per minute, including having multiple people count each vote. If the votes are tallied in place rather than being moved, very little organization is needed. Rather than getting 200 people per state counting every day for a month, have ordinary volunteers count at the polling station. You'd need about 150.000 volunteers total, or 52 per county on average. Working three hours on election night. Is that really that difficult?
200,000,000 is a pretty big number to count all the way up to without making a mistake Not if you have enough people counting. At our polling station tonight, we had about 8000 voters and 25 people counting. That's an amazing 320 votes each will have to count. How long would it take you to sort through 320 pieces of paper according to where an X is marked? How about "not all damn night"?
Agreed. We're currently counting our votes for the election here in Denmark. By hand. With a ballot about a meter long to hold all the parties and candidates. I stuck around at the polling station after close to watch the counting -- it's open to the public, and anyone can sign up to participate. When I left half an hour after close, the votes were just about all unfolded and perhaps 25% were through the first sorting (where the four largest parties are sorted out from the rest.
Mechanical voting is a cure that's worse than the disease. It's expensive, it adds ways things can break, and it obfuscates what's actually going on. Hand voting and hand counting scales very well, and in a real democracy, maximum openness is not just an advantage, but essential.
Slashdot Mirror
The legends on the main graphs appear to be wrong: According to the caption for Fig. 3, the blue curve should be 30-day plots, but the legend calls that 90 days. The legend doesn't make sense when you consider which numbers should be included in the others, e.g. that 0-day patches are also included in 30-day etc. Thus the green line is 0-day, the blue line is 30-day, the red line is 90-day, and the grey line is 180-day. MS has been around 60% 0-day +- 10% for much of the interval, except a dip to below 40% in most of 2004, and they are now up to almost 80% 0-day patches. The 90% 0-day patches in 2002 is impressive almost to the point of being suspicious. Apple has been climbing from 0% 0-day patches before 2003, managed to be above 60% for most of 2006, but fell to about 40% in 2007. For total patches within 180 days, MS has been in the 90% area most of the time, above 95% at the end of the study. Apple has been above 80% 180-day fixes most of the period, but only briefly above 90%.
Who wants to do the same thing for Linux?
-Lars
I never knew the days when MS was liked as an underdog. Compared to Amiga, Atari, Mac etc their stuff has always been crap, their policies always been deplorable, and Gates has always been hated. Basic assumption of article wiped out.
As for Apple, I'm currently trying a switch from Ubuntu, and I'm only partially happy. Some of it may improve when I get some hacks installed (e.g. to get click-anywhere-in-window-to-drag and other real conveniences), but I'm quite worried about their closedness in general. They may have better bling-bling than MS will ever get, but there's very much a "we design it all" attitude towards third-party work.
The ability to climb poles (and legs) is cute, but apart from that, Xerox PARC had a modular robot in 2000 that could not only be a snake, but could reconfigure itself into a ball or a spider to go faster or to traverse difficult terrain. It was extremely nifty, but like so much else from Xerox PARC, they never capitalized much on it.
-Lars
Part of the Ethernet spec is to wait 9.6 microseconds after the medium appears to be idle before sending, then resend if it collides. Light moves about 3 kilometres in that time. Making an Ethernet of 2550 km pratically guarantees nothing but collisions. So while this is a hunkin' heap of net, it's not Ethernet.
It'd be cool if TFA's headline was actually correct: Then we'd have a machine whose performance actually accelerated by a 10^15 floating point operations per second *per second*. That gets to be a lot of FLOPS real fast.
OTOH, it might just be the singularity happening. We wouldn't notice until it was too late.
Actually, the eureka moments are neither at the head end or the tail end. First comes a lot of digging into the field in one way or another, then at some point you get the "perspective change", then a lot of hard work is required to get it to something that works. However, that moment where the accumulated mountain of knowledge, ideas, intuitions etc collapse into a single new thing is exhilarating and noticeable.
Innovation is about as much sudden flash as making love is orgasm: It's the high point, but fairly brief. The rest is mostly perspiration -- and hopefully a lot of fun, too.
There, that analogy should derail enough nerd workforce that I can get my "innovation" out first.
Welcome to the Nanny Nation. I bought a folding step ladder while I lived in the US. It had eleven (11) warning labels on it. I think two or three of them were the same, but still... There's nothing mysterious about a step ladder like there is about electricity.
-Lars
They used torches before electricity and lanterns to light up dark areas. And to set fire to things before sticking in the pitchforks.
-Lars
Amen. Any time you pick one language, no matter how brilliant or versatile, and only teach that, you're crippling your students. Noone would expect a carpenter to only know how to use a powerdrill. Some assembly is a must, to understand the lowest level of the machine. One each of procedural, object-oriented and functional languages should also be in the toolbox of anyone with a CS degree. We can discuss all night which ones they should be, but that's like quibbling over which textbooks to choose for a subject. Irrelevant.
-Lars
I would give you the data on the direct comparison, but they haven't been published yet. Even over RAID-5, we get twice the speed without any warm-up time. And once you're talking high-performance HDD + RAID controller + extra disks for RAID + extra power for HDD + extra power for cooling, the savings on HDD are minimal if not gone.
-Lars
Just looking at newegg.com, I find the current sweet spot of SSD to be 32GB, at $250. $7/GB, half down from what Wikipedia mentions for "late 2007". The price is not just falling, it's plummeting like a jumbojet with both wings shot off. I love it. Can't wait to get the last mechanical pieces out of my computers.
-Lars
We have already been running tests showing Lucene to be several times as fast on large indexes and realistic queries using SSD than using normal drives. I'm going to have a smallish SSD in my new laptop combined with an external drive for my large data. Faster, more solid, and less battery usage. Doesn't matter if I get 32GB rather than 160GB on board. I agree fully with the OP, SSD will really break through in 2008. Dell already offers it as an option. It's all a matter of usage patterns right now, in the long term I am prety sure hard disks will die.
-Lars
You can make that much money by outsourcing PCI data? And here I thought outsourcing meant you pay somebody else to do something.
-Lars
My now-wife and I actually did this back when we were still dating & in the US -- the portions there are just so fricking huge that we couldn't always finish them even when we split them. Loose weight and save money at the same time, woohoo!
-Lars
This article is fairly content-free. For all the categories, the answer seems to be "let the users bend you over backwards". Nothing useful.
-Lars
My code style has improved a lot the four years I've been out in the workforce. We were fortunate enough to have somebody at the start of the project who really cared about methodology, metrics and style, and it has paid off. We've been using unit tests and code reviews all the way through, together with fairly powerful tools (IntelliJ has nice refactorings). While my coding quality still varies, it is no longer where I'm embarrased, and some of it I can plainly say 'this is the way to solve this problem.' The three practices I have found the most useful are:
1) Always document your functions and variables[1]. I don't agree with Use The Source, Luke. The source says what's being done, not why, and if the code has an error, you'll translate that error into your thinking about the program rather than fix it. Documenting the code *before* writing it lets you think about it first and forces you to be explicit rather than clever.
2) Write unit tests first (this is the one I find the hardest to follow). This encourages smaller portions of code and clarifies what the code should do. Plus, it gives you a place to do cowboy programming:)
3) Refactor mercilessly. Any time I cut-and-paste a chunk of code, I regard it as a candidate for refactoring, even if it's just a couple lines. Making it a new method adds testability, reduces cut-and-paste errors, increases documentation and makes it easier to use that third time.
I'm applying it as I go along to the OSS project I'm maintaining, and it helps both me and others.
-Lars
[1] Except trivial getters and setters. Maybe.
The issue is not backup up, but how to access it. I'm pretty sure I have many, many more bits of data in my brain than I can easily access. If anyone comes out with a product that improves recalling ability, I'm all over it. But not if it has Windows written on it.
-Lars
Been done, and well. See for instance Lois McMaster Bujold's "Mirror Dance". Actually, read all of the Miles series. It rocks.
-Lars
Unfortunately, none of these tests are very relevant to my normal usage. Where are the compile tests? I spend significant time compiling various stuff, and that's a lot of reading fairly small files from different places. SSD should really shine there.
-Lars
Hard disks are not reliable above 10000ft (2 miles). That covers a number of interesting places, including many observatories. At the distance and speed that happens inside a HDD, the Bernoulli effect is what keeps the heads from turning your data into slightly magnetic dust. See http://en.wikipedia.org/wiki/Hard_disk#Integrity
-Lars
From empirical data in the current Danish election, I can tell you that counting 8000 votes takes about 3 hours for 25 people, so 1 to 2 votes per minute, including having multiple people count each vote. If the votes are tallied in place rather than being moved, very little organization is needed. Rather than getting 200 people per state counting every day for a month, have ordinary volunteers count at the polling station. You'd need about 150.000 volunteers total, or 52 per county on average. Working three hours on election night. Is that really that difficult?
-Lars
-Lars
Agreed. We're currently counting our votes for the election here in Denmark. By hand. With a ballot about a meter long to hold all the parties and candidates. I stuck around at the polling station after close to watch the counting -- it's open to the public, and anyone can sign up to participate. When I left half an hour after close, the votes were just about all unfolded and perhaps 25% were through the first sorting (where the four largest parties are sorted out from the rest.
Mechanical voting is a cure that's worse than the disease. It's expensive, it adds ways things can break, and it obfuscates what's actually going on. Hand voting and hand counting scales very well, and in a real democracy, maximum openness is not just an advantage, but essential.