The venerable Unix info files and even man pages also do the same thing. Web browsers was a logical improvement of existing ideas. It was not evolutionary, not revolutionary.
Sometimes, the evolutionary is revolutionary. What happens is that a small advance leads to a phase change; things go from being obscure to being world-beating. It's happened before, it will happen again.
You're mostly right in your post, but I'd like to take issue with a few specifics.
The classic example is C's "array = pointer" ambiguity. Consider
int read(int fd, char* buf, size_t len);
Think hard about "char* buf". That's not a pointer to a character. It's a pass of an array by reference. The programmer had to lie to the language because the language doesn't have a way to talk about what the programmer needed to say. That should have been
int read(int fd, byte& buf[len], size_t len);
Now the interface is correctly defined. The caller is passing an array of known size by reference.
With read() specifically, the pointer is not necessarily to the start of the buffer. This is an important point; one of the most important things about C is that you can do address arithmetic. Yes, this is a very sharp-edged tool, but it is so useful for performance. In particular, if you wrap things up so that you can only ever pass the start of a buffer, you end up having to perform many more allocation steps and many more copies of information. This utterly slays performance (a problem that is disappointingly common in programs written in C++, despite all the theoretical speed it has).
Of course, what a good IO library does is to look after the details for you so that you write what you mean and it implements it efficiently using code that is highly reusable and extensively tested. But at that point you are no longer looking at passing buffers around, but rather higher-level entities. And the real goal is, indeed, to narrow the gap between what programmers are thinking about when they write code, and the code that they really write; we want there to be obviously no bugs, and not just no obvious bugs.
actually, greed is good. it's the great motivator. really, it's the only motivator.
No. There's "fear" too. We need to lynch some bank executives from lamp-posts and sell their families into slavery. That will then remind all future financial whizz-kids that if they screw people over too much, the rest of the world will get them and make their gains worth naught.
He died suddenly in the hospital from internal bleeding caused by the surgery a few hours later. Now the cancer might have gotten him eventually, but how long, five years? ten? He was 82 and healthy and happy so it was kinda pointless operating really.
He thought so too, but let himself be talked into it by his doctor.
Sounds to me like the best thing you could do would be to sue the doctor and hospital for pressing unnecessary interventions and so causing his death. If the system is as broken in the US as alleged, you might as well try to use that brokenness for a little good.
Yeah, that is a good idea. But save it for when somebody comes with a way to differentiate "reading" from "idle".
This stuff has already been solved in a very slightly different context. "Idle" is what happens 10 seconds or so after the screensaver kicks in, and corresponds to the point when you also start requiring a password to get back in. (If you're running a cycle scavenger on your desktop, that's also the point when it should kick in.) Like that, if you're reading something and you notice the screensaver start (easily noticed) then you've got a moment or two to move the mouse or press a key. And it works; all the bits and pieces are already there.
Apparently neither of you have been to Massachusetts...
The traffic in Naples is worse than the traffic in Massachusetts. Yes, I've been in both places. Neapolitans are mad. They manage to be worse even than the Athenians...
For instance, if you are losing $3000 per hour in lost profit, then craft an SLA with your provider in which they are liable for $3000 per hour in penalties. Then be prepared to pay for that level of service.
Or use some of that money to buy insurance against downtime. After all, you ultimately cannot prevent shit from ever happening; you can just ensure that when things go wrong the business is not slayed by it.
There's nothing quite like buying insurance to focus the mind on how much you actually value something...
Until someone else reports on a story, it won't appear on slashdot.
Not necessarily, but it helps a submission a lot if it includes a relevant link to a well-written page. Several links (especially where it's not just a dump of what you can get by googling the keywords) is better still. And let's face it, there will probably be somewhere else that writes about it first, even if it is just some obscure blog.
"1 of 3" and not "1 in 3"? Big deal. So Dell sold 1 notebook with Linux. How is that going to put a dent in Microsoft's market share?
You've missed the big news there, which is that the economy has tanked so badly that Dell has only sold three notebooks! It's right there in the title!
Will someone please do Dell a favor and increase their sales by 33% by buying one of their notebooks?
To the contrary, DNSSEC could possibly kill the goldmine that is the SSL cert racket. That is, unless having your DNS entry signed somehow becomes a "value added" service you need to pay for extra.
SSL also protects against other threats, such as route poisoning and eavesdropping, neither of which are DNS-related threats. To say that DNSSEC replaces all that is just plain wrong.
If you think that the commercial CAs are running a racket, you don't need to take part. Really. FWIW, I use SSL with a custom CA just fine across some of the servers I look after; we can just distribute the CA certificate manually just fine too, since it is a limited problem space. For your own stuff, that's actually ideal since you've got better control over the trust domain. (If you control the trust root the rest of the SSL system is very good since a lot of people have tried to make it robust.) You only need the CAs when you are communicating with people who don't already know you, and they probably trust the CA more than some random person on the 'net. Mostly that's a good decision for them, given that a fair number of "random persons" are blackhats.
What I want to know about DNSSEC (and haven't yet found by googling) is whether it is possible to constrain the amount that the root declarations actually have to be trusted. Can they only be limited to stating who the authorities for particular TLDs are? Can we have different CAs signing each of the layers public keys? If that's all that we're trusting them to do, it is probably possible to accept them doing that. (Or at least it beats the current situation.)
The scary thing "rm -f/**", when used with the new shopt "globstar", removes all non-directory files while preserving the directory skeleton. It's kinda like vaporizing everyone in the town while leaving all the empty buildings and cars intact...
On a large directory structure it will actually (partially) fail in a nasty heap, since you probably won't be able to fit the list of all files (and directories and...) into the command line space. If you want to destroy all the files in the world, you need to be more sophisticated: find / -type f -print0 | xargs -0 rm -f
Data storage is something we've gotten very good at and we've made it very cheap. A Petabyte a day is not as staggering as it was even five years ago.
It still has to be paid for. It still has to be actually stored. It still has to be backed up. It still has to be kept in formats that we can actually read. It still has to have knowledge about what it all means maintained. In short, it still has to be curated, kept in an online museum collection if you will. And this all costs, both in money and effort by knowledgeable people.
The problem doesn't stop with copying the data to a disk array.
Hey, there's benefits to [large companies] too - I may have to target all my development to IE6, but at least nobody's forcing me to "upgrade" to Vista.
I'd watch out if I were you. They've got this new-fangled "Windows XP" software which they might force you onto...
In the flamebait but true category, this is further evidence why scripting languages are not suitable for most application development... because they are much more brittle than a traditionally compiled application.
Only because too many scripting language implementations are done by people who don't actually care about compatibility or the difficulty of deployment. Of course, it's dangerous to generalize from "all the ones I know" to "all"; some of us actually give a shit about such important stuff.
In my experience, it tends to be best to use a language like C, C++, Java or C# to write components, and to use a scripting language to stick those components together. (Yes, of course the components should be tested thoroughly.) Sticking independently-developed components using just a low-level language tends to be hard, dull, and error-prone work due to all the type-conversion gunk that you need. Using a higher-level language to hide most of the crap makes programmers more effective since it lets the real program be closer to the pseudo-code that people really work with in their heads.
Alas, it's when the people working on doing the code that connects different languages get it wrong that this whole sweet process is made much more painful. Perl isn't stellar in this regard; you can do better for yourself.
It's an XS module: They include components that are written in a language other than Perl, and have to be compiled against perl.
Which means that if the perl binary they are pointing to changes, they break. The code itself is fine: You just need to recompile.
You mean that Perl doesn't maintain a stable ABI from one version to another, at least for the parts that existed in the old version? What a bunch of amateurs! It's a long-solved problem outside Perl-land.
And my point is actually a serious one. It is possible to take code compiled against Tcl 8.1 (a decade old) and load it into a build of 8.6b1 (from last December) and have it work. Really. If you choose to do so, you've got a superb chance that the code will Just Work, despite substantive API changes over the intervening time. It's not rocket science, guys!
Correct for most people this is a good plan. For spammers it is not. They will of course opt out of the restriction.
So long as there is no way for the zombie itself to opt out, there's no (big) problem: the owner probably won't opt out, and the spammer won't go to the (fairly substantial) effort to social engineer his way past the restriction. What this does mean is that it pretty much requires that people who want to opt out call their Customer Services line rather than using a self-service webpage. It's horrible, but necessary.
And for the love of God, don't encourage J Random Grandma to opt out unless she's actually busy overthrowing the government.
In this financial climate? Only if those projects are willing to pay you (hah!) or you really believe in supporting what they do.
The wanna-be businessman in me thinks its probably a waste of money as well.
You look like you're in a position to use virtualization to create X application servers over Y machine servers... but you'd need all the IT staff and customer support, etc. to get that going. It's too bad you can't sell your CPUs to Amazon for their cloud computing since it's all pretty much anonymous but I guess either way I think about it you would need a pretty hefty internet connection.
There's really hardly any money to speak of in plain old CPU cycles. Amazon does OK out of it, but their model relies on being really big. Most of us don't operate at that size.
OTOH, if you can offer some sort of value-add, you can charge more. For example, you might run and support specialist applications for small businesses; there's a reasonable amount to be made in that area, but you need to be thinking then in terms of not just having computers but support staff too and, indeed, a whole business. You can't do it half-assed; this isn't the tech bubble.
Have you thought about just selling the servers?
As others have explained, that may well be a solid suggestion. Right now, better to have cash in hand than servers you don't need.
Organic != made by life. Means nonmetals, so Carbon, Nitrogen Sulfur and related compounds.
It specifically means Carbon. There's really quite a bit of it about in space, and the process of evaporating off all the ice from the comet will mean that that which is there has been thoroughly concentrated to make something rather like soot. Such materials, especially in ultra-low gravity environments (so preventing the collapse of complicated micro-strucutres), are incredibly black, making the comet harder to see than a black cat in a coal cellar. At night with no torch.
The New Scientist article goes on to mention that the best hope of spotting these things may be in the infra-red range, as they'll be absorbing all the sunlight that falls on them and reradiating it. Sounds tricky to me, but just might work...
Stockholm already have an old (17th century) warship near the harbour. Look at the Vasa museum.
But other alternatives in the area, while not being of the right period, are at least afloat, and any pirate worth his salt wouldn't be too bothered by the difference.
Slashdot Mirror
I imagine you'd run out of soldiers in the front real fast, and you'd have packed the last truck so full even a Mexican wouldn't fit in.
The story did involve the phrase "military intelligence"; it probably didn't occur to anyone that there was a problem...
The venerable Unix info files and even man pages also do the same thing. Web browsers was a logical improvement of existing ideas. It was not evolutionary, not revolutionary.
Sometimes, the evolutionary is revolutionary. What happens is that a small advance leads to a phase change; things go from being obscure to being world-beating. It's happened before, it will happen again.
You're mostly right in your post, but I'd like to take issue with a few specifics.
The classic example is C's "array = pointer" ambiguity. Consider
int read(int fd, char* buf, size_t len);
Think hard about "char* buf". That's not a pointer to a character. It's a pass of an array by reference. The programmer had to lie to the language because the language doesn't have a way to talk about what the programmer needed to say. That should have been
int read(int fd, byte& buf[len], size_t len);
Now the interface is correctly defined. The caller is passing an array of known size by reference.
With read() specifically, the pointer is not necessarily to the start of the buffer. This is an important point; one of the most important things about C is that you can do address arithmetic. Yes, this is a very sharp-edged tool, but it is so useful for performance. In particular, if you wrap things up so that you can only ever pass the start of a buffer, you end up having to perform many more allocation steps and many more copies of information. This utterly slays performance (a problem that is disappointingly common in programs written in C++, despite all the theoretical speed it has).
Of course, what a good IO library does is to look after the details for you so that you write what you mean and it implements it efficiently using code that is highly reusable and extensively tested. But at that point you are no longer looking at passing buffers around, but rather higher-level entities. And the real goal is, indeed, to narrow the gap between what programmers are thinking about when they write code, and the code that they really write; we want there to be obviously no bugs, and not just no obvious bugs.
actually, greed is good. it's the great motivator. really, it's the only motivator.
No. There's "fear" too. We need to lynch some bank executives from lamp-posts and sell their families into slavery. That will then remind all future financial whizz-kids that if they screw people over too much, the rest of the world will get them and make their gains worth naught.
Fear and greed, the great motivators.
He died suddenly in the hospital from internal bleeding caused by the surgery a few hours later. Now the cancer might have gotten him eventually, but how long, five years? ten? He was 82 and healthy and happy so it was kinda pointless operating really.
He thought so too, but let himself be talked into it by his doctor.
Sounds to me like the best thing you could do would be to sue the doctor and hospital for pressing unnecessary interventions and so causing his death. If the system is as broken in the US as alleged, you might as well try to use that brokenness for a little good.
Yeah, that is a good idea. But save it for when somebody comes with a way to differentiate "reading" from "idle".
This stuff has already been solved in a very slightly different context. "Idle" is what happens 10 seconds or so after the screensaver kicks in, and corresponds to the point when you also start requiring a password to get back in. (If you're running a cycle scavenger on your desktop, that's also the point when it should kick in.) Like that, if you're reading something and you notice the screensaver start (easily noticed) then you've got a moment or two to move the mouse or press a key. And it works; all the bits and pieces are already there.
I of course immediately tried logging in as root using variants of "asecret" for a password, and sure enough -- it worked!
Damn! Time to change again...
Now we're making a true commodity out of babies.
I don't know about you, but I'm more interested in baby futures.
Apparently neither of you have been to Massachusetts ...
The traffic in Naples is worse than the traffic in Massachusetts. Yes, I've been in both places. Neapolitans are mad. They manage to be worse even than the Athenians...
For instance, if you are losing $3000 per hour in lost profit, then craft an SLA with your provider in which they are liable for $3000 per hour in penalties. Then be prepared to pay for that level of service.
Or use some of that money to buy insurance against downtime. After all, you ultimately cannot prevent shit from ever happening; you can just ensure that when things go wrong the business is not slayed by it.
There's nothing quite like buying insurance to focus the mind on how much you actually value something...
Until someone else reports on a story, it won't appear on slashdot.
Not necessarily, but it helps a submission a lot if it includes a relevant link to a well-written page. Several links (especially where it's not just a dump of what you can get by googling the keywords) is better still. And let's face it, there will probably be somewhere else that writes about it first, even if it is just some obscure blog.
"1 of 3" and not "1 in 3"? Big deal. So Dell sold 1 notebook with Linux. How is that going to put a dent in Microsoft's market share?
You've missed the big news there, which is that the economy has tanked so badly that Dell has only sold three notebooks! It's right there in the title!
Will someone please do Dell a favor and increase their sales by 33% by buying one of their notebooks?
To the contrary, DNSSEC could possibly kill the goldmine that is the SSL cert racket. That is, unless having your DNS entry signed somehow becomes a "value added" service you need to pay for extra.
SSL also protects against other threats, such as route poisoning and eavesdropping, neither of which are DNS-related threats. To say that DNSSEC replaces all that is just plain wrong.
If you think that the commercial CAs are running a racket, you don't need to take part. Really. FWIW, I use SSL with a custom CA just fine across some of the servers I look after; we can just distribute the CA certificate manually just fine too, since it is a limited problem space. For your own stuff, that's actually ideal since you've got better control over the trust domain. (If you control the trust root the rest of the SSL system is very good since a lot of people have tried to make it robust.) You only need the CAs when you are communicating with people who don't already know you, and they probably trust the CA more than some random person on the 'net. Mostly that's a good decision for them, given that a fair number of "random persons" are blackhats.
What I want to know about DNSSEC (and haven't yet found by googling) is whether it is possible to constrain the amount that the root declarations actually have to be trusted. Can they only be limited to stating who the authorities for particular TLDs are? Can we have different CAs signing each of the layers public keys? If that's all that we're trusting them to do, it is probably possible to accept them doing that. (Or at least it beats the current situation.)
The scary thing "rm -f /**", when used with the new shopt "globstar", removes all non-directory files while preserving the directory skeleton. It's kinda like vaporizing everyone in the town while leaving all the empty buildings and cars intact...
On a large directory structure it will actually (partially) fail in a nasty heap, since you probably won't be able to fit the list of all files (and directories and ...) into the command line space. If you want to destroy all the files in the world, you need to be more sophisticated:
find / -type f -print0 | xargs -0 rm -f
ln -s /bin/false /bin/csh
99% of the functionality of csh, without the bugs!
Try it the other way round for even more fun...
Real developers actually use the Mac?
Of course. The MacBook and MacBook Pro are nice laptops for on the move, and it runs ssh, gcc, vi, emacs and X11 perfectly.
Data storage is something we've gotten very good at and we've made it very cheap. A Petabyte a day is not as staggering as it was even five years ago.
It still has to be paid for. It still has to be actually stored. It still has to be backed up. It still has to be kept in formats that we can actually read. It still has to have knowledge about what it all means maintained. In short, it still has to be curated, kept in an online museum collection if you will. And this all costs, both in money and effort by knowledgeable people.
The problem doesn't stop with copying the data to a disk array.
Hey, there's benefits to [large companies] too - I may have to target all my development to IE6, but at least nobody's forcing me to "upgrade" to Vista.
I'd watch out if I were you. They've got this new-fangled "Windows XP" software which they might force you onto...
Unless team facebook is a bunch of utter morons
It doesn't do to exclude the possibility. Never underestimate the power of massed morons!
In the flamebait but true category, this is further evidence why scripting languages are not suitable for most application development ... because they are much more brittle than a traditionally compiled application.
Only because too many scripting language implementations are done by people who don't actually care about compatibility or the difficulty of deployment. Of course, it's dangerous to generalize from "all the ones I know" to "all"; some of us actually give a shit about such important stuff.
In my experience, it tends to be best to use a language like C, C++, Java or C# to write components, and to use a scripting language to stick those components together. (Yes, of course the components should be tested thoroughly.) Sticking independently-developed components using just a low-level language tends to be hard, dull, and error-prone work due to all the type-conversion gunk that you need. Using a higher-level language to hide most of the crap makes programmers more effective since it lets the real program be closer to the pseudo-code that people really work with in their heads.
Alas, it's when the people working on doing the code that connects different languages get it wrong that this whole sweet process is made much more painful. Perl isn't stellar in this regard; you can do better for yourself.
It's an XS module: They include components that are written in a language other than Perl, and have to be compiled against perl.
Which means that if the perl binary they are pointing to changes, they break. The code itself is fine: You just need to recompile.
You mean that Perl doesn't maintain a stable ABI from one version to another, at least for the parts that existed in the old version? What a bunch of amateurs! It's a long-solved problem outside Perl-land.
And my point is actually a serious one. It is possible to take code compiled against Tcl 8.1 (a decade old) and load it into a build of 8.6b1 (from last December) and have it work. Really. If you choose to do so, you've got a superb chance that the code will Just Work, despite substantive API changes over the intervening time. It's not rocket science, guys!
Correct for most people this is a good plan. For spammers it is not. They will of course opt out of the restriction.
So long as there is no way for the zombie itself to opt out, there's no (big) problem: the owner probably won't opt out, and the spammer won't go to the (fairly substantial) effort to social engineer his way past the restriction. What this does mean is that it pretty much requires that people who want to opt out call their Customer Services line rather than using a self-service webpage. It's horrible, but necessary.
And for the love of God, don't encourage J Random Grandma to opt out unless she's actually busy overthrowing the government.
The IT guy in me thinks that's a waste of FLOPS.
In this financial climate? Only if those projects are willing to pay you (hah!) or you really believe in supporting what they do.
The wanna-be businessman in me thinks its probably a waste of money as well.
You look like you're in a position to use virtualization to create X application servers over Y machine servers ... but you'd need all the IT staff and customer support, etc. to get that going. It's too bad you can't sell your CPUs to Amazon for their cloud computing since it's all pretty much anonymous but I guess either way I think about it you would need a pretty hefty internet connection.
There's really hardly any money to speak of in plain old CPU cycles. Amazon does OK out of it, but their model relies on being really big. Most of us don't operate at that size.
OTOH, if you can offer some sort of value-add, you can charge more. For example, you might run and support specialist applications for small businesses; there's a reasonable amount to be made in that area, but you need to be thinking then in terms of not just having computers but support staff too and, indeed, a whole business. You can't do it half-assed; this isn't the tech bubble.
Have you thought about just selling the servers?
As others have explained, that may well be a solid suggestion. Right now, better to have cash in hand than servers you don't need.
Organic != made by life. Means nonmetals, so Carbon, Nitrogen Sulfur and related compounds.
It specifically means Carbon. There's really quite a bit of it about in space, and the process of evaporating off all the ice from the comet will mean that that which is there has been thoroughly concentrated to make something rather like soot. Such materials, especially in ultra-low gravity environments (so preventing the collapse of complicated micro-strucutres), are incredibly black, making the comet harder to see than a black cat in a coal cellar. At night with no torch.
The New Scientist article goes on to mention that the best hope of spotting these things may be in the infra-red range, as they'll be absorbing all the sunlight that falls on them and reradiating it. Sounds tricky to me, but just might work...
Stockholm already have an old (17th century) warship near the harbour. Look at the Vasa museum.
But other alternatives in the area, while not being of the right period, are at least afloat, and any pirate worth his salt wouldn't be too bothered by the difference.