I can't wait until MS finally loses its dominant desktop position, and the onus of cloning their interfaces to make it acceptable to Windows users is gone, and the OSS world can strike out on its own.
However, given we don't know how Yamhill implements 64-bit x86 instructions Intel will have to do some VERY serious convincing to Linux kernel programmers and to Microsoft to write Yamhill-native code
There's very little asm in the Linux kernel, and I suspect the same holds true for the NT kernel. The largest problem is porting the compiler.
He was talking about Revelations, not the earth ending in 2060. The story submission said that he believed that the earth would end in 2060, not that he believed in Revelations.
If Slashdot is still around in five years and you're still using this account, are you really going to be broken up if you look at your user info page and see one less accepted story? I mean, what does it really matter?
The story submission blows this *waaay* out of proportion. Way to go, Slashdot editors, letting this one through.
Basically, if one reads the article, one finds that Newton made the prediction because *he* was fed up with people setting dates and wanted to put an end to it, and figured that with his repution, he could quiet them down by giving a different date from all of the rest of them.
He wrote: "This I mention not to assert when the time of the end shall be, but to put a stop to the rash conjectures of fancifull men who are frequently predicting the time of the end, & by doing so bring the sacred prophesies into discredit as often as their predictions fail."
Goddamn it, Slashdot stories frequently have incredibly overblown headlines. You have to go read the article to get a *modicum* of useful information anymore.
I thought FLAC was a lossless format so one could record and edit sound files, not for listening
Yup. You can certainly listen to it though.
Do audiophiles really notice the difference between a high quality ogg/mp3 and FLAC?
Not with a portable player and earbuds, they don't.
Is the FLAC file smaller?
No. It's much larger. At the bitrates I usually feel comfortable with, FLAC tends to be over five times as large as ogg. FLAC on this player would be more a gimmick than a useful feature.
In other words, more than my main desktop computer cost.
I'm assuming you're talking about the 20GB version, but even so...you built your computer system (with a display) for less than $400? Did you buy it used or something?
OH NO WHAT SHALL I EVER DO!!! My guess is that i cancel the card and get a new one, uh oh that was so hard I am surely doomed ??
What CC companies usually do is eat the loss, unless it is very large or you've previously contested charges.
So, no, you may not *directly* be responsible for the loss of your CC information. But this is passed on to the consumer through higher rates, annual fees, and surcharges.
My argument is that with all the Internet-connected CC databases and the accelerating rate of compromise of said databases, it is unsustainable for CC companies to keep eating these losses.
Furthermore, it will screw with your credit rating to keep contesting charges and then immediately cancelling cards.
Huh, you're right. Thanks. I'm pretty sure didn't at one point, since I remember writing test code and going through the assembly to see how smart gcc was. The following contruct needed -fexpensive-optimizations:
I want NASA's budget cut because they have failed to provide a ship that meets the original design parameters.
Yeah, if we just get rid of all their mechanical engineers, I'll bet they could build much more reliable shuttles!
Most notably the shuttle's turn around time and payload size. Both of which were cut way back from the original goals.
Yeah. Bastards. NASA is the only organization that doesn't meet initial estimates. Unlike, say, software companies.
No one else *builds* shuttles, you know? It's a little bit hard to *make* accurate estimates. If they simply underestimated everything, would *that* make you happy?
NASA in my opinion is mishandling our money. This has been my opinion for almost 20 years. Two shuttle accidents just prove my point.
You're cranky because of an accident a *decade*? Hell, Ford would *kill* for that kind of record, and they have a *much* easier task to do.
Ignoring for the moment the lives lost: If this had been a normal rocket we had lost then we would not have lost so much money.
The lives lost are essentially irrelevant. Maybe in a couple of hundred million years of shuttle flights, it'll measure up to some of the *other* things that we've done, like WWII or Vietnam. Why do you think they used only military personnel on the shuttle for years and years?
As for being a normal rocket and cost -- sure, it would have cost less. OTOH, the cost *per flight* would have been higher, because the vehicle wouldn't be reusable. There's a *reason* they built the shuttle, laddie buck.
If the shuttle flights were occurring more often then it would have been comparable with loosing say an airliner. Annoying but within expectations. The number of flights would pay for a shuttle loss quicker, maybe enough to be factored into the costs. As it is we have lost a very expensive craft used for very rare missions. 5-6 launches a year is a sorry waste of my tax money for a system designed as if it was running 50 times a year.
Had you been less ignorant about what you were talking about, you'd be aware that the reason shuttle flights were cut so far back from original design parameters is *because* NASA had their funding cut so much since the moon landings.
This is pork barrel spending at it worst hiding behind science and patriotism.
Yeah! We could *obviously* put the money into pursuits *far* more productive for the human race, like blowing up Iraqis! Are you stupid?
Use the Intel compilers, your code will be 50-300% faster.
50-300%? You're nuts. I've used both, and performance definitely varies...and if I had to choose one or the other as "generally producing faster code", I'd probably point at gcc.
American Express and VISA already allow you to generate a single-use number. It's only good for a single transaction at a single point in time.
Yes, but the CC number space isn't large enough to allow this to be a universal solution. (That's ignoring the fact that it's all divided up and whatnot).
I guess you could try to set up some cyclic reuse thing...
But a per-transaction scheme can't, by definition, handle recurring payments.
[shrug] Same system could pretty easily be used to authorize recurring payments.
Frankly, though, I'm not entirely sure that I wouldn't just like my CC company to just send me a bill with *requested* recurring payments, which then get authorized on a per-transaction basis so that I know where my money is going, and I have absolute control over who gets it.
I was responding to your generalized perception that compatibility is as huge an issue as you still perceive it to be, and OS X having it's own advantages over Windows and.net beyond simple eye candy.
Okay, I can get about three interpretations here:
First possibility: what you believe is that instead of writing something using Microsoft's Win32, MFC, or.NET, developers are going to move to a new API because it has some technical advantages. This will marginalize Microsoft's compatibility lever?
All I can say is that historically this is not true, and that I find it unlikely that it will happen now.
Second possibility: you're arguing that APIs supported on OS X are better, so commercial developers will abandon Windows, and code for OS X instead? I find that equally unlikely.
Third possibility: you mentioned open source development. You feel that open source developers will see the benefits of SmallTalk and start using it instead of C on UNIX. First of all, this would have little benefit to Mac users -- most open source developers already code for a POSIX C API, which works fine with OS X. Second of all, there have been many, many more modern languages and VMs available, and open source apps are still almost always written in C, which most people feel is a pretty bad application development language. I don't see this changing either.
Objective C (written by Brad Cox) was trying to bring smalltalk like objected oriented functionality to C.
Most Linux folks already have a free Objective C (The GNU one) compiler installed on their system, and the language *still* gets ignored by the overwhelming majority of open source programmers. I don't think I've ever needed my Objective C compiler to compile a single program I wanted to use.
Java is interesting (and certainly useful against Microsoft in some areas), but has long since turned out to not be what it once was billed as -- a write once run anywhere solution for all applications, including desktop computing. There is a very obvious lack of horizontal-market Java applications, stemming from issues with the Java standard itself, including a lack of templated container classes, and poor performance and memory footprint. Remember that Corel spent a *huge* amount of money porting their suite to Java, and at the end (and I'm *sure* that after that kind of resource expenditure, this was not done without much agonizing consideration) the entire thing was scrapped.
Okay, now what I said, paraphrased, is that "Java is not a universal desktop software environment." STOP. That was my point. Java is not enough to get people off of Windows because it's not used enough. Then, by way of explanation, I wrote that (paraphrased) "this was because of poor performance".
It's *entirely* irrelevant to my argument whether SmallTalk gives better peformance. Or a better structure. Or whether it's more mature. SmallTalk has been around for decades, and it is not widely used for the apps that are keeping people stuck on Windows. Yes, if everyone suddenly started using SmallTalk (in a portable way, so no changes involved to build for another platform) for major desktop apps, it could nail MS. It *doesn't*, however.
we didn't need any fancy computer to whip up characters. Just 3d6, a pencil and paper. Most of the iterations since have just been sales-driven product releases.
With all due respect to the PcGen people, I could never understand the point of a "character generator". You download and install an app so that you can shave a couple of seconds off of character generation? What's the *point*? If anything, you lose part of the gaming experience.
I mean, how often do you need to generate a freaking character?
It's a given that at some point, given the potentially *massive* financial benefits inherent in compromising CC databases, that CCs must go away. They're totally inappropriate for today's society.
The only question is how much money CC providers and companies are going to lose before moving to smartcards that authorize payments on a per-transaction basis.
What I pointed out was what mono will most likely do well is the same GNUStep does well, and that is open up the API's so they can be used in open source projects. Open source projects obviously don't mature overnight.
Again, this is *not* what I was talking about. Libraries to write cross-platform apps are all over the place. There is no lack of those, nor do we need more to stop the Microsoft hegemon.
The problem is whether the most commonly *used* APIs are available across platforms. Nothing else really matters from a compatibility standpoint. OpenGL is an excellent API. It's available *everywhere*. I can write an OpenGL app and compile it wherever I want.
However, it doesn't really *play* a huge role in making the masses of games out there available for Linux and Mac OS, because Direct3d is far more commonly used. So you can have the amazing cross-platform FooBarBaz VM and language, and it means zilch as long as everyone is using Microsoft's own APIs.
Ideally what this will do is not replace the commercial implementaion (.net or cocoa) but rather give developers access to these api's freely and openly, so that ideally they can take advantage of them.
Furthermore, having "open access" to an API is not a problem. You can run out and look up the Win32 API to your heart's content. The problem is having libraries *implementing* that API available.
The issue is what is making.net relevant? What is.net is trying to do? Enable people to write software in a different, object oriented way. People will only have a need to use.net enabled software when such software exists, does something meaningful, and works well.
No, that is *not* the issue. There are *scads* of ways to write object oriented code. There is no lack of ways to do so in a cross platform manner.
This is not the case right now. Sure, Microsoft is pushing the tools, but you know damned well people aren't writing for.net as much as win32, and that's what they're going to continue to do in order to maintain Microsoft's legendary (and necessary) backwards compatibility.
Not last time I was going through win32. Microsoft is pushing *hard* to move developers to.NET. New functionality is not infrequently being exposed *only* though.NET.
SmallTalk is relevant because it is where most of the good aspects of.net are heavily drawn from. The issue between Java and.net isn't about who has it installed - it's about who's writing the next killer application and what it runs on.
Fine. It certainly is not fucking running on SmallTalk. There are SmallTalk implementations for Linux. You know what? I still *don't use a single program written in SmallTalk because almost no one codes for it*.
The problem is that you're trying to make the argument that "SmallTalk is a good environment" or "A lot of modern features originated with SmallTalk" or "People *could* write cross-platform code for SmallTalk". And this has *zero* to do with my post, which has entirely to do with cross-platform compatibility in *commonly used* languages/VMs.
Maybe you do "gotta say" that, but you'd be wrong.
Nope.
As we discussed above, if the key length is less than the message length there will be some difference between pure noise and your signal.
Yup. But that doesn't matter. Not being random is entirely different from not being random in a manner that we can detect. An encryption algorithm that is *detectably* nonrandom is pretty poor.
I assure you, you cannot tell the difference between, say, DES-encrypted data and random data.
That's pretty much definitionally what a good encryption algorithm is.
Sure, given a computer with infinite resources, any crypto algorithm except one-time pads can be broken. The point is that we don't *have* computers with infinite resources. That's why non-one-time-pad crypto is used.
only 3% have stopped buying CDs because prices are too high...
You given Rosen too much credit. *Your statistic might potentially be true*.
According to the submission, 3% buy *fewer* CDs because prices are too high.
That's absolutely ridiculous. Let's take this to the point of absurdity. If I start *giving* away CDs for free, how many people are going to take them? Granted, there might be a few who value CDs negatively (they're afraid of them or something), and a few people who have every CD that they have the remotest interest in). But most people are going to take at least *one* more CD.
If prices go down, sales will go up, and I assure you, more than 3% of the population will get at least one CD more.
The i960 is an embedded processor that doesn't do IA32. You can't boot Windows XP on it.
It depends on what OS you want to run. Alpha is dead, so if you want to run Windows XP, you're going to need IA32 compatibility. Crusoe, Athlon, Duron, Pentium IV, Celeron, Xenon, and C3 are all useable lines of IA32 chips with quite different characteristics.
Apple offers only the G3 and the G4.
Frankly, I don't see why you'd *care* how many architectures there are -- I don't know anyone whose sole demand is wanting to run an oddball architecture, but whatever.
I disagree with you. If you check your history, Apple has the jump in this situation - NextStep/Objective C was doing OOP way before Java was a glimmer in Gosling's eye. I don't know the history that well, but Objective C (written by Brad Cox) was trying to bring smalltalk like objected oriented functionality to C.
This really doesn't relate to what I was talking about. I said that Mono wasn't going to be running neck and neck with Microsoft's.NET implementation for some time, which made Mono not a solution to.NET-implemented software, which is where Microsoft is pushing very hard to get everyone moving.
I have not used SmallTalk, but it's irrelevant to the discussion. It's not used en masse on the desktop, which means it cannot be a tool used to move people out of the MS camp. This is the same issue I mentioned with Java (and even *that* is used more than SmallTalk). The point I was arguing was that Java and Mono are not (currently) enough to break an MS hold on the desktop. SmallTalk is even less so. I really don't care about the technical merits of any of them, at least so far as this discussion goes.
Slashdot Mirror
I can't wait until MS finally loses its dominant desktop position, and the onus of cloning their interfaces to make it acceptable to Windows users is gone, and the OSS world can strike out on its own.
However, given we don't know how Yamhill implements 64-bit x86 instructions Intel will have to do some VERY serious convincing to Linux kernel programmers and to Microsoft to write Yamhill-native code
There's very little asm in the Linux kernel, and I suspect the same holds true for the NT kernel. The largest problem is porting the compiler.
He was talking about Revelations, not the earth ending in 2060. The story submission said that he believed that the earth would end in 2060, not that he believed in Revelations.
If Slashdot is still around in five years and you're still using this account, are you really going to be broken up if you look at your user info page and see one less accepted story? I mean, what does it really matter?
The story submission blows this *waaay* out of proportion. Way to go, Slashdot editors, letting this one through.
Basically, if one reads the article, one finds that Newton made the prediction because *he* was fed up with people setting dates and wanted to put an end to it, and figured that with his repution, he could quiet them down by giving a different date from all of the rest of them.
He wrote: "This I mention not to assert when the time of the end shall be, but to put a stop to the rash conjectures of fancifull men who are frequently predicting the time of the end, & by doing so bring the sacred prophesies into discredit as often as their predictions fail."
Goddamn it, Slashdot stories frequently have incredibly overblown headlines. You have to go read the article to get a *modicum* of useful information anymore.
I'd have to say that that's a legitimate concern.
Most programming languages are designed around keeping a codebase usable even at large sizes.
Most scripting languages are designed around letting small problems be implemented quickly.
They each have a place. Using one in the place of the other really is a bad idea.
I thought FLAC was a lossless format so one could record and edit sound files, not for listening
Yup. You can certainly listen to it though.
Do audiophiles really notice the difference between a high quality ogg/mp3 and FLAC?
Not with a portable player and earbuds, they don't.
Is the FLAC file smaller?
No. It's much larger. At the bitrates I usually feel comfortable with, FLAC tends to be over five times as large as ogg. FLAC on this player would be more a gimmick than a useful feature.
In other words, more than my main desktop computer cost.
I'm assuming you're talking about the 20GB version, but even so...you built your computer system (with a display) for less than $400? Did you buy it used or something?
I use squid on my machine with the sleezeball filter system, so that *all* my browsers are taken care of when I add a filter.
OH NO WHAT SHALL I EVER DO!!! My guess is that i cancel the card and get a new one, uh oh that was so hard I am surely doomed ??
What CC companies usually do is eat the loss, unless it is very large or you've previously contested charges.
So, no, you may not *directly* be responsible for the loss of your CC information. But this is passed on to the consumer through higher rates, annual fees, and surcharges.
My argument is that with all the Internet-connected CC databases and the accelerating rate of compromise of said databases, it is unsustainable for CC companies to keep eating these losses.
Furthermore, it will screw with your credit rating to keep contesting charges and then immediately cancelling cards.
Huh, you're right. Thanks. I'm pretty sure didn't at one point, since I remember writing test code and going through the assembly to see how smart gcc was. The following contruct needed -fexpensive-optimizations:
if (a < 2)
{
if (a < 3) foo
else bar;
}
baz;
}
I want NASA's budget cut because they have failed to provide a ship that meets the original design parameters.
Yeah, if we just get rid of all their mechanical engineers, I'll bet they could build much more reliable shuttles!
Most notably the shuttle's turn around time and payload size. Both of which were cut way back from the original goals.
Yeah. Bastards. NASA is the only organization that doesn't meet initial estimates. Unlike, say, software companies.
No one else *builds* shuttles, you know? It's a little bit hard to *make* accurate estimates. If they simply underestimated everything, would *that* make you happy?
NASA in my opinion is mishandling our money. This has been my opinion for almost 20 years. Two shuttle accidents just prove my point.
You're cranky because of an accident a *decade*? Hell, Ford would *kill* for that kind of record, and they have a *much* easier task to do.
Ignoring for the moment the lives lost: If this had been a normal rocket we had lost then we would not have lost so much money.
The lives lost are essentially irrelevant. Maybe in a couple of hundred million years of shuttle flights, it'll measure up to some of the *other* things that we've done, like WWII or Vietnam. Why do you think they used only military personnel on the shuttle for years and years?
As for being a normal rocket and cost -- sure, it would have cost less. OTOH, the cost *per flight* would have been higher, because the vehicle wouldn't be reusable. There's a *reason* they built the shuttle, laddie buck.
If the shuttle flights were occurring more often then it would have been comparable with loosing say an airliner. Annoying but within expectations. The number of flights would pay for a shuttle loss quicker, maybe enough to be factored into the costs. As it is we have lost a very expensive craft used for very rare missions. 5-6 launches a year is a sorry waste of my tax money for a system designed as if it was running 50 times a year.
Had you been less ignorant about what you were talking about, you'd be aware that the reason shuttle flights were cut so far back from original design parameters is *because* NASA had their funding cut so much since the moon landings.
This is pork barrel spending at it worst hiding behind science and patriotism.
Yeah! We could *obviously* put the money into pursuits *far* more productive for the human race, like blowing up Iraqis! Are you stupid?
Use the Intel compilers, your code will be 50-300% faster.
50-300%? You're nuts. I've used both, and performance definitely varies...and if I had to choose one or the other as "generally producing faster code", I'd probably point at gcc.
Take a look at these benchmarks.
Gcc produces fastest code on 26 of the tests, icc on 9.
Furthermore, not all the optimization flags for gcc were being used (no idea why -fexpensive-optimizations wasn't used).
American Express and VISA already allow you to generate a single-use number. It's only good for a single transaction at a single point in time.
Yes, but the CC number space isn't large enough to allow this to be a universal solution. (That's ignoring the fact that it's all divided up and whatnot).
I guess you could try to set up some cyclic reuse thing...
But a per-transaction scheme can't, by definition, handle recurring payments.
[shrug] Same system could pretty easily be used to authorize recurring payments.
Frankly, though, I'm not entirely sure that I wouldn't just like my CC company to just send me a bill with *requested* recurring payments, which then get authorized on a per-transaction basis so that I know where my money is going, and I have absolute control over who gets it.
I was responding to your generalized perception that compatibility is as huge an issue as you still perceive it to be, and OS X having it's own advantages over Windows and .net beyond simple eye candy.
.NET, developers are going to move to a new API because it has some technical advantages. This will marginalize Microsoft's compatibility lever?
Okay, I can get about three interpretations here:
First possibility: what you believe is that instead of writing something using Microsoft's Win32, MFC, or
All I can say is that historically this is not true, and that I find it unlikely that it will happen now.
Second possibility: you're arguing that APIs supported on OS X are better, so commercial developers will abandon Windows, and code for OS X instead? I find that equally unlikely.
Third possibility: you mentioned open source development. You feel that open source developers will see the benefits of SmallTalk and start using it instead of C on UNIX. First of all, this would have little benefit to Mac users -- most open source developers already code for a POSIX C API, which works fine with OS X. Second of all, there have been many, many more modern languages and VMs available, and open source apps are still almost always written in C, which most people feel is a pretty bad application development language. I don't see this changing either.
Objective C (written by Brad Cox) was trying to bring smalltalk like objected oriented functionality to C.
Most Linux folks already have a free Objective C (The GNU one) compiler installed on their system, and the language *still* gets ignored by the overwhelming majority of open source programmers. I don't think I've ever needed my Objective C compiler to compile a single program I wanted to use.
Argh! Okay, let's review my original post:
Java is interesting (and certainly useful against Microsoft in some areas), but has long since turned out to not be what it once was billed as -- a write once run anywhere solution for all applications, including desktop computing. There is a very obvious lack of horizontal-market Java applications, stemming from issues with the Java standard itself, including a lack of templated container classes, and poor performance and memory footprint. Remember that Corel spent a *huge* amount of money porting their suite to Java, and at the end (and I'm *sure* that after that kind of resource expenditure, this was not done without much agonizing consideration) the entire thing was scrapped.
Okay, now what I said, paraphrased, is that "Java is not a universal desktop software environment." STOP. That was my point. Java is not enough to get people off of Windows because it's not used enough. Then, by way of explanation, I wrote that (paraphrased) "this was because of poor performance".
It's *entirely* irrelevant to my argument whether SmallTalk gives better peformance. Or a better structure. Or whether it's more mature. SmallTalk has been around for decades, and it is not widely used for the apps that are keeping people stuck on Windows. Yes, if everyone suddenly started using SmallTalk (in a portable way, so no changes involved to build for another platform) for major desktop apps, it could nail MS. It *doesn't*, however.
we didn't need any fancy computer to whip up characters. Just 3d6, a pencil and paper. Most of the iterations since have just been sales-driven product releases.
With all due respect to the PcGen people, I could never understand the point of a "character generator". You download and install an app so that you can shave a couple of seconds off of character generation? What's the *point*? If anything, you lose part of the gaming experience.
I mean, how often do you need to generate a freaking character?
It's a given that at some point, given the potentially *massive* financial benefits inherent in compromising CC databases, that CCs must go away. They're totally inappropriate for today's society.
The only question is how much money CC providers and companies are going to lose before moving to smartcards that authorize payments on a per-transaction basis.
You don't get it.
.net relevant? What is .net is trying to do? Enable people to write software in a different, object oriented way. People will only have a need to use .net enabled software when such software exists, does something meaningful, and works well.
.net as much as win32, and that's what they're going to continue to do in order to maintain Microsoft's legendary (and necessary) backwards compatibility.
.NET. New functionality is not infrequently being exposed *only* though .NET.
.net are heavily drawn from. The issue between Java and .net isn't about who has it installed - it's about who's writing the next killer application and what it runs on.
I certainly don't.
What I pointed out was what mono will most likely do well is the same GNUStep does well, and that is open up the API's so they can be used in open source projects. Open source projects obviously don't mature overnight.
Again, this is *not* what I was talking about. Libraries to write cross-platform apps are all over the place. There is no lack of those, nor do we need more to stop the Microsoft hegemon.
The problem is whether the most commonly *used* APIs are available across platforms. Nothing else really matters from a compatibility standpoint. OpenGL is an excellent API. It's available *everywhere*. I can write an OpenGL app and compile it wherever I want.
However, it doesn't really *play* a huge role in making the masses of games out there available for Linux and Mac OS, because Direct3d is far more commonly used. So you can have the amazing cross-platform FooBarBaz VM and language, and it means zilch as long as everyone is using Microsoft's own APIs.
Ideally what this will do is not replace the commercial implementaion (.net or cocoa) but rather give developers access to these api's freely and openly, so that ideally they can take advantage of them.
Furthermore, having "open access" to an API is not a problem. You can run out and look up the Win32 API to your heart's content. The problem is having libraries *implementing* that API available.
The issue is what is making
No, that is *not* the issue. There are *scads* of ways to write object oriented code. There is no lack of ways to do so in a cross platform manner.
This is not the case right now. Sure, Microsoft is pushing the tools, but you know damned well people aren't writing for
Not last time I was going through win32. Microsoft is pushing *hard* to move developers to
SmallTalk is relevant because it is where most of the good aspects of
Fine. It certainly is not fucking running on SmallTalk. There are SmallTalk implementations for Linux. You know what? I still *don't use a single program written in SmallTalk because almost no one codes for it*.
The problem is that you're trying to make the argument that "SmallTalk is a good environment" or "A lot of modern features originated with SmallTalk" or "People *could* write cross-platform code for SmallTalk". And this has *zero* to do with my post, which has entirely to do with cross-platform compatibility in *commonly used* languages/VMs.
Maybe you do "gotta say" that, but you'd be wrong.
Nope.
As we discussed above, if the key length is less than the message length there will be some difference between pure noise and your signal.
Yup. But that doesn't matter. Not being random is entirely different from not being random in a manner that we can detect. An encryption algorithm that is *detectably* nonrandom is pretty poor.
I assure you, you cannot tell the difference between, say, DES-encrypted data and random data.
That's pretty much definitionally what a good encryption algorithm is.
Sure, given a computer with infinite resources, any crypto algorithm except one-time pads can be broken. The point is that we don't *have* computers with infinite resources. That's why non-one-time-pad crypto is used.
only 3% have stopped buying CDs because prices are too high...
You given Rosen too much credit. *Your statistic might potentially be true*.
According to the submission, 3% buy *fewer* CDs because prices are too high.
That's absolutely ridiculous. Let's take this to the point of absurdity. If I start *giving* away CDs for free, how many people are going to take them? Granted, there might be a few who value CDs negatively (they're afraid of them or something), and a few people who have every CD that they have the remotest interest in). But most people are going to take at least *one* more CD.
If prices go down, sales will go up, and I assure you, more than 3% of the population will get at least one CD more.
Australia is notoriously regulation happy (yesterday sent off $100 fine for NOT voting in the election - that's how regulated we are.)
What, paying a $100 fine for *voting* in the election would make more sense?
The i960 is an embedded processor that doesn't do IA32. You can't boot Windows XP on it.
It depends on what OS you want to run. Alpha is dead, so if you want to run Windows XP, you're going to need IA32 compatibility. Crusoe, Athlon, Duron, Pentium IV, Celeron, Xenon, and C3 are all useable lines of IA32 chips with quite different characteristics.
Apple offers only the G3 and the G4.
Frankly, I don't see why you'd *care* how many architectures there are -- I don't know anyone whose sole demand is wanting to run an oddball architecture, but whatever.
I disagree with you. If you check your history, Apple has the jump in this situation - NextStep/Objective C was doing OOP way before Java was a glimmer in Gosling's eye.
.NET implementation for some time, which made Mono not a solution to .NET-implemented software, which is where Microsoft is pushing very hard to get everyone moving.
I don't know the history that well, but Objective C (written by Brad Cox) was trying to bring smalltalk like objected oriented functionality to C.
This really doesn't relate to what I was talking about. I said that Mono wasn't going to be running neck and neck with Microsoft's
I have not used SmallTalk, but it's irrelevant to the discussion. It's not used en masse on the desktop, which means it cannot be a tool used to move people out of the MS camp. This is the same issue I mentioned with Java (and even *that* is used more than SmallTalk). The point I was arguing was that Java and Mono are not (currently) enough to break an MS hold on the desktop. SmallTalk is even less so. I really don't care about the technical merits of any of them, at least so far as this discussion goes.
Excuse me. I neglected to mention BSD.