Their failure to disclose which lines of Linux violate their copyright prevents the Linux community from removing and rewriting the offending code. If they are being hurt by Linux's "copyright violation", they would be helped if Linux stopped violating their copyright. Since they haven't acted in any way that would prevent further violation of their copyright, it's reasonable to conclude that they are actually helped, not hurt by the copyright violation. Specifically, it supports their lawsuit.
According to the original poster, disk space is cheap. I tend to agree. I will gladly forgo a 33% reduction in storage space to achieve far greater compatibility. Yes, I could losslessly convert to wav. But I'm lazy. Give me a FLAC acm codec, and I might rethink that.
That's "du jour", (of the day). And whoah, fanboy. If I was gonna go lossless, I'd go with with a RIFF wav-- those are compatible with every imaginable program.
It's not a choice of photons vs electrons. Ethernet can use optical fibre too.
And I'm glad it's not up to you which technology we use, because the actual tech is only one part of the overall usefulness of a technology. For example, a $100 network card that can do 1gbit/s is more useful to me than a $1000 network card that can do 100 gbit/s. Because I can afford (and justify) the $100 card.
Price matters. Open standards matter. Would we have Ethereal and tcpdump and all the billions of useful network tools that are out there if we were using proprietary standards for networking? I don't think so. Would people get owned due to network stack (or network protocol design) bugs? Seems quite possible.
Try looking a little farther out.
Re:Now if only it had a decent name
on
Ogg Now An RFC
·
· Score: 1
Ogg isn't the sound format-- it's the file format. It's an avi/asf alternative (maybe a tar alternative too), not a mpeg-layer-3 or pcm or flac alternative. The reason I'm being lame about this is that it's the Ogg file format that was standardized, not the Vorbis audio encoding format.</lame>
Here's what makes it ideal: BitTorrent is a protocol. It's not a file format. There are files associated with the protocol, but fundamentally, BitTorrent is a way of delivering files, not a type of file.
Treating BitTorrent as a media type reduces the number of things you can do with it. For example, you can't use it for displaying streaming video, since application/x-bittorrent isn't a video format.
But when you treat BitTorrent as a protocol, you can use it for inline video, or images, or (shudder) Flash.
You could even use it to browse mirrors of slashdotted sites.
I suspect you're actually wrong when you say "you access the tracker via HTTP"-- I don't see why you couldn't download the.torrent via FTP or gopher or kazaa. But however the protocol is implemented, treating it as a protocol means more possibilities and fewer problems.
What comes after the torrent: is completely protocol-defined, so neither you nor I can dictate what it "has to" be. It could be something like torrent://f.scarywater.net/aldenata.iso.torrent.
That's the wrong level. BitTorrent is not a media type, it's a protocol. The media type can be anything: text/plain, audio/mpeg, application/pdf, whatever. Don't let the torrent files fool you. Ideally, they'd be linked with torrent://.
I don't know if protocols are pluggable in Mozilla, but I doubt it. And torrent would have to be a 'protocol plugin' if it was any kind of plugin. Otherwise, torrent would have to be built into Mozilla to be used everywhere that http is.
GIF and PNG use lossless compression techniques. They are lossless. If you have a black-and-white image and you save it into GIF or PNG, you will get an identical image back when you load it.
You're confusing format with interface (because you refer to options used, and those are an interface thing). GIF is lossless, but it can only represent images with 256 colours or less. (Black-and-white images meet that test.) It's impossible to save an image with more than 256 colours as a GIF, so many programs will convert it for you. That doesn't mean GIF is lossy. Just means that it has limitations. Save any 256-colour image, load it up, and you'll get exactly what you had before.
The IA-64 instruction set is not similar to IA-32. It's very, very, very, very, very different. Instead of being CISC (like x86) or RISC (like PowerPC) or VLIW, it's EPIC. The IA-32 compatibility is provided by special compatibility circuitry. If you're looking for a 64-bit instruction set that's similar to x86, you want AMD-64.
Hmmm... One of the suggestions in the article was that companies only be liable for bugs they fail to disclose. If the entire source code is disclosed, does that mean all the bugs are disclosed?
What you say is all true. But it seems as though clustering is becoming more like multiprocessing, and RDMA can be seen as an extension of NUMA. Certainly, the implementation will be easiest on NUMA-aware operating systems.
Why would it matter whether users submit their email on the standard SMTP port?
I can see why you'd want to block port 25 outgoing on your firewall so no one can bypass your SMTP server, but configuring your SMTP server to accept mail on port 8025 or something... what's the point?
It's not usually about "correct". It's generally about being maintainable and extensible.
And the more experience you have with a problem domain, the better-prepared you are to create an architecture that solves the right set of problems.
Yes, each army prepares to fight the last war, and there is the "second system" effect. Myself, I try to avoid rewrites-- usually you can evolve existing code towards the right architecture, but first you need an idea of what the right architecture is. Looks like Tridge is starting with some exploration.
Slashdot Mirror
Their failure to disclose which lines of Linux violate their copyright prevents the Linux community from removing and rewriting the offending code. If they are being hurt by Linux's "copyright violation", they would be helped if Linux stopped violating their copyright. Since they haven't acted in any way that would prevent further violation of their copyright, it's reasonable to conclude that they are actually helped, not hurt by the copyright violation. Specifically, it supports their lawsuit.
Isn't there another possibility: Linux code that was copied into SCO software improperly?
According to the original poster, disk space is cheap. I tend to agree. I will gladly forgo a 33% reduction in storage space to achieve far greater compatibility. Yes, I could losslessly convert to wav. But I'm lazy. Give me a FLAC acm codec, and I might rethink that.
That's "du jour", (of the day). And whoah, fanboy. If I was gonna go lossless, I'd go with with a RIFF wav-- those are compatible with every imaginable program.
It's not a choice of photons vs electrons. Ethernet can use optical fibre too.
And I'm glad it's not up to you which technology we use, because the actual tech is only one part of the overall usefulness of a technology. For example, a $100 network card that can do 1gbit/s is more useful to me than a $1000 network card that can do 100 gbit/s. Because I can afford (and justify) the $100 card.
Price matters. Open standards matter. Would we have Ethereal and tcpdump and all the billions of useful network tools that are out there if we were using proprietary standards for networking? I don't think so. Would people get owned due to network stack (or network protocol design) bugs? Seems quite possible.
Try looking a little farther out.
Ogg isn't the sound format-- it's the file format. It's an avi/asf alternative (maybe a tar alternative too), not a mpeg-layer-3 or pcm or flac alternative. The reason I'm being lame about this is that it's the Ogg file format that was standardized, not the Vorbis audio encoding format.</lame>
Here's what makes it ideal: BitTorrent is a protocol. It's not a file format. There are files associated with the protocol, but fundamentally, BitTorrent is a way of delivering files, not a type of file.
.torrent via FTP or gopher or kazaa. But however the protocol is implemented, treating it as a protocol means more possibilities and fewer problems.
Treating BitTorrent as a media type reduces the number of things you can do with it. For example, you can't use it for displaying streaming video, since application/x-bittorrent isn't a video format.
But when you treat BitTorrent as a protocol, you can use it for inline video, or images, or (shudder) Flash.
You could even use it to browse mirrors of slashdotted sites.
I suspect you're actually wrong when you say "you access the tracker via HTTP"-- I don't see why you couldn't download the
Well, see, this review was written for the STC Single Source SIG newsletter. So, obviously, there was no need to define the term.
In a similar vein, Scott Abel has demonstrated how to use the same review for multiple audiences.
Why not just submit a link, Scott? Sheesh.
Yes, that's very c00l.
What comes after the torrent: is completely protocol-defined, so neither you nor I can dictate what it "has to" be. It could be something like torrent://f.scarywater.net/aldenata.iso.torrent.
If you're from Finland, you do pronounce it "Linnus".
That's the wrong level. BitTorrent is not a media type, it's a protocol. The media type can be anything: text/plain, audio/mpeg, application/pdf, whatever. Don't let the torrent files fool you. Ideally, they'd be linked with torrent://.
I don't know if protocols are pluggable in Mozilla, but I doubt it. And torrent would have to be a 'protocol plugin' if it was any kind of plugin. Otherwise, torrent would have to be built into Mozilla to be used everywhere that http is.
Actually, EPIC is closest to VLIW. It's not orthagonal to the issue.
GIF and PNG use lossless compression techniques. They are lossless. If you have a black-and-white image and you save it into GIF or PNG, you will get an identical image back when you load it.
You're confusing format with interface (because you refer to options used, and those are an interface thing). GIF is lossless, but it can only represent images with 256 colours or less. (Black-and-white images meet that test.) It's impossible to save an image with more than 256 colours as a GIF, so many programs will convert it for you. That doesn't mean GIF is lossy. Just means that it has limitations. Save any 256-colour image, load it up, and you'll get exactly what you had before.
The IA-64 instruction set is not similar to IA-32. It's very, very, very, very, very different. Instead of being CISC (like x86) or RISC (like PowerPC) or VLIW, it's EPIC. The IA-32 compatibility is provided by special compatibility circuitry. If you're looking for a 64-bit instruction set that's similar to x86, you want AMD-64.
The x86 emulation circuitry on Itanium is really slow. So slow that they think software emulation would be faster. . .
Here's a more detailed C|Net story.
(Yes, it's linked from the posted C|Net story).
Hmmm... One of the suggestions in the article was that companies only be liable for bugs they fail to disclose. If the entire source code is disclosed, does that mean all the bugs are disclosed?
What you say is all true. But it seems as though clustering is becoming more like multiprocessing, and RDMA can be seen as an extension of NUMA. Certainly, the implementation will be easiest on NUMA-aware operating systems.
Why would it matter whether users submit their email on the standard SMTP port?
I can see why you'd want to block port 25 outgoing on your firewall so no one can bypass your SMTP server, but configuring your SMTP server to accept mail on port 8025 or something... what's the point?
Just call the browser "Flamewar".
It IS a very fine line-- you can copyright the font binary or the font source, but the appearance of the font cannot be copyrighted.
It's not usually about "correct". It's generally about being maintainable and extensible.
And the more experience you have with a problem domain, the better-prepared you are to create an architecture that solves the right set of problems.
Yes, each army prepares to fight the last war, and there is the "second system" effect. Myself, I try to avoid rewrites-- usually you can evolve existing code towards the right architecture, but first you need an idea of what the right architecture is. Looks like Tridge is starting with some exploration.
Hmmm... I wonder whether a PDF renderer could be implemented as a set of shader programs?