Theoretically true, perhaps, but practially impossible if you use a big enough key.
But there's another concern too -- if some chunk of your data exists *only* on some random person's hard drive, how can you be assured that it'll be there when you need it? Maybe that person won't have his computer on, or the drive will have crashed, etc. You can have multiple copies of everything, but there's a better way: error-correction encoding!
This would be just like a RAID array. The data would be split up among random host machines (every Nth bit goes to host 1, N+1 goes to host 2, N+3...), with extra redundant bits added accoring to the encoding, such that the data can be recovered 2 or 3 hosts aren't accessible.
This would also render your data very difficult to steal -- unless the theif could somehow find where enough of your different bits are being stored.
> How much does it weigh? For all I know it could sink a jetski, an area where this could apply.
Whoops, I missed this part. Let me address it.
According to the article, their 20-cm prototype produced 30 horsepower. I'm pretty rusty on my numbers, but the article said it'd be enough for a speedboat -- so a jet ski could probably do very well with something even smaller. Perhaps not much heavier than the current impeller mechanism.
> Ahem. Where you getting the steam from, buddy? If you are burning something, you need an oxidizer as well(a torpedo runs underwater...).
Uhh, if a torpedo is using a propeller, what engine is driving the propeller? Gas turbine? Don't you need oxidizer for that too? I suspect this is a solved problem.
> And I strongly suspect this engine isn't as fuel efficient as standard piston or turbines anyway.
I don't know about turbine, but a piston engine is only 20-30% efficient -- it's not hard to see this at least matching that.
Let's see -- making the steam and transferring that heat to the chamber will be near 100%. Then it's a matter of how much of the shockwave energy goes out the front vs. the back of the engine. I don't see that causing a loss of more than 50% -- probably less once it really gets moving, with all the water rushing in the front. The heating of the water will be a loss too, I guess, but probably not too much. Yeah, I can see this beating 30%.
> One question... What if they run into a school of tuna?;-)
Well, then you have a new fishing technique, too. Could even put the canning machinery right on the boat -- just aim the engine into the input, and let 'er rip!
> Have you ever gone for a ride in a small boat of current design? I wouldn't exactly classify them as silent. In fact, it's more along the lines of too loud for even a shouted conversation of any useful length.
This actually would be the above-water noise. I don't know how much the actual propeller transmits into the water, but it's probably less.
> For all we know the lack of prop cavitation and direct transmission of engine vibration through the drive shaft to the water might in fact make this a quieter engine!
Yes -- as you say here, the sound will likely go mostly into the water, not the air. So while it would very likely be much quieter above-water, below-water it could be worse.
Though as you say, we of course need actual measurements to answer the question.
> I highly doubt this would become mainstream in any smaller craft. The design would require revamping most current hull designs to accomodate an intake for better waterflow to the motor.
Jet skiis are already designed with this sort of thing in mind -- they just use an impeller where this engine would go.
> Also, how big is the motor? It might be far too cumbersome to fit in anything less than a 20 foot boat.
A jet ski can fit a good-sized 2-cylender engine, complete with starter moter & battery, water cooling system, etc, all under the hood. I'd think that a simple boiler with no moving parts would be vastly simpler, and therefore much smaller.
And I'm not talking about those big honking pansy-assed motorcycle-for-the-water types of jet skiis that you practically can't fall off of. I'm talking the ones that are basically a fiberglass shell holding an engine, with just a tray on the back for the rider to stand on (with the impeller beneath), and a long bar with the controls on the end.
Those things are only 6 feet long or so.
Oh, man, I'd really love to ride one of those with *this* engine!
I can offer a little info on what MS code is like -- at least, what it *was* like, as of 1993, when I was an intern there for one summer. That was on the Excel team.
This was back when Bill Gates was merely a $6 billion-dollar man, and the Excel team still used a Borland code-editor program running on OS/2 (I assume they've changed that since then). The code was still 95% straight C code, though they were using a C++ compiler on it, and a lot of the comments I saw were of the// style.
They used the "hungarian" variable-naming convention. Which, when I got used to it, I rather liked a lot. It lends a certain amount of self-documentation/consistency/navigability to the code, no matter who writes it. I still use a simplified version of it today. Unfortunately, what I saw there was a very, VERY heavy reliance on that aspect -- *actual* comments were very few and far between.
But the most striking aspect of the code, that I could tell, was what I came to call it's being "upgraded beyond all recognition". I could see the remnants of what was once an extremely elegant, well-organized program. But those parts of the code were like a skeleton swimming around inside an 800-pound person. So many features had been added everywhere that it was really turning into a mess -- for example, there were whole multi-level data structures added where you could only get get to them by following a miscellaneous pointer shoved into the struct's of older data structures.
I want to point out, by the way, that this was still a really excellent team of engineers. A lot of fun personalities and just really smart people. But they were subject to the whims of, oh what were they called -- the Program Directors?? Those were a whole other team of people who were totally non-programmers -- their job was to just keep thinking of new features to add, I guess based on user comments, market research, maybe their own "wouldn't it be cool" ideas as well. They would write up some sort of specification of the new features in a standard format, and give them to the programmers, who then had to find some way to stick them in.
When I was there, they had just finished inserting OLE into Excel. My mentor on the team called that "the worst thing that ever happened to the program".
> You have 16 hours a day that you can devote to going back and making the code "good" under the same revenue model that OSS is produced - none at all!
But OSS offers other benefits. The glory possibility is one. But also, since the code is not going to be imprisoned inside some company (or project within a company) that may well go kaput in a few years, it can be inherently more satisfying to write. That can be enough incentive to go write it with some of your extra 16 hours/day instead of watching TV.
Closed source offers *only* the revenue as reward. Yes, of course, if you've got a revenue/overtime-based bonus plan, or you're in a central position within the company (e.g. founder), that's can be a hell of a lot more incentive than what OSS offers. But if you're just a regular-joe programmer in a big company, doing the 8hrs/day that gets you all the revenue you're gonna get, OSS can be an attractive use of the other 16.
> led to military support, arms and training for numerous guerilla organizations that either inflicted suffering on their own people (Honduras and Guatemala)...
Don't forget Iraq!:)
>... or that turned out to be ill considered allies (like the Taliban).
Actually, the Taliban didn't exist at the time the US was supporting Afghanistan against the USSR. Back then, the CIA was supporting/coordinating (along with others such as one Osama Bin Laden) miscellaneous groups of locals. Though you could say it was the same thing, since these locals were rebelling aginst the USSR largely because the Soviets were trying to impose modern ideas of culture on them -- e.g. equality for women. And the Taliban came to embody the most extreme version of that attitude.
Of course, the Taliban *did* come to power due to support from an outside source -- Pakistan. Which, er, is *now* being supported by the U.S. in the War on Terrorism. Ugh.
> If developing countries adopt OSS policy, that severely limits the growth potential and forces microsoft into a position it doesn't want to be in.
Yeah, it might even have to pay dividends to stock holders to make their stock worth something, when they recognize that the price won't go up anymore.
Definitely. The only time it's not is when you're hunting-and-pecking.
I generally look at the screen while I type; my fingers find the keys by themelves -- and tactile feedback is important for that. I don't see how touch typing could work with this kind of keyboard.
You know, that would be a good type of project for classes in the 9-12 levels: develop educational software for the K-8 levels. Talk about open source feeding upon itself!
I suspect you are both right: the 2nd article seems to refer to the time-reversal-antenna technique; the 1st, Blast. Perhaps these are two completely different systems?
Re:Cell Phones = Cancer is BULLSHIT
on
Reflections
·
· Score: 1
> Why do I have a headache after using my cellphone?
My guess would be stress. Humans generally increase their stress levels when they talk to other humans (I saw a psychologist mentioning that on some tv news thing about the thereputic effects of pets). Talking to someone on the phone probably does it more, and a cell phone possibly even more so, since the receiver is generally smaller, sound quality poor, etc.
Try to observe yourself next time: when you hang up the cell phone, do you feel as though you've been holding any muscles in your head or face tight for a long time? Or in other areas of your body? If so, you may be able to train yourself to relax those muscles; see if that works.
Re:Cool? Yes, but when?
on
Reflections
·
· Score: 1
> From the second article: "For the time being, the communication technique is limited to ultrasonic communication -...
But from the first article:
> Prototypes of the system, called Blast, can send data over third-generation, or 3G, cellphone networks at rates about eight times those of 3G.
and
> Bell Labs has made prototype chips that would allow Blast to operate at speeds of 19.2 megabits per second over a 3G wireless network. Currently the highest speed those networks can offer is 2.5 megabits per second. Ran Yan, vice president for wireless research at Bell Labs, said that the prototype chips were intended for use in a cellphone or wireless hand-held computer.
Sounds like the articles are talking about two completely different systems, using different techniques. Apparently Blast is using something simple enough to be implementable today -- and has been. The theoretical research that the first article describes may be something much more complex. I don't know if one would be fundamentally better than the other.
Re:So it wont work for CDMA
on
Reflections
·
· Score: 1
> I can't be bothered to decipher these fluff articles, but it looks like these guys have merely added a phased-array antenna to the conventional CDMA approach. It is neat, but once you have the concept of making multipath work for you, it isn't much of a leap.
The article talks of the necessity of there being multiple *transmitter* antennae as well, so I'm guessing it's different than what you're talking about.
> The people--from the CEOs to the Unix sysadmins--who worked for dot-coms with phony business plans should ALL take responsibility for the current sorry state of the economy.
Ahh, they only started it. The real blows came from the mistrust sewn by the Enrons/Worldcoms/etc.
> Edison invented the electric chair as part of his marketting campaign for DC - the chair used AC.
And it really backfired -- the execution went so horribly, disgustingly wrong that people thought "well, if it's *that* hard to kill someone with AC on *purpose*, I guess it doesn't seem so dangerous to have it in my home."
> In the case where you have an infinite loop bug your CPU usage will eventually hit 100% and the computer will lock up.
That'd only be true with a pre-NT Windows OS (i.e. '95, '98' ME, etc). Also the older Mac OS's, I believe. Any OS with true multitasking abilities will allow any program to be interrupted and killed, even if it's in an infinite loop. Unless, of course, the loop is within the kernel code. Which would be a major bug. Well, ok, so there go all the other versions of Windows.
But anyways, any OS which *doesn't* have multitasking won't be able to make use of HT anyways.
> But HT sounded like a way to more efficiently use the pipelines on modern processors by allowing multiple threads to work on them.
Not the pipeline itself; more like the *resources* that the chip has -- e.g. if you have 2 floating-point multipliers, 2 dividers, and 3 integer units, you're going to find it difficult to keep them all busy with just a single thread, unless you're running a very math-intensive process. Similarly for other types of resources, such as memory access, etc. Having multiple threads automatically removes a lot of the inter-instruction dependencies that the CPU sees, and thus allows it to throw more work at the resources (on average).
> Do the multiple threads need to be in the same process?
That's purely an OS issue; the CPU really doesn't know the difference. HT's job on the CPU is to make it act like two physical processors. It's then up the the OS to decide how to use it.
> Also, if some of the posts are correct it seems that multiple processors show up in Top. Off hand I wonder if this hamper or help OpenMosix's algorithms that decide where to place processes to run.
I don't know anything about OpenMosix, but the OS kernel does need to take new info into account to be able to fully optimize things, as discussed in the article.
Slashdot Mirror
> Encryption will always be broken.
Theoretically true, perhaps, but practially impossible if you use a big enough key.
But there's another concern too -- if some chunk of your data exists *only* on some random person's hard drive, how can you be assured that it'll be there when you need it? Maybe that person won't have his computer on, or the drive will have crashed, etc. You can have multiple copies of everything, but there's a better way: error-correction encoding!
This would be just like a RAID array. The data would be split up among random host machines (every Nth bit goes to host 1, N+1 goes to host 2, N+3...), with extra redundant bits added accoring to the encoding, such that the data can be recovered 2 or 3 hosts aren't accessible.
This would also render your data very difficult to steal -- unless the theif could somehow find where enough of your different bits are being stored.
> How much does it weigh? For all I know it could sink a jetski, an area where this could apply.
Whoops, I missed this part. Let me address it.
According to the article, their 20-cm prototype produced 30 horsepower. I'm pretty rusty on my numbers, but the article said it'd be enough for a speedboat -- so a jet ski could probably do very well with something even smaller. Perhaps not much heavier than the current impeller mechanism.
> Ahem. Where you getting the steam from, buddy? If you are burning something, you need an oxidizer as well(a torpedo runs underwater...).
Uhh, if a torpedo is using a propeller, what engine is driving the propeller? Gas turbine? Don't you need oxidizer for that too? I suspect this is a solved problem.
> And I strongly suspect this engine isn't as fuel efficient as standard piston or turbines anyway.
I don't know about turbine, but a piston engine is only 20-30% efficient -- it's not hard to see this at least matching that.
Let's see -- making the steam and transferring that heat to the chamber will be near 100%. Then it's a matter of how much of the shockwave energy goes out the front vs. the back of the engine. I don't see that causing a loss of more than 50% -- probably less once it really gets moving, with all the water rushing in the front. The heating of the water will be a loss too, I guess, but probably not too much. Yeah, I can see this beating 30%.
> I wonder how small an effective boiler can be made.
This might be an indication.
> One question... What if they run into a school of tuna? ;-)
Well, then you have a new fishing technique, too. Could even put the canning machinery right on the boat -- just aim the engine into the input, and let 'er rip!
> Have you ever gone for a ride in a small boat of current design? I wouldn't exactly classify them as silent. In fact, it's more along the lines of too loud for even a shouted conversation of any useful length.
This actually would be the above-water noise. I don't know how much the actual propeller transmits into the water, but it's probably less.
> For all we know the lack of prop cavitation and direct transmission of engine vibration through the drive shaft to the water might in fact make this a quieter engine!
Yes -- as you say here, the sound will likely go mostly into the water, not the air. So while it would very likely be much quieter above-water, below-water it could be worse.
Though as you say, we of course need actual measurements to answer the question.
I really hope it's quieter!
> I highly doubt this would become mainstream in any smaller craft. The design would require revamping most current hull designs to accomodate an intake for better waterflow to the motor.
Jet skiis are already designed with this sort of thing in mind -- they just use an impeller where this engine would go.
> Also, how big is the motor? It might be far too cumbersome to fit in anything less than a 20 foot boat.
A jet ski can fit a good-sized 2-cylender engine, complete with starter moter & battery, water cooling system, etc, all under the hood. I'd think that a simple boiler with no moving parts would be vastly simpler, and therefore much smaller.
And I'm not talking about those big honking pansy-assed motorcycle-for-the-water types of jet skiis that you practically can't fall off of. I'm talking the ones that are basically a fiberglass shell holding an engine, with just a tray on the back for the rider to stand on (with the impeller beneath), and a long bar with the controls on the end.
Those things are only 6 feet long or so.
Oh, man, I'd really love to ride one of those with *this* engine!
I can offer a little info on what MS code is like -- at least, what it *was* like, as of 1993, when I was an intern there for one summer. That was on the Excel team.
// style.
:)
This was back when Bill Gates was merely a $6 billion-dollar man, and the Excel team still used a Borland code-editor program running on OS/2 (I assume they've changed that since then). The code was still 95% straight C code, though they were using a C++ compiler on it, and a lot of the comments I saw were of the
They used the "hungarian" variable-naming convention. Which, when I got used to it, I rather liked a lot. It lends a certain amount of self-documentation/consistency/navigability to the code, no matter who writes it. I still use a simplified version of it today. Unfortunately, what I saw there was a very, VERY heavy reliance on that aspect -- *actual* comments were very few and far between.
But the most striking aspect of the code, that I could tell, was what I came to call it's being "upgraded beyond all recognition". I could see the remnants of what was once an extremely elegant, well-organized program. But those parts of the code were like a skeleton swimming around inside an 800-pound person. So many features had been added everywhere that it was really turning into a mess -- for example, there were whole multi-level data structures added where you could only get get to them by following a miscellaneous pointer shoved into the struct's of older data structures.
I want to point out, by the way, that this was still a really excellent team of engineers. A lot of fun personalities and just really smart people. But they were subject to the whims of, oh what were they called -- the Program Directors?? Those were a whole other team of people who were totally non-programmers -- their job was to just keep thinking of new features to add, I guess based on user comments, market research, maybe their own "wouldn't it be cool" ideas as well. They would write up some sort of specification of the new features in a standard format, and give them to the programmers, who then had to find some way to stick them in.
When I was there, they had just finished inserting OLE into Excel. My mentor on the team called that "the worst thing that ever happened to the program".
I wonder what's happened since then?
> You have 16 hours a day that you can devote to going back and making the code "good" under the same revenue model that OSS is produced - none at all!
But OSS offers other benefits. The glory possibility is one. But also, since the code is not going to be imprisoned inside some company (or project within a company) that may well go kaput in a few years, it can be inherently more satisfying to write. That can be enough incentive to go write it with some of your extra 16 hours/day instead of watching TV.
Closed source offers *only* the revenue as reward. Yes, of course, if you've got a revenue/overtime-based bonus plan, or you're in a central position within the company (e.g. founder), that's can be a hell of a lot more incentive than what OSS offers. But if you're just a regular-joe programmer in a big company, doing the 8hrs/day that gets you all the revenue you're gonna get, OSS can be an attractive use of the other 16.
> led to military support, arms and training for numerous guerilla organizations that either inflicted suffering on their own people (Honduras and Guatemala)...
:)
... or that turned out to be ill considered allies (like the Taliban).
Don't forget Iraq!
>
Actually, the Taliban didn't exist at the time the US was supporting Afghanistan against the USSR. Back then, the CIA was supporting/coordinating (along with others such as one Osama Bin Laden) miscellaneous groups of locals. Though you could say it was the same thing, since these locals were rebelling aginst the USSR largely because the Soviets were trying to impose modern ideas of culture on them -- e.g. equality for women. And the Taliban came to embody the most extreme version of that attitude.
Of course, the Taliban *did* come to power due to support from an outside source -- Pakistan. Which, er, is *now* being supported by the U.S. in the War on Terrorism. Ugh.
> ... all the posts from people who seem to think that knowing anything about the superbowl or football in genereal makes them weird ...
It's not about that.
It's about revenge.
> If developing countries adopt OSS policy, that severely limits the growth potential and forces microsoft into a position it doesn't want to be in.
Yeah, it might even have to pay dividends to stock holders to make their stock worth something, when they recognize that the price won't go up anymore.
Oh, wait a minute...
> They could invest in nailing the problems they wish to solve with no worries about future price hikes and inter-op.
Yeah:
Step 1: Rewrite all OSS code in Ada
Step 2: ???
Step 3: Buy more MS code. Microsoft profits!
Wow, I didn't know the *spelling* was different in Australia too... ;)
> ... daylight
Heh -- there's a rather fatal error: what happens when the sun is shining on the window?
> the feel of keyboards which is important too.
Definitely. The only time it's not is when you're hunting-and-pecking.
I generally look at the screen while I type; my fingers find the keys by themelves -- and tactile feedback is important for that. I don't see how touch typing could work with this kind of keyboard.
You know, that would be a good type of project for classes in the 9-12 levels: develop educational software for the K-8 levels. Talk about open source feeding upon itself!
> You were close, but not on.
I suspect you are both right: the 2nd article seems to refer to the time-reversal-antenna technique; the 1st, Blast. Perhaps these are
two completely different systems?
> Why do I have a headache after using my cellphone?
My guess would be stress. Humans generally increase their stress levels when they talk to other humans (I saw a psychologist mentioning that on some tv news thing about the thereputic effects of pets). Talking to someone on the phone probably does it more, and a cell phone possibly even more so, since the receiver is generally smaller, sound quality poor, etc.
Try to observe yourself next time: when you hang up the cell phone, do you feel as though you've been holding any muscles in your head or face tight for a long time? Or in other areas of your body? If so, you may be able to train yourself to relax those muscles; see if that works.
> From the second article: "For the time being, the communication technique is limited to ultrasonic communication -...
But from the first article:
> Prototypes of the system, called Blast, can send data over third-generation, or 3G, cellphone networks at rates about eight times those of 3G.
and
> Bell Labs has made prototype chips that would allow Blast to operate at speeds of 19.2 megabits per second over a 3G wireless network. Currently the highest speed those networks can offer is 2.5 megabits per second. Ran Yan, vice president for wireless research at Bell Labs, said that the prototype chips were intended for use in a cellphone or wireless hand-held computer.
Sounds like the articles are talking about two completely different systems, using different techniques. Apparently Blast is using something simple enough to be implementable today -- and has been. The theoretical research that the first article describes may be something much more complex. I don't know if one would be fundamentally better than the other.
> I can't be bothered to decipher these fluff articles, but it looks like these guys have merely added a phased-array antenna to the conventional CDMA approach. It is neat, but once you have the concept of making multipath work for you, it isn't much of a leap.
The article talks of the necessity of there being multiple *transmitter* antennae as well, so I'm guessing it's different than what you're talking about.
> The people--from the CEOs to the Unix sysadmins--who worked for dot-coms with phony business plans should ALL take responsibility for the current sorry state of the economy.
Ahh, they only started it. The real blows came from the mistrust sewn by the Enrons/Worldcoms/etc.
> Edison invented the electric chair as part of his marketting campaign for DC - the chair used AC.
And it really backfired -- the execution went so horribly, disgustingly wrong that people thought "well, if it's *that* hard to kill someone with AC on *purpose*, I guess it doesn't seem so dangerous to have it in my home."
And so AC took off.
> In the case where you have an infinite loop bug your CPU usage will eventually hit 100% and the computer will lock up.
That'd only be true with a pre-NT Windows OS (i.e. '95, '98' ME, etc). Also the older Mac OS's, I believe. Any OS with true multitasking abilities will allow any program to be interrupted and killed, even if it's in an infinite loop. Unless, of course, the loop is within the kernel code. Which would be a major bug. Well, ok, so there go all the other versions of Windows.
But anyways, any OS which *doesn't* have multitasking won't be able to make use of HT anyways.
> But HT sounded like a way to more efficiently use the pipelines on modern processors by allowing multiple threads to work on them.
Not the pipeline itself; more like the *resources* that the chip has -- e.g. if you have 2 floating-point multipliers, 2 dividers, and 3 integer units, you're going to find it difficult to keep them all busy with just a single thread, unless you're running a very math-intensive process. Similarly for other types of resources, such as memory access, etc. Having multiple threads automatically removes a lot of the inter-instruction dependencies that the CPU sees, and thus allows it to throw more work at the resources (on average).
> Do the multiple threads need to be in the same process?
That's purely an OS issue; the CPU really doesn't know the difference. HT's job on the CPU is to make it act like two physical processors. It's then up the the OS to decide how to use it.
> Also, if some of the posts are correct it seems that multiple processors show up in Top. Off hand I wonder if this hamper or help OpenMosix's algorithms that decide where to place processes to run.
I don't know anything about OpenMosix, but the OS kernel does need to take new info into account to be able to fully optimize things, as discussed in the article.