I think the innovation is coming in the forms of new encoding formats, portable devices, and music distribution schemes. Don't throw the baby out with the bath water. These innovations have merit, despite how someone might use them to commit copyright violation.
This movie lacked genius and direction. It shyed away from posing the questions that Katz seems to think it does and hides them under an extraneous forty minutes of wandering. When movie critics are surprised by a plot twist and a movie doesn't go where they expect, they herald this as some mark of genius. This was just a wandering, poorly thought out, anti-climatic, weak movie.
If you were expecting this movie to be epic, or to ask the really tough questions about what it is to be human and machine, then you won't find that. If you expect this to parallel Frankenstein, you'd be better off reading Frankenstein. The classics did it far far better than AI could ever hope to hold a candle to.
It seems Intel may have bet the farm on Marketecture...20 stage pipeline to reach multiple gigahertz speeds, double pumped ALUs that run at twice core clockspeed, a trace cache of recently decoded RISC "micro-ops", and SSE2, almost 200 new floating point SIMD instructions that are supposed to give incredible performance. Yet the Pentium 4 has trouble against a lower clocked Athlon in many many benchmarks.
Intel is the market leader, but they shouldn't let their marketing team design their chips!
AMD in good position to take 30%
on
nVidia nForce
·
· Score: 5
AMD recently claimed they would have 30% overall market share by the end of the year, their goal before launching their 64 bit processor. It seems they are on track to meet those expectations. With NVidia's chipset offering a low-cost affordable solution for low-end machines and the 760MP chipset offering us the world's first multiprocessor AMD platform, they are putting themselves in a position to have real sway in the coming 64 bit desktop revolution.
Just because the original poster didn't mention compression doesn't mean it's not a factor or not worth considering. In fact, is the factor that I pointed out which made his claims (or reckonings) inaccurate.
...and recognises that there is a non-zero increase in the amount of data being transmitted because of encryption.
And I pointed out the indeed, the total data transmitted (think bits) does increase because of encryption (beyond transmission of keys/etc) in a situation with compression, such as a modem, which is a very important consideration.
Perhaps we should take a breather before jumping on things so quickly?
Oh, for pointing out something the poster missed, and something that turns out to be very important and is counter to the poster's claims?
Eh, wrong, at least when it comes to compressed communications protocols. If you know anything about information theory, encryption increases the entropy of the information, while compression increases the rate. Compression in the communication phase relies on the ability to find repeated data or some pattern in the data(as all compression schemes do). Encryption before transmission (as in over a modem) significantly reduces the possibility for compressing the data by hiding the repeated data and the patterns.
Not convinced? gzip a text file. Then gzip a DES-ed copy of the same original text file. Compare sizes.
Completely unfounded FUD. They aren't planning on putting some kind of HAL on the damn ship. The AI they are using is more like fuzzy logic than anything. AI is such a misnomer...
See how many traders react the same way to [news that is 5 months old]!? Seriously, anyone who knows ANYTHING about AMD or Transmeta or would care enough to invest their money in either one would have heard about this long ago. Sheesh.
I am also currently working on my own hobby Open Source OS, and have considered a job at Be after I graduate, doing kernel level stuff. The thing I was concerned about was Be reacting to my involvement in an Open Source project where I might feel compelled to implement similar solutions to the BeOS kernel, and thus leak Be's trade secrets. I am sure this would be a serious issue for someone in my position, but I wonder, as an ex-employee, whether the author of this OS has received any heat from his former employer.
I don't find this to terribly new. There are literally hundreds of OS projects like this one, at various stages of completion. Read alt.os.development sometime, there are plenty of brilliant people toiling away on their hobby operating systems. Recently the developer (or someone pushing it) posted a link to this OS on the newsgroup, but the page was in Italian or Portugese. Needless to say, good way to frustrate a bunch of OS developers!
For some info on developing your own OS check out:
http://www.execpc.com/~geezer/os/
Is just one of the regulars (well not too regular these days) on the newsgroup. The "Triple Fault Club" is kind of funny actually. Everyone's OS has flummoxed many a frustrated x86 processor at some point! From his site I learned some of the ropes. Also check out some of the sites on the webring. Many OSes, varying from toys to useable systems.
BTW, people on the newsgroup generally sneer at any OS named ____OS or ___ix. There are so many ChrisOS, and DaveOS, and Winix and Finix and Pukenix, etc...
There is this huge point about the size of _Alaska_ that you all are apparently missing. The Supreme Court isn't trying to legislate from the bench and make pornography illegal or make judgements on its moral character, but rather to give local governments the power to enforce their own enacted decency laws! They aren't trying to push their own agenda, they are trying to make the enforcement of laws (which YOU have put in place) possible. Plain and simple.
It's Orwellian! It's fascist! They are trying to brainwash us with their Puritan values!
Notice the words "carrying capacity" in what you just quoted? That means they can ramp up the amount of power carried by the lines which risking burning them UP!
Weather _never_ reaches an equilibrium, or steady state condition. There are several variables, all linked to divergent forces.
1 - Gravitational contraction. The sheer pressure of matter crushing into the center of a planet or moon generates heat. This continual heat dissipation through the core and outer layers leads to convection in the core and heats the atmosphere. Heating of the atmosphere causes convection, like a pot of boiling soup, but at a much much colder temperature.
2 - Light the from Sun. The Sun is immensely powerful and yes, does heat Titan, even from that distance.
3 - Gravitational interactions with Saturn. Saturns gravity distorts its moons as they orbit, causing techtonic activity. Titan would also have gravitational interactions from the other moons.
4 - Coriolis effect. This is the kicker. Since Titan is spinning, a small perterbation in the pressure in one part of the atmosphere causes the gases rushing in to balance the pressure to swirl because gas near the equator is moving faster than that at the poles. This is the base force for weather on earth and all bodies with an atmosphere.
5 - Dust and rocks. Titan, like all bodies in the solar system, is continually showered with dust and rocks of all sizes. These all cause perterbations in the atmosphere, and since these forces are so divergent, they affect the entire atmosphere.
I would like to have a disk drive that is artifically intelligent, can do my dishes, teach me calculus, pleasure me sexually, and take out the trash for me.
Lots of shirking the responsibility seems to be going on in this discussion. Sure system admins should be informed about security and keep with patches and all, but to some degree, fault must inevitably lie with software vendors who don't have a deep commitment to producing trustworthy (read: secure) software. And that's not just Microsoft.
A program can be provably invulnerable from certain attacks, but undecideable on other attacks. It's a shame that software most often fails on the most obvious and straightforward of fronts to defend: buffer overflows. Something along the lines of 30-60% of all exploits make use of buffer overflows. However, checking for such weaknesses can be carried out by a sufficiently capable automated tool. With as common a problem as buffer overflows have been, you would think that it would be foremost in people's minds when designing against flaws. If you left your door unlocked and were robbed seven times in a row, wouldn't you start locking your front door as the first measure?
It's a small example but indicative of a larger problem I am trying to frame. Software vendors, hobbyists, open source developers, just don't think about these things. They write software in an ad hoc fashion intended to be configurable and carry out a service, so intent on the goal that they fail to consider the larger context. They believe an exploit or a security flaw is something blatant and obvious in the code, or they base their assumptions on a narrower range of input than the application will be exposed to. And even in that case, they see a security flaw as just another bug to patch in the next release, as innocuous as the something like a memory leak.
Software that provides services is meant to do that. To everyone. And if not to everyone, to a select group of people who must be authenticated and authorized. Those mechanisms must be engineered to be extremely fault tolerant. Unfortunately, they often are not.
The software vendors to carry blame for this. Don't push this off onto system administrators for not knowing "how to configure" something. That's a poor excuse. They should be informed, of course, but their software should be secure, out of the box. Correct software isn't patchwork. It is carefully designed, carefully crafted to fit together but remain modular. It is not a series of patches with various nebulous origins to fix flaw after flaw in far flung parts of the code. Despite what you want to claim, secure, well-engineered software truly is a Cathedral, and not a Bazaar.
Simply throwing bugfixes at a problem won't fix and underlying engineering flaw. Throwing your code at people won't fix its design flaws. Take for example Kerberos. Nearly ten years it spent in the open source community as a secure protocol for providing services. The code was in the open and everyone just assumed that it was correct. In two weeks of studying the code at Purdue, a flaw was discovered that allowed the encryption to be subverted and tickets forged in less than a tenth of a second. The flaw had been in the code for ten years, because no one with enough training bothered to look for it.
Like I said, throwing patches at a problem isn't going to fix an engineering flaw, throwing your code at people isn't going to fix your design flaws. Until vendors realize this (which will probably be never) and start designing secure software from the ground up, there will always be buffer overflows, always exploits, always patches. A lot of services are set up to be turn-key, infeasible for the application to have a babysitter to patch the software night and day. Blaming system admins for their systems be penetrable? Who wrote the software again?
Hacker's a dumb word anyway. Security professionals don't call themselves "hackers". It implies a substandard, ad hoc solution to a problem lacking formal verification. It's the difference between the terms "Structural Engineer" and "Carpenter".
I am working on a pretty loose definition of Severity 1 and 2 (on a scale from 1 to 5), but one that had should have pretty intuitive interpretation. Basically a Severity 1 bug would amount to unusable software, Severity 2 would severely handicap usability.
I think the whole notion that software with non-zero "value" is a gain is preposterous. Aiming for just above worthless isn't what software designers should be doing these days. If 95% of Word was broken, crashed your system, and revealed all your personal information, but it could still edit text files, you might try to construe it as having some value. That's an improper evaluation. The more desirable evaluation (in fact the only evaluation) is whether the software meets its itemized requirements. In the example of the severely handicapped Word, and I argue any software containing bugs of Severity 1 or 2, it is obvious that this is not the case. The software simply hasn't met the requirements.
This is more than me just being pedantic. It is a very important distinction between today's corporate drive to deliver and proper software engineering. Broken, buggy software, like I said, is irresponsible. It doesn't meet the requirements, and therefore it shouldn't be released. Expecting people to "put up" with it, and trying to rationalize the presence of serious issues that should be addressed is what makes software, well, suck.
I'm not even going to go into the debate over whether Open Source addresses these issues or not, or whether its a solution to a larger problem, but it's high time that software vendors put some true engineering into their products and had some dedication to the final output. Crapping out buggy software that has some "value" but doesn't meet its requirements just isn't enough.
It's irresponsible to release software that has at least one known Severity 1 or Severity 2 bug. The software is obviously not even complete, so why would you even toy with the idea of releasing it? And if those bugs aren't *known* at release time, then congrats, your testing team needs a good kick in the pants. "What testing team?" Oooh. That testing team. Yeah.
Neither does the notion that the computer will inevitably win hold any water. Chess is a well understood finite situation? Even finite problems can be intractable or undecideable, in which case computers could not ever arrive at a single, verifyable solution. That is something a human can do, through intuition, which is a mysterious and powerful trait of intelligence. A human can prove something with an insight into the problem, a computer could never.
And Kasparov being beaten by Deep Blue? How many times had he defeated "chess master" machines prior? The fact the human brain can compete with and even defeat a machine with its incredible computational power says a lot in itself.
Slashdot Mirror
Well, I don't know about you, but the thought of Clippy with its big dumb eyes behind THE button....whew. Scary.
I think the innovation is coming in the forms of new encoding formats, portable devices, and music distribution schemes. Don't throw the baby out with the bath water. These innovations have merit, despite how someone might use them to commit copyright violation.
This movie lacked genius and direction. It shyed away from posing the questions that Katz seems to think it does and hides them under an extraneous forty minutes of wandering. When movie critics are surprised by a plot twist and a movie doesn't go where they expect, they herald this as some mark of genius. This was just a wandering, poorly thought out, anti-climatic, weak movie.
If you were expecting this movie to be epic, or to ask the really tough questions about what it is to be human and machine, then you won't find that. If you expect this to parallel Frankenstein, you'd be better off reading Frankenstein. The classics did it far far better than AI could ever hope to hold a candle to.
It seems Intel may have bet the farm on Marketecture...20 stage pipeline to reach multiple gigahertz speeds, double pumped ALUs that run at twice core clockspeed, a trace cache of recently decoded RISC "micro-ops", and SSE2, almost 200 new floating point SIMD instructions that are supposed to give incredible performance. Yet the Pentium 4 has trouble against a lower clocked Athlon in many many benchmarks.
Intel is the market leader, but they shouldn't let their marketing team design their chips!
Roads? Where we're going, we don't need "roads"!
AMD recently claimed they would have 30% overall market share by the end of the year, their goal before launching their 64 bit processor. It seems they are on track to meet those expectations. With NVidia's chipset offering a low-cost affordable solution for low-end machines and the 760MP chipset offering us the world's first multiprocessor AMD platform, they are putting themselves in a position to have real sway in the coming 64 bit desktop revolution.
Just because the original poster didn't mention compression doesn't mean it's not a factor or not worth considering. In fact, is the factor that I pointed out which made his claims (or reckonings) inaccurate.
...and recognises that there is a non-zero increase in the amount of data being transmitted because of encryption.
And I pointed out the indeed, the total data transmitted (think bits) does increase because of encryption (beyond transmission of keys/etc) in a situation with compression, such as a modem, which is a very important consideration.
Perhaps we should take a breather before jumping on things so quickly?
Oh, for pointing out something the poster missed, and something that turns out to be very important and is counter to the poster's claims?
Eh, wrong, at least when it comes to compressed communications protocols. If you know anything about information theory, encryption increases the entropy of the information, while compression increases the rate. Compression in the communication phase relies on the ability to find repeated data or some pattern in the data(as all compression schemes do). Encryption before transmission (as in over a modem) significantly reduces the possibility for compressing the data by hiding the repeated data and the patterns.
Not convinced? gzip a text file. Then gzip a DES-ed copy of the same original text file. Compare sizes.
Completely unfounded FUD. They aren't planning on putting some kind of HAL on the damn ship. The AI they are using is more like fuzzy logic than anything. AI is such a misnomer...
And just because it's free doesn't mean it's good either.
No, x86-64 runs x86 code just fine and dandy, natively.
See how many traders react the same way to [news that is 5 months old]!? Seriously, anyone who knows ANYTHING about AMD or Transmeta or would care enough to invest their money in either one would have heard about this long ago. Sheesh.
I am also currently working on my own hobby Open Source OS, and have considered a job at Be after I graduate, doing kernel level stuff. The thing I was concerned about was Be reacting to my involvement in an Open Source project where I might feel compelled to implement similar solutions to the BeOS kernel, and thus leak Be's trade secrets. I am sure this would be a serious issue for someone in my position, but I wonder, as an ex-employee, whether the author of this OS has received any heat from his former employer.
I don't find this to terribly new. There are literally hundreds of OS projects like this one, at various stages of completion. Read alt.os.development sometime, there are plenty of brilliant people toiling away on their hobby operating systems. Recently the developer (or someone pushing it) posted a link to this OS on the newsgroup, but the page was in Italian or Portugese. Needless to say, good way to frustrate a bunch of OS developers!
For some info on developing your own OS check out:
http://www.execpc.com/~geezer/os/
Is just one of the regulars (well not too regular these days) on the newsgroup. The "Triple Fault Club" is kind of funny actually. Everyone's OS has flummoxed many a frustrated x86 processor at some point! From his site I learned some of the ropes. Also check out some of the sites on the webring. Many OSes, varying from toys to useable systems.
BTW, people on the newsgroup generally sneer at any OS named ____OS or ___ix. There are so many ChrisOS, and DaveOS, and Winix and Finix and Pukenix, etc...
But of course there is MacOS and Linux...
There is this huge point about the size of _Alaska_ that you all are apparently missing. The Supreme Court isn't trying to legislate from the bench and make pornography illegal or make judgements on its moral character, but rather to give local governments the power to enforce their own enacted decency laws! They aren't trying to push their own agenda, they are trying to make the enforcement of laws (which YOU have put in place) possible. Plain and simple.
It's Orwellian! It's fascist! They are trying to brainwash us with their Puritan values!
Gimme a break.
Notice the words "carrying capacity" in what you just quoted? That means they can ramp up the amount of power carried by the lines which risking burning them UP!
Weather _never_ reaches an equilibrium, or steady state condition. There are several variables, all linked to divergent forces.
1 - Gravitational contraction. The sheer pressure of matter crushing into the center of a planet or moon generates heat. This continual heat dissipation through the core and outer layers leads to convection in the core and heats the atmosphere. Heating of the atmosphere causes convection, like a pot of boiling soup, but at a much much colder temperature.
2 - Light the from Sun. The Sun is immensely powerful and yes, does heat Titan, even from that distance.
3 - Gravitational interactions with Saturn. Saturns gravity distorts its moons as they orbit, causing techtonic activity. Titan would also have gravitational interactions from the other moons.
4 - Coriolis effect. This is the kicker. Since Titan is spinning, a small perterbation in the pressure in one part of the atmosphere causes the gases rushing in to balance the pressure to swirl because gas near the equator is moving faster than that at the poles. This is the base force for weather on earth and all bodies with an atmosphere.
5 - Dust and rocks. Titan, like all bodies in the solar system, is continually showered with dust and rocks of all sizes. These all cause perterbations in the atmosphere, and since these forces are so divergent, they affect the entire atmosphere.
Dear Creative Labs:
I would like to have a disk drive that is artifically intelligent, can do my dishes, teach me calculus, pleasure me sexually, and take out the trash for me.
-Thank you,
this Slashdot article.
Bump this to number 2 on list of things to have on a desert island:
1. Jamie Presley
2. Dell Laptop - new with built in survivor kit!
3. Fresh water
...
Lots of shirking the responsibility seems to be going on in this discussion. Sure system admins should be informed about security and keep with patches and all, but to some degree, fault must inevitably lie with software vendors who don't have a deep commitment to producing trustworthy (read: secure) software. And that's not just Microsoft.
A program can be provably invulnerable from certain attacks, but undecideable on other attacks. It's a shame that software most often fails on the most obvious and straightforward of fronts to defend: buffer overflows. Something along the lines of 30-60% of all exploits make use of buffer overflows. However, checking for such weaknesses can be carried out by a sufficiently capable automated tool. With as common a problem as buffer overflows have been, you would think that it would be foremost in people's minds when designing against flaws. If you left your door unlocked and were robbed seven times in a row, wouldn't you start locking your front door as the first measure?
It's a small example but indicative of a larger problem I am trying to frame. Software vendors, hobbyists, open source developers, just don't think about these things. They write software in an ad hoc fashion intended to be configurable and carry out a service, so intent on the goal that they fail to consider the larger context. They believe an exploit or a security flaw is something blatant and obvious in the code, or they base their assumptions on a narrower range of input than the application will be exposed to. And even in that case, they see a security flaw as just another bug to patch in the next release, as innocuous as the something like a memory leak.
Software that provides services is meant to do that. To everyone. And if not to everyone, to a select group of people who must be authenticated and authorized. Those mechanisms must be engineered to be extremely fault tolerant. Unfortunately, they often are not.
The software vendors to carry blame for this. Don't push this off onto system administrators for not knowing "how to configure" something. That's a poor excuse. They should be informed, of course, but their software should be secure, out of the box. Correct software isn't patchwork. It is carefully designed, carefully crafted to fit together but remain modular. It is not a series of patches with various nebulous origins to fix flaw after flaw in far flung parts of the code. Despite what you want to claim, secure, well-engineered software truly is a Cathedral, and not a Bazaar.
Simply throwing bugfixes at a problem won't fix and underlying engineering flaw. Throwing your code at people won't fix its design flaws. Take for example Kerberos. Nearly ten years it spent in the open source community as a secure protocol for providing services. The code was in the open and everyone just assumed that it was correct. In two weeks of studying the code at Purdue, a flaw was discovered that allowed the encryption to be subverted and tickets forged in less than a tenth of a second. The flaw had been in the code for ten years, because no one with enough training bothered to look for it.
Like I said, throwing patches at a problem isn't going to fix an engineering flaw, throwing your code at people isn't going to fix your design flaws. Until vendors realize this (which will probably be never) and start designing secure software from the ground up, there will always be buffer overflows, always exploits, always patches. A lot of services are set up to be turn-key, infeasible for the application to have a babysitter to patch the software night and day. Blaming system admins for their systems be penetrable? Who wrote the software again?
Hacker's a dumb word anyway. Security professionals don't call themselves "hackers". It implies a substandard, ad hoc solution to a problem lacking formal verification. It's the difference between the terms "Structural Engineer" and "Carpenter".
I am working on a pretty loose definition of Severity 1 and 2 (on a scale from 1 to 5), but one that had should have pretty intuitive interpretation. Basically a Severity 1 bug would amount to unusable software, Severity 2 would severely handicap usability.
I think the whole notion that software with non-zero "value" is a gain is preposterous. Aiming for just above worthless isn't what software designers should be doing these days. If 95% of Word was broken, crashed your system, and revealed all your personal information, but it could still edit text files, you might try to construe it as having some value. That's an improper evaluation. The more desirable evaluation (in fact the only evaluation) is whether the software meets its itemized requirements. In the example of the severely handicapped Word, and I argue any software containing bugs of Severity 1 or 2, it is obvious that this is not the case. The software simply hasn't met the requirements.
This is more than me just being pedantic. It is a very important distinction between today's corporate drive to deliver and proper software engineering. Broken, buggy software, like I said, is irresponsible. It doesn't meet the requirements, and therefore it shouldn't be released. Expecting people to "put up" with it, and trying to rationalize the presence of serious issues that should be addressed is what makes software, well, suck.
I'm not even going to go into the debate over whether Open Source addresses these issues or not, or whether its a solution to a larger problem, but it's high time that software vendors put some true engineering into their products and had some dedication to the final output. Crapping out buggy software that has some "value" but doesn't meet its requirements just isn't enough.
It's irresponsible to release software that has at least one known Severity 1 or Severity 2 bug. The software is obviously not even complete, so why would you even toy with the idea of releasing it? And if those bugs aren't *known* at release time, then congrats, your testing team needs a good kick in the pants. "What testing team?" Oooh. That testing team. Yeah.
Please place remaining eye here.
|
v
Neither does the notion that the computer will inevitably win hold any water. Chess is a well understood finite situation? Even finite problems can be intractable or undecideable, in which case computers could not ever arrive at a single, verifyable solution. That is something a human can do, through intuition, which is a mysterious and powerful trait of intelligence. A human can prove something with an insight into the problem, a computer could never.
And Kasparov being beaten by Deep Blue? How many times had he defeated "chess master" machines prior? The fact the human brain can compete with and even defeat a machine with its incredible computational power says a lot in itself.