If the disk fails I don't care about the $70, but I would hope that the manufacturer does, and to avoid losing that $70 they'd take care to make the disk more reliable. This is the purpose of warranties. It would be better still if the penalty on failure were something unpleasant for the manufacturer - e.g. if the disk fails within the first five years then a randomly selected employee of Seagate has to eat rotting fish. Does it do me any good? Nope. Would it give me more confidence in Seagate products? Of course.
Well, I for one, am waiting on the new graphical OS for my Sinclair Z80.
If you mean the ZX81 (not the ZX80, and not the Z88) then there was a new graphical OS released a couple of years ago. SP81 is a backport of the Spectrum operating system to the ZX81 hardware. It's compatible with many Spectrum games.
I expect the Sinclair QL has an alternative operating system written by Linus, if he can find the old disks in his attic.
The FSF has employed paid developers for years. It doesn't seem to have distracted them from their goals of free software or led to them being corrupted by Microsoft.
The article seems to suggest that South Korea has mandated one standard, and China a different and incompatible standard, which does show why having governments arbitrarily decide these things may not always be a good idea. If you live in China and you don't agree with the government's decision, you have no choice to get some different power connector, even if you're willing to pay for such a phone and someone else is willing to sell it to you.
You can't fix a bug you don't know about, and saying Apple should somehow magically know about them all itself is disingenuous.
I don't think so at all. It's an indication of the sad state things are in when security holes are accepted as inevitable. If we still have buffer overflows in the year 2006, it's because nobody has really bothered to do what's necessary to eliminate them once and for all. (Switching to a safe language like Cyclone would fix all these, for example.) Ditto format string vulnerabilities, or integer overflows, or most of the other classes of bug that make up 90% of security holes.
I agree that it's best to give the vendor time to respond before making public that there is a security hole - assuming the vendor actually does fix it promptly. All I'm saying is that a bug is a bug, and it's not somehow less serious because of a positive attitude by Apple, or because they have improved greatly in the past couple of years, or whatever. At the end of the day, if the system is insecure then it's insecure, and if the bug found its way into released software this is a failure. With the speed at which worms can spread, you cannot rely on patching fast enough, and so what happens _after_ the bug is found is fairly unimportant. What matters is that the bug exists at all.
In a sense it matters nothing at all whether Apple has previously had a chance to respond. I don't think any exploit tool has a special mode where it only takes advantage of vulnerabilities if the vendor has had a reasonable time to fix them. Nobody should care about how good the vendor's excuses are about why the security holes haven't been fixed; only that they haven't.
If Microsoft had convinced the music companies to drop the DRM
I don't see what it has to do with the music companies. Microsoft or anyone else can still make a music player without record industry permission - things haven't gotten *that* bad, even in the USA. To listen to music you rip it from your own CDs, or download from the net (with or without payment), just like everyone does already.
Core Duo doesn't do x86_64? Holy crap! Thanks for the correction, I just automatically assumed Intel would include it... especially since these processors are used by Apple, and it would be mad for Apple to step back from 64-bit PowerPC to 32-bit i386 just as several gigabytes of memory becomes common... um... wouldn't it?
Linux has supported x86-64 for years now. The recent versions of Fedora and other distributions have perfectly usable 64-bit versions. The few remaining bits and pieces like OpenOffice have been fixed. (If you run proprietary software such as the Flash player it may be a different story.)
In any case what sort of question is this? Should you buy a recent processor like the Athlon 64s AMD have been selling for ages, or the Intel chips on the market for almost as long? Well, yes of course. What half-decent i386-compatible processor sold these days doesn't support the 64-bit mode?
This is absolutely right. There are patent infringements in Linux. The state of software patents is such that any nontrivial program infringes on them. Some of the infringed patents are held by Microsoft. This is not news at all.
As for the fantasizing about the 'secret agreement', please come back when you have any shred of evidence.
The moment they signed this secret deal to insert MS patented IP into their Linux software
Whoa there. What deal to do what? Oh right, I see, it's a 'secret deal' so obviously it must be a conspiracy to insert 'MS patented IP'... there's no way to prove that allegation either way, so it must be true!
'The proceedings' of important lawsuits are fine. I'm quite happy to read about what happened in court or Groklaw's analysis of the latest ruling. That does not include witless speculation and vapour from pundits on Infoworld or anywhere else.
Can we stop treating this as some kind of corporate soap opera? I'll be happy when Slashdot can once again focus on the technical features of SuSE Linux or other Novell software, together with how well it respects the freedoms of its users. Those are things we can have some knowledge of and discuss sensibly, rather than speculating and fanboying.
An x86 instruction which fits in 16-32 bits might take 4 or 5 instructions on a RISC processor,
Do you have evidence to back that up? From the limited amount that I've seen, the opposite seems to be true - one or two instructions on an ARM or MIPS processor can neatly do what takes several instructions of fumbling on an i386. Partly this is because of more registers accessible at the instruction level, and partly because of a more orthogonal instruction set.
You could compare the size of object code spat out by gcc for different architectures, though of course gcc may not be the most efficient writer of assembly language.
You left out dosemu (the earliest hardware virtualization, using the V86 mode of all 386-compatible processors - but also supporting 32-bit DPMI applications) and DOSBox (which is based on bochs). Also Cooperative Linux for running a Linux system under other OSes, such as Windows.
I think Moglen's point was that he hoped to get 'social justice' without 'coercive redistribution', that is, without the theft-and-redistribution part that you dislike.
Yet another huge point here is that when C++ was designed and written it really had one goal in mind, which was to bring the wonders of object orientedness to the unwashed masses of computer programming.
Er, where did you get that from? I don't think Stroustrup ever said anything like that. See this interview for example:
Stroustrup: My main aim with C++ was to be able to express ideas directly in code and have that code execute with close-to-optimal performance. In other words, to write programs that were both elegant and efficient.
Really, the object-oriented part of C++ is not the most important. More useful is the support for generic programming and efficient, type-safe libraries. I do recommend you read The C++ Programming Language, which is to C++ what K&R is to C. The object-oriented stuff with classes and inheritance isn't introduced until quite late in the book. It's a mistake to characterize C++ as 'C with classes', although it might have started out as that in the very beginning.
Good point. You'd only be in the red if you got a mortgage of nearly 100% and the value of the house had fallen since you bought it. A better example would be someone who rents and is paying off credit card debts.
This measurement of 'wealth' doesn't mean a great deal. If you live in a shanty town and have no regular work, but you do own the shirt on your own back (which might be worth say fifty cents) and don't have any debts to pay off, then you are counted as more wealthy than someone who lives in a million dollar house but is still making repayments on the mortgage.
If the disk fails I don't care about the $70, but I would hope that the manufacturer does, and to avoid losing that $70 they'd take care to make the disk more reliable. This is the purpose of warranties. It would be better still if the penalty on failure were something unpleasant for the manufacturer - e.g. if the disk fails within the first five years then a randomly selected employee of Seagate has to eat rotting fish. Does it do me any good? Nope. Would it give me more confidence in Seagate products? Of course.
I expect the Sinclair QL has an alternative operating system written by Linus, if he can find the old disks in his attic.
10 PRINT "I DEMAND ROBO-HEALTHCARE"
20 GOTO 10
What exactly is the criterion for deciding when a robot has 'demanded' rights?
The FSF has employed paid developers for years. It doesn't seem to have distracted them from their goals of free software or led to them being corrupted by Microsoft.
The article seems to suggest that South Korea has mandated one standard, and China a different and incompatible standard, which does show why having governments arbitrarily decide these things may not always be a good idea. If you live in China and you don't agree with the government's decision, you have no choice to get some different power connector, even if you're willing to pay for such a phone and someone else is willing to sell it to you.
I agree that it's best to give the vendor time to respond before making public that there is a security hole - assuming the vendor actually does fix it promptly. All I'm saying is that a bug is a bug, and it's not somehow less serious because of a positive attitude by Apple, or because they have improved greatly in the past couple of years, or whatever. At the end of the day, if the system is insecure then it's insecure, and if the bug found its way into released software this is a failure. With the speed at which worms can spread, you cannot rely on patching fast enough, and so what happens _after_ the bug is found is fairly unimportant. What matters is that the bug exists at all.
In a sense it matters nothing at all whether Apple has previously had a chance to respond. I don't think any exploit tool has a special mode where it only takes advantage of vulnerabilities if the vendor has had a reasonable time to fix them. Nobody should care about how good the vendor's excuses are about why the security holes haven't been fixed; only that they haven't.
Core Duo doesn't do x86_64? Holy crap! Thanks for the correction, I just automatically assumed Intel would include it... especially since these processors are used by Apple, and it would be mad for Apple to step back from 64-bit PowerPC to 32-bit i386 just as several gigabytes of memory becomes common... um... wouldn't it?
What about the Core 2 Duo?
Linux has supported x86-64 for years now. The recent versions of Fedora and other distributions have perfectly usable 64-bit versions. The few remaining bits and pieces like OpenOffice have been fixed. (If you run proprietary software such as the Flash player it may be a different story.)
In any case what sort of question is this? Should you buy a recent processor like the Athlon 64s AMD have been selling for ages, or the Intel chips on the market for almost as long? Well, yes of course. What half-decent i386-compatible processor sold these days doesn't support the 64-bit mode?
As for the fantasizing about the 'secret agreement', please come back when you have any shred of evidence.
'The proceedings' of important lawsuits are fine. I'm quite happy to read about what happened in court or Groklaw's analysis of the latest ruling. That does not include witless speculation and vapour from pundits on Infoworld or anywhere else.
Can we stop treating this as some kind of corporate soap opera? I'll be happy when Slashdot can once again focus on the technical features of SuSE Linux or other Novell software, together with how well it respects the freedoms of its users. Those are things we can have some knowledge of and discuss sensibly, rather than speculating and fanboying.
You could compare the size of object code spat out by gcc for different architectures, though of course gcc may not be the most efficient writer of assembly language.
Come back Jon Katz! We miss you!
So... you can write your application in Java, but then compile it to Javascript to run inside a web browser?
You left out dosemu (the earliest hardware virtualization, using the V86 mode of all 386-compatible processors - but also supporting 32-bit DPMI applications) and DOSBox (which is based on bochs). Also Cooperative Linux for running a Linux system under other OSes, such as Windows.
\sloppy
I think Moglen's point was that he hoped to get 'social justice' without 'coercive redistribution', that is, without the theft-and-redistribution part that you dislike.
Really, the object-oriented part of C++ is not the most important. More useful is the support for generic programming and efficient, type-safe libraries. I do recommend you read The C++ Programming Language, which is to C++ what K&R is to C. The object-oriented stuff with classes and inheritance isn't introduced until quite late in the book. It's a mistake to characterize C++ as 'C with classes', although it might have started out as that in the very beginning.
Good point. You'd only be in the red if you got a mortgage of nearly 100% and the value of the house had fallen since you bought it. A better example would be someone who rents and is paying off credit card debts.
This measurement of 'wealth' doesn't mean a great deal. If you live in a shanty town and have no regular work, but you do own the shirt on your own back (which might be worth say fifty cents) and don't have any debts to pay off, then you are counted as more wealthy than someone who lives in a million dollar house but is still making repayments on the mortgage.