Random extra doesn't cut it, just means you have to take more measurements to get the timing right. This isn't pointless at all, I've seen too many "only theoretical" exploits work to dismiss anything that seems like a possible flaw.
I disagree with that. I do want that to happen. It seems to have got past the point where Linus running the whole thing is beneficial. I think we need a fork, I really do.
In that case, how come the "victim" gets them? Why don't the actual damages go to the victim, and anything meant to punish can go to the IRS, or to victims whose offenders couldn't pay the damages, or something?
So how about a sort of "diamond foam"? Could that be done? Solid, transparent, but very insulating. Actually, the refractive index is probably far too big to be useful. Any heat-inconductive fluids that could be used with a similar refractive index to diamond?
It's IE's fault for having the flaws that allowed it get in there. With the existence of all the junk in it, it should be removed from the OS post-haste.
Why the hell should you need an external program to repair your OS?
I don't think it was, I think it was done because it was seen to be seriously necessary. Using a proprietary API is a big thing, and must be seen to be something we care deeply about.
It won because a few big distros stacked the standards comittee. And LSB distros only need to provide a way to install RPMs, not use it as the primary package managment for the actual system. (RTFFootnote on the link you give)
It's not public domain. A significant amount of it is produced by other studios under license, licensed from other channels/countries, or will be licensed to other places for money. Now one can argue it should be public domain, but it presently isn't.
OK, but it's reducing functionality if you buy music from other sources - namely, the ability to play protected songs.
I can see them winning with that, but I can also see them losing, because at the same time it's clearly superior functionality if the music sites can rent songs for ipods, for example. Even without that, the ability to buy and use a limited licensed song is, I feel, a major functional difference.
They said, plain and simple, if the project doesn't do this they'll try and fork/clone it. That's their right, and it's courtesy to tell the OOo people what problems they have so they can avoid a fork if they want to rather than just forking it straight away. OOo devs had every right to ignore them.
No, the issue was that sun was using sun-only classes which aren't part of the Java 5 spec. They've now agreed not to do that; classpath still won't run it all immediately, but any fully java 1.31 compliant VM will.
KDE has no ties to proprietary software at all. Qt became GPL in about 2001. The rest is just FUD from gnome because they know their desktop can't compete on its merits.
No, but he complains if it depends on it. If OOo depended on some feature only found in the IBM BIOS, he would complain just as much - and quite rightly.
The biggest problem was the use of sun-only APIs. Yes, classpath doesn't have the entire library implemented yet, but even if all the missing bits of the official libraries were implemented, prior to this agreement OOo still wouldn't have full functionality. Now it will. Which is an important difference.
Moving the plugin interface into the JVM rather than OOo codebase is a genuine concession. It was staying in there, and although some had been cleaned up there was still unnecessary use of sun.* in OOo, and the precedent could have lead to more and more of OOo becoming sun-jvm-dependent. Making an agreement to only use standard APIs is an important difference
Random extra doesn't cut it, just means you have to take more measurements to get the timing right. This isn't pointless at all, I've seen too many "only theoretical" exploits work to dismiss anything that seems like a possible flaw.
I disagree with that. I do want that to happen. It seems to have got past the point where Linus running the whole thing is beneficial. I think we need a fork, I really do.
If you could bill 3 digits an hour reading slashdot, wouldn't you?
In that case, how come the "victim" gets them? Why don't the actual damages go to the victim, and anything meant to punish can go to the IRS, or to victims whose offenders couldn't pay the damages, or something?
ITYM rapport. It's one of those silly words to help the French cheat at scrabble (yes that was a bash ref)
So how about a sort of "diamond foam"? Could that be done? Solid, transparent, but very insulating. Actually, the refractive index is probably far too big to be useful. Any heat-inconductive fluids that could be used with a similar refractive index to diamond?
Why the hell should you need an external program to repair your OS?
Like all trolls, if he doesn't get a rise he'll stop eventually
Not at all. Programmer time costs a lot more than CPU time.
I don't think he does see hardware as off-limits. He certainly replaced his bios with a Free one as soon as he could.
I don't think it was, I think it was done because it was seen to be seriously necessary. Using a proprietary API is a big thing, and must be seen to be something we care deeply about.
No, have the web browser responsible for browsing the web and a completely different program for running remote applications.
Exactly. The AC I replied to was claiming you can justify anything under free speech.
It won because a few big distros stacked the standards comittee. And LSB distros only need to provide a way to install RPMs, not use it as the primary package managment for the actual system. (RTFFootnote on the link you give)
It has also taught us that the makers won't bother making a linux client.
It's not public domain. A significant amount of it is produced by other studios under license, licensed from other channels/countries, or will be licensed to other places for money. Now one can argue it should be public domain, but it presently isn't.
I can see them winning with that, but I can also see them losing, because at the same time it's clearly superior functionality if the music sites can rent songs for ipods, for example. Even without that, the ability to buy and use a limited licensed song is, I feel, a major functional difference.
They said, plain and simple, if the project doesn't do this they'll try and fork/clone it. That's their right, and it's courtesy to tell the OOo people what problems they have so they can avoid a fork if they want to rather than just forking it straight away. OOo devs had every right to ignore them.
No, the issue was that sun was using sun-only classes which aren't part of the Java 5 spec. They've now agreed not to do that; classpath still won't run it all immediately, but any fully java 1.31 compliant VM will.
KDE has no ties to proprietary software at all. Qt became GPL in about 2001. The rest is just FUD from gnome because they know their desktop can't compete on its merits.
No, but he complains if it depends on it. If OOo depended on some feature only found in the IBM BIOS, he would complain just as much - and quite rightly.
The concessions on the free software side seem to be not forking OOo.
The biggest problem was the use of sun-only APIs. Yes, classpath doesn't have the entire library implemented yet, but even if all the missing bits of the official libraries were implemented, prior to this agreement OOo still wouldn't have full functionality. Now it will. Which is an important difference.
Moving the plugin interface into the JVM rather than OOo codebase is a genuine concession. It was staying in there, and although some had been cleaned up there was still unnecessary use of sun.* in OOo, and the precedent could have lead to more and more of OOo becoming sun-jvm-dependent. Making an agreement to only use standard APIs is an important difference
No. The standard java api, in java.* is well documented. The proprietary extensions we are worried about, in sun.*, are not.