Better the water than the astronauts. It's cheap. It's packed full of hydrogen at high density. You have to take some anyway.
What about when you run out?
You recycle water. In fact, whatever else is done, the mission would have to recycle water just to cut down the amount of mass. Otherwise, a quick back of an envelope calculation says you'd need to take 11 tonnes of water just for drinking (assumptions: 2.5 litres a day, 18 month mission, 8 crew members). To say nothing of the other uses for it.
Joel's articles have the great property of virtually always being a good read. In my experience, he's either insighfully right or wrong for reasons that you need to think hard about.
Which version(s) of Tcl do you believe to be slow? Which software were you running on top of the language core? Griping about stuff on/. is all very well, but actually saying "This specific X is too slow" allows it to be fixed.
On the "ugly" comment, I'll just say "each to his own". I don't care for Ruby or Python all that much myself, but I learnt long ago that people's mileage really does vary.
The industry likes paying for single songs because it is way better (from their PoV) than people not buying music at all. It's all about growing the overall market...
What I'd like is a way to make my landline cost any corporate body (including non-profits of all descriptions) $1-per-minute to call, with the money coming to me. If the telemarketers have to pay me to listen, I might not get quite so cross at them.
"I don't want to buy insurance from you at the moment, but do tell me more about it anyway. I feel a slight twinge of doubt coming and going, so perhaps a good long pitch ($50 worth, perhaps) will change my mind..." [some time passes] "No, I think I'll just ring off now as I want to get that pizza you've just paid for with this call. Thanks anyway, and rest assured that I value your subsidizing my pizza habit so feel free to call again!"
There is only one layer of transistors, which is at the top of the silicon substrate. I am not aware of any production process which has multiple layers of transistors.
As I understand it, the problem has been that it is extremely difficult to match the capacitances (i.e. the switching speeds) of transistors at different depths within the silicon, and this causes a lot of trouble for normal VLSI design toolchains. Fully clockless designs have advantages here, and especially the variants that are free of timing hazards, but the support technology to work with these sorts of tooling is much less advanced. There are critical advantages to things smartcards though, especially as thermal constraints are less of a worry than making the chip very highly hardened against analysis.
Finally, if we had a keyboard like this, we might finally get programming languages with decent mathematical symbols -- instead of crap like !=, **, and so on.
That's malformed XML! What you really wanted to type was this:
<whackball:theory xmlns:whackball="uri:tinfoil.hats.R.us" whackball:contentType="text/paranoid" whackball:style="conspiracy">
Microsoft is paying everybody to stay on Windows
</whackball:theory>
"With this knowlege, you can easily estimate the traffic to other sites. If we go by the 471 million estimate, Slashdot gets a whopping 380,000 daily readers."
Pretty sure I F5 more than that.
Sure, but that information is encapsulated in the page-views-per-visit figure, which will be different for slashdot than for the site for which the original author had some sample data. And you might be a statistical outlier anyway.
Let's consider the actual figure the original author extracted for the size of the internet: is it of the right magnitude? I'd argue that it is, as I'd certainly believe 150 million to 1500 million internet users (which is one-order magnitude span with the 471 million figure at about the center value on a log scale). With more sample data - which the author explains is hard to come by for understandable reasons - a better estimate could be obtained and it would become possible to start thinking about handling the errors sensibly; the general technique is clever though, and a nice analogy with Cavendish's experiment.
You really want to allow the U.N. to impose taxes? Talk about taxation without representation...
Perhaps, but it's not like the US (and hence its citizens) isn't represented at the UN. If you feel the US representatives aren't doing enough for you, surely that's a problem between them and you.
(Of course, if the UN were running the basis of DNS, they'd probably do it by handing control of it back to national governments under some understanding that they'd agree to list each others root nameservers fairly. In practice, I'd bet that the root nameservers themselves would stay exactly where they are now, except maybe more of them would get set up. The political management of them would just become a bit more complex.)
If you use instanceof more than once every, say, 10000 lines of code, I will fight you.
This all depends on whether you need to vary things by the type of the actual object along multiple axes simultaneously (and also on how large your class definitions are.;-) OK, some languages support such things (Common Lisp with CLOS is one such example) but neither Java nor C++ do. Sometimes, the right thing to do is to refer the action to the other class and use the inheritance hierarchy to sort it all out, but not always.
One place where you do tend to need instanceof a lot is in basic equals() method implementations, since if things are of a different type, they're definitely not equal and yet you don't want to throw a type exception since you can correctly determine that they're different. It's when things are the same type that you have to do more work. If you're going to insist on avoiding instanceof because of some prissy rule on what you think OO is, you're going to have to do something even more gross instead, like catching all exceptions in code, or even comparing the serializations! Or are you just relying on the lame built-in object identity rules? (Oh well, at least they're controllable.)
Pragmatic programmers use instanceof where necessary (just like any other tool provided). Language fascists foolishly try to castigate them for this. But that's always been the way.
I agree mostly (losing associativity is worse, BTW) and I feel that C++ could have done the whole operator thing much better if they'd forced people to only ever do the job properly (perhaps by subclassing an abstract NumericValue class?)
As it is, what we have is a language that can be used to do really neat stuff, but which too often isn't used that way in practice. The language also makes it too easy to lose sight of where the expensive operations are, which is something that really matters for any language intended for even moderately low-level use.
(The other key problem with C++ as commonly implemented is that it is a PITA to deploy in a portable way. I'm not sure you'd call this a language fault though; it's perhaps more of a toolchain and binary-format problem.)
Fly to USA: Fingerprint scanning. Slight increase in time creates larger backlog. Clearing customs takes longer.
In my experience at flying to the USA, the fingerprinting stuff has sped things up somewhat (assuming you're someone who can fill the forms in right!), perhaps because of the reexamining of protocols on queue management, but baggage reclaim and customs are just exactly as slow and annoying as they have always been.
So we have a choice between "correct" and "fast"? I'd much rather go with both (who wouldn't?) but if I had to pick, I'd go with "correct".
The problem is that correctness is a system property; the code is correct if and only if it has no mistakes anywhere in it, and there's no bound on the number of levels you can make a mistake at (starting from typos that make the compiler crap out, and going through to and beyond the problems you get when systems of libraries are joined together in an unfortunate way - a fault that is actually distressingly common, BTW). Given that correctness is really hard to achieve, lots of people prefer speed. I'm not quite sure why; maybe they subconciously hope that by making the code go by really quickly, they'll be out of harm's way before some random bolt from the blue makes them hit a bug?? (Anyone really thinking that should turn their software license right now; they're not fit to be let loose on a programming environment.)
Looking more specifically at zlib, it's one of those curious things that has to be written in C (alas, still the only language that really has meaningful portability across a truly wide range of systems) and yet the code is complex enough that almost anyone could stare at it for ages and not be sure whether any buffer overflows exist or not. OK, it's doing something complex, but even so the code is not written for maximum clarity; it needs more simplification so that it becomes easier to determine the overall "smell" of the code. (You all know about "code smell", don't you?) Like that it will be easier for more people to audit the code, and one of the clear key strengths of OSS will kick in.
If you intend to prosecute anyone you discover using your software without making the source (or at least their changes to it) publically available, use the GPL. If you do not intend to prosecute anyone for such things, use the (advertising-clause-free) BSD license.
A license isn't worth half a wooden nickel if you won't actively defend it if necessary. Choose where you draw the line in the sand for yourself.
In the event of a disk failure, the data can be reasonably rebuilt by isolating the specific byte or bytes in that array that fails the checksum verification and applying a reverse checksum algorithm to determine the most likely original byte value.
Wouldn't it be better to use one of the high-performance error correcting codes instead of a checksum? After all, it is "critical data". Also, have you considered whether the critical data is stored on the same device or in the same facility? What happens if the device fails overall? What happens if the machine-room burns down? What happens if someone in a call-center in Bangalore sells the critical data to the Russian mafia?
Sounds like people here have not considered the nature of the criticality of the data at all, and hence the nature of threats that it must be guarded against. Come on! Show some insight! Put those hard-earned PhDs to work!
If these people were serious about grid computing, they'd offer a way for people to sell cycles. Altruistic donation may be good for some people, but the rest of us like to see real money for this sort of thing. If nothing else, covering some of the costs (and not just electric power) of having a machine would be nice.
With some experience, even $250k is on the low-side for a serious compute cluster. Assuming you put in reasonable interconnect (needed for many interesting problems).
Slashdot Mirror
And end up with nicely ionised, irradiated water?
Better the water than the astronauts. It's cheap. It's packed full of hydrogen at high density. You have to take some anyway.
What about when you run out?
You recycle water. In fact, whatever else is done, the mission would have to recycle water just to cut down the amount of mass. Otherwise, a quick back of an envelope calculation says you'd need to take 11 tonnes of water just for drinking (assumptions: 2.5 litres a day, 18 month mission, 8 crew members). To say nothing of the other uses for it.
Joel's articles have the great property of virtually always being a good read. In my experience, he's either insighfully right or wrong for reasons that you need to think hard about.
Which version(s) of Tcl do you believe to be slow? Which software were you running on top of the language core? Griping about stuff on /. is all very well, but actually saying "This specific X is too slow" allows it to be fixed.
On the "ugly" comment, I'll just say "each to his own". I don't care for Ruby or Python all that much myself, but I learnt long ago that people's mileage really does vary.
Unfortunately, we don't have the fancy web framework in place just yet...
Ah, so OpenACS isn't a fancy web framework?
there are patent applications coming into the USPTO in torrents
They're using BitTorrent to upload patent applications now? Cool!
The industry likes paying for single songs because it is way better (from their PoV) than people not buying music at all. It's all about growing the overall market...
What I'd like is a way to make my landline cost any corporate body (including non-profits of all descriptions) $1-per-minute to call, with the money coming to me. If the telemarketers have to pay me to listen, I might not get quite so cross at them.
"I don't want to buy insurance from you at the moment, but do tell me more about it anyway. I feel a slight twinge of doubt coming and going, so perhaps a good long pitch ($50 worth, perhaps) will change my mind..." [some time passes] "No, I think I'll just ring off now as I want to get that pizza you've just paid for with this call. Thanks anyway, and rest assured that I value your subsidizing my pizza habit so feel free to call again!"
[Gates] wants more friggin' managers!
Not quite; he wants more competent managers. Incompetent ones are easy enough to come by after all.
I mean seriously, whens the last time you used ctrl+c and ctrl+v to move and deposit physical objects (rhetorical)?
Speaking as someone who's been moving heavy furniture around at home, "cut-n-paste in the real world" would have been very useful...
There is only one layer of transistors, which is at the top of the silicon substrate. I am not aware of any production process which has multiple layers of transistors.
As I understand it, the problem has been that it is extremely difficult to match the capacitances (i.e. the switching speeds) of transistors at different depths within the silicon, and this causes a lot of trouble for normal VLSI design toolchains. Fully clockless designs have advantages here, and especially the variants that are free of timing hazards, but the support technology to work with these sorts of tooling is much less advanced. There are critical advantages to things smartcards though, especially as thermal constraints are less of a worry than making the chip very highly hardened against analysis.
Finally, if we had a keyboard like this, we might finally get programming languages with decent mathematical symbols -- instead of crap like !=, **, and so on.
And when we do, we'll have the programming language to make use of it.
That's what you get when you have an unholy alliance between plutocrats and kleptocrats.
That's malformed XML! What you really wanted to type was this:
<whackball:theory xmlns:whackball="uri:tinfoil.hats.R.us" whackball:contentType="text/paranoid" whackball:style="conspiracy">
Microsoft is paying everybody to stay on Windows
</whackball:theory>
Now, isn't that much easier to understand?
Let's consider the actual figure the original author extracted for the size of the internet: is it of the right magnitude? I'd argue that it is, as I'd certainly believe 150 million to 1500 million internet users (which is one-order magnitude span with the 471 million figure at about the center value on a log scale). With more sample data - which the author explains is hard to come by for understandable reasons - a better estimate could be obtained and it would become possible to start thinking about handling the errors sensibly; the general technique is clever though, and a nice analogy with Cavendish's experiment.
(Of course, if the UN were running the basis of DNS, they'd probably do it by handing control of it back to national governments under some understanding that they'd agree to list each others root nameservers fairly. In practice, I'd bet that the root nameservers themselves would stay exactly where they are now, except maybe more of them would get set up. The political management of them would just become a bit more complex.)
If you use instanceof more than once every, say, 10000 lines of code, I will fight you.
;-) OK, some languages support such things (Common Lisp with CLOS is one such example) but neither Java nor C++ do. Sometimes, the right thing to do is to refer the action to the other class and use the inheritance hierarchy to sort it all out, but not always.
This all depends on whether you need to vary things by the type of the actual object along multiple axes simultaneously (and also on how large your class definitions are.
One place where you do tend to need instanceof a lot is in basic equals() method implementations, since if things are of a different type, they're definitely not equal and yet you don't want to throw a type exception since you can correctly determine that they're different. It's when things are the same type that you have to do more work. If you're going to insist on avoiding instanceof because of some prissy rule on what you think OO is, you're going to have to do something even more gross instead, like catching all exceptions in code, or even comparing the serializations! Or are you just relying on the lame built-in object identity rules? (Oh well, at least they're controllable.)
Pragmatic programmers use instanceof where necessary (just like any other tool provided). Language fascists foolishly try to castigate them for this. But that's always been the way.
I agree mostly (losing associativity is worse, BTW) and I feel that C++ could have done the whole operator thing much better if they'd forced people to only ever do the job properly (perhaps by subclassing an abstract NumericValue class?)
As it is, what we have is a language that can be used to do really neat stuff, but which too often isn't used that way in practice. The language also makes it too easy to lose sight of where the expensive operations are, which is something that really matters for any language intended for even moderately low-level use.
(The other key problem with C++ as commonly implemented is that it is a PITA to deploy in a portable way. I'm not sure you'd call this a language fault though; it's perhaps more of a toolchain and binary-format problem.)
The problem is that correctness is a system property; the code is correct if and only if it has no mistakes anywhere in it, and there's no bound on the number of levels you can make a mistake at (starting from typos that make the compiler crap out, and going through to and beyond the problems you get when systems of libraries are joined together in an unfortunate way - a fault that is actually distressingly common, BTW). Given that correctness is really hard to achieve, lots of people prefer speed. I'm not quite sure why; maybe they subconciously hope that by making the code go by really quickly, they'll be out of harm's way before some random bolt from the blue makes them hit a bug?? (Anyone really thinking that should turn their software license right now; they're not fit to be let loose on a programming environment.)
Looking more specifically at zlib, it's one of those curious things that has to be written in C (alas, still the only language that really has meaningful portability across a truly wide range of systems) and yet the code is complex enough that almost anyone could stare at it for ages and not be sure whether any buffer overflows exist or not. OK, it's doing something complex, but even so the code is not written for maximum clarity; it needs more simplification so that it becomes easier to determine the overall "smell" of the code. (You all know about "code smell", don't you?) Like that it will be easier for more people to audit the code, and one of the clear key strengths of OSS will kick in.
If you intend to prosecute anyone you discover using your software without making the source (or at least their changes to it) publically available, use the GPL. If you do not intend to prosecute anyone for such things, use the (advertising-clause-free) BSD license.
A license isn't worth half a wooden nickel if you won't actively defend it if necessary. Choose where you draw the line in the sand for yourself.
Good thing all my critical data values equal zero or I don't know what I'd do.
Wouldn't it be better to use one of the high-performance error correcting codes instead of a checksum? After all, it is "critical data". Also, have you considered whether the critical data is stored on the same device or in the same facility? What happens if the device fails overall? What happens if the machine-room burns down? What happens if someone in a call-center in Bangalore sells the critical data to the Russian mafia?
Sounds like people here have not considered the nature of the criticality of the data at all, and hence the nature of threats that it must be guarded against. Come on! Show some insight! Put those hard-earned PhDs to work!
You forgot the Evil Laugh. The Evil Laugh is very important in this sort of situation.
If these people were serious about grid computing, they'd offer a way for people to sell cycles. Altruistic donation may be good for some people, but the rest of us like to see real money for this sort of thing. If nothing else, covering some of the costs (and not just electric power) of having a machine would be nice.
With some experience, even $250k is on the low-side for a serious compute cluster. Assuming you put in reasonable interconnect (needed for many interesting problems).