This is reasonable while working with non-compressed data; the gap in the sound will not be that long. But with compressed data, the size of the gap is also "decompressed", enlarged.
Wrong. Compressed data would actually be less succeptible to skipping. If it's not compressed, you need to read the data from CD with a speed of at least 150k/s (more if you want to buffer it). If it is compressed, the required speed is about 1/8 of that (for 128kbps mp3's at least). So the same speed CD reader will be able to fill the buffers much faster if the data is compressed. Think about it. The data gets expanded after it is read from the CD.
uhhm, the difference is that mummies are "stored" at pretty much room temperature. Here we are talking about a *frozen* mamonth. AFAIK, frozen meet can be stored indefinitely. We'll see anyway. It would sure be interesting to extract DNA from this piece of meat.
If you mean re-implementing the Glide functions so they call GL, this is slow and in violation of 3dfx's copyrights on Glide (Creative provided the same thing under Windows and got their butts sued). This is also not such a trivial thing to do...
This is not in violation of 3dfx copyright. All Creative did was implement glide API, in the same way that WINE implements win32 API. You are right that this is not a trivial thing to do.
I wonder what happened to that lawsuit though. Creative has the resources to defend itself of this ridiculous lawsuit. Does anyone know what happened?
First of all, MS releasing source is very unlikely to happen. Second of all, even if they do release it, it will most likely be under some kind of restrictive license (a la SCSL), which does not qualify as open source. The bad thing is that *they* will call it open source and media (i.e. ZD Net) will not have a clue to figure out the difference.
I agree with your point that, perhaps, deep down Gates's intentions are good. But think about -- in excat same way you can argue that deep down Hitler's intentions were also good. It does not take that much imagination to see this parallel. But the flaw of this way of thinking is precicely the fact that the end *does not* justy the means.
One more thing: there is an old saying "The road to hell is paved with good intentions."
When it comes to drivers, I don't understand why the company wouldn't want to release the souce. It's actually a lot easier for them since some people might actuall look at the source, find bug and/or add improvements.
Hardware manufacturers are in business to sell hardware. Drivers is something they must write to go with their hardware, but they make *no profit* on them. Thus releasing the source would allow them to leverage the OS model of development, and hence lowering the production costs, while loosing *no* revenue!
At least that's the way I see it. Comment's / corrections are welcome.
RDRAM can NOT run at 800 MHz. It runs at 400 MHz at the most, but it's rated at 800 because it can transfer data at both the rising and falling edge of the cylce. This is exactly what DDR DRAM will do. It's basically the same as SDRAM except for this very feature. And you don't have to pay any royalties.
Although the maximum transfer rate of RDRAM is 1600 Mb/s (compared to 800 MB/s of 100 MHz SDRAM), its latency is much higher (because it can only transfer 16 bits at a time). And for 90% of the applications, latency is the limiting factor, not burst transfer rate. This is exactly why you see almost no difference between Celeron and PII, even though Celeron has 66 MHz bus while PII has 100Mhz.
Exactly! Free Software has no testing cycle and the code quality is very poor. That is why commerical software such as Windows is so much more stable then Linux... errr... wait...
I can think of five or six showtopper bugs off the top of my head in Red Hat 6.0 that would have prevented the release from cooming close to shipping out the door had it been a serious commercial system, but it was released anyways.
I can think of five or six showtopper bugs off the top of my head in Windows 98 that would have prevented the release from cooming close to shipping out the door had it been a serious commercial system, but it was released anyways.
Distribute or sell printer drivers and filters that use the CUPS API so long as source code is made available under the GPL.
Does that mean *all* printer drivers have to be GPL? What if the company doesn't want to release the source? I don't see how it would encourage companies to release more printer drivers.
Debian comes with magicfilter package which does just that. You can send jpegs and stuff to the printer (besides plain text and postscript). So this is not entirely new concept. But I doubt how useful it is. You cannot make filters for every possible type of file. OK, so I can print pdf without Acrobat reader. Can I do the same with jpeg / gif / png / WordPerfect / as well? I'm sure it will be a cold day in hell before I'll be able to print MS Word documents that way. What I'm trying to say is that not only do you need drivers specific for every printer, but also for every file type...
I don't see what's so bad about the current printing system other then the lack of drivers. What we really need is more drivers for GhostScript.
So a couple of kids are suing Nintendo because they were "forced" to buy these cards??? Uhhm, don't you have to be 18 or something? Do they parents know they are doing this?... oh.. wait... they do! Nice going!
Before this story appeared, I thought the funniest lawsuit was the one in which a woman sued the pharmaceutical company because she ate contraceptive jelly and still got pregnant... I guess we have a new winner.
news.com has a story about how NSI and NameSecure handle domain disputes. NSI once again screwed over a small company, Virtual Works, that registered the domain vw.net. They just transfered the domain to Volksvagen and Virtual Works had to spend big bucks in court to get it back.
On the other hand, NameSecure's policy is exactly opposite to NSI's. They don't transfer the domain until they get the court order.
That is a reason enough to switch to NameSecure. Not to mention that the totally moronic email screw up is outrageous.
I run Mandrake 6.0 and I like it very much. I used to think of Mandrake as nothing more then RedHat with KDE slapped on top of it -- and I started to hate Redhat with a passion after it killed my partition table. That was until the article on/. that said Mandrake had been awarded Product of the Year. I immediately downloaded a copy and installed it (got to love the cable modem:). From what I can tell so far, it's an award well deserved. Although it still felt like RedHat initially (esp. the installation part), it turned out to be RedHat that actually works. And works very well I must say. Pentium optimizations turned out to speed up the system a lot. All the apps seem to have a significantly smaller memory footprint (I'm assuming that's the effect of the optimizations?), and that causes the system to swap much less and load apps faster. Oh, and the colorized gcc output is kind of neat.
There were, of course, a few things that I didn't like about it. First of all, KDE was not in the standard location. Putting KDE under/usr is counter-productive and confusing since all the KDE apps expect it to be under/opt/kde. Download an rpm of any KDE app -- it'll install itself under/opt/kde.
Secondly, and that's not something specific to KDE, it doesn't have the nice key mappings for vim that SuSE has. SuSE puts a lot of key mappings in the vimrc file so that the arrows, home/end, pgup/pgdn, etc. always work properly. No big deal -- I just copied the vimrc file.
Finally, for some reason, Netscape seems to crash a lot more often. Perhaps it has something to do with glibc2.1?
I can only hope that Mandrake 6.1 is just as good. However, I'm worried that Mandrake is starting to do what RedHat is doing -- ship beta and pre-release packages. I don't like that it ships with a pre-release kernel as well as betas of other apps, as Skeezix has pointed out. To Mandrake team: please please please don't repeat RedHat's mistakes.
I heard that Linux's 64-bit support (on Alpha at least) is not exactly as good as it should be. Technically, Linux has 64-bit address space; both kernel and apps can use it. But there is a problem with PCI cards. Some cards need to be able to read/write to memory, but they can address only 32 bit space. In order for them to work, the kernel must allocate memory for them below 1 gig, as the person who told me that claimed. DEC Unix(*) does that, but Linux does not. This is similar to some old ISA cards, for which memory had to be allocated below 16 Mb.
Can somebody confirm / deny / comment on that?
(*) I refuse to call it "Compaq Tru64". Compaq had nothing to do with it, other then buying Digital. Besides, does anybody else think "Tru64" is a stupid name?
WHat's wrong with using 64 bit pointers? And why would you have to recompile? Isn't it possible for the kernel to recognize both kinds and translate them accordingly?
I do agree that the segment stuff is a big and horrible hack rather then a real solution.
FPU on Athlons absolutely screams!!! It's close to 40% faster then same-clock Intel chips. Integer performance is not as impressive though. Only 8% (?) faster then Intel.
I keep hearing that XF4.0 "will" have DRI which will make things "much faster". Question is *when* will XF4.0 be released and *how much* faster will things run? I don't think it is a good idea to have games run on top of X in any shape or form. X is still a huge overhead. When you run a game you don't want to waste any resources, esp. for something huge that just sits in the background. Would it not be much better to implement DRI (or some equivalent) in kernel, so that you don't need to run X?
DISCLAIMER: this is not intended to be a flamebait. Just my experience, observations and opinion.
I tried playing Q2 under Linux. Basically you have two options: run it under X, in which case it runs in a tiny window; or run it under svgalib, which is quite outdated. Neither way is good. Q2 is noticeably slower under Linux then under Windows.
I also heard about the DGA mode in X. In fact I downloaded a demo of (forget what) from loki.com specifically to try DGA. Well, I must admit it actually works. But you have to run the game as root. Q2, on the other hand, doesn't support it.
When a game is ported to Linux, what *exactly* is it ported to? X? If so, that is a rather bad idea. X is a bottleneck for games.
I think graphics support should be a part of the kernel. Games should not require X to run. Only then can you get acceptable performance. I know lots of people object that, but 1. You always have an option not to compile it. 2. It is IMHO better then running games as root.
Passwords are the basic means of checking authorization, whether the protocol is obscure or not. I don't see why "password would violate the ban on security through obscurity". I don't see either how shadow login can be considered an obscure protocol. The author admits himself that the protocol is open. Just because the passwords are hidden does not make the protocol obscure. Using the same logic one may argue that any kind of security system is obscure because it restricts access to data.
2 - time-limited secrets
That is correct. However, this approach is rather risky. You never know how long it will take for attackers to crack it. In fact, it would not be secure to use it more then once...
3 - obscurity as tripwire
OK. I get the point. But how can you connect to a web server if you don't know its port? Besides, "Such measures do not make a given machine resistant to breach in the long term..." The author concedes that this tactics can be used to *detect* the attack but not to stop it.
4 - Assymetric encryption
That is his strongest point. Assymetric encryption is indeed a form of security through obscurity. Just imagine what would happen if you find an algorithm to quickly factor large numbers into primes... So yes, he does make his point that any security system cannot be completely free of obscurity.
Slashdot Mirror
Wrong. Compressed data would actually be less succeptible to skipping. If it's not compressed, you need to read the data from CD with a speed of at least 150k/s (more if you want to buffer it). If it is compressed, the required speed is about 1/8 of that (for 128kbps mp3's at least). So the same speed CD reader will be able to fill the buffers much faster if the data is compressed. Think about it. The data gets expanded after it is read from the CD.
uhhm, the difference is that mummies are "stored" at pretty much room temperature. Here we are talking about a *frozen* mamonth. AFAIK, frozen meet can be stored indefinitely. We'll see anyway. It would sure be interesting to extract DNA from this piece of meat.
This is not in violation of 3dfx copyright. All Creative did was implement glide API, in the same way that WINE implements win32 API. You are right that this is not a trivial thing to do.
I wonder what happened to that lawsuit though. Creative has the resources to defend itself of this ridiculous lawsuit. Does anyone know what happened?
I once used RedHat's disk druid and got the same result. Another time it created overlapping partitions... So Caldera is not the only one.
First of all, MS releasing source is very unlikely to happen. Second of all, even if they do release it, it will most likely be under some kind of restrictive license (a la SCSL), which does not qualify as open source. The bad thing is that *they* will call it open source and media (i.e. ZD Net) will not have a clue to figure out the difference.
Or, conversly, children should be allowed to do everything adults are.
I agree with your point that, perhaps, deep down Gates's intentions are good. But think about -- in excat same way you can argue that deep down Hitler's intentions were also good. It does not take that much imagination to see this parallel. But the flaw of this way of thinking is precicely the fact that the end *does not* justy the means.
One more thing: there is an old saying "The road to hell is paved with good intentions."
Wasn't it supposed to be released in August? Will it be released any time soon?
When it comes to drivers, I don't understand why the company wouldn't want to release the souce. It's actually a lot easier for them since some people might actuall look at the source, find bug and/or add improvements.
Hardware manufacturers are in business to sell hardware. Drivers is something they must write to go with their hardware, but they make *no profit* on them. Thus releasing the source would allow them to leverage the OS model of development, and hence lowering the production costs, while loosing *no* revenue!
At least that's the way I see it. Comment's / corrections are welcome.
RDRAM can NOT run at 800 MHz. It runs at 400 MHz at the most, but it's rated at 800 because it can transfer data at both the rising and falling edge of the cylce. This is exactly what DDR DRAM will do. It's basically the same as SDRAM except for this very feature. And you don't have to pay any royalties.
Although the maximum transfer rate of RDRAM is 1600 Mb/s (compared to 800 MB/s of 100 MHz SDRAM), its latency is much higher (because it can only transfer 16 bits at a time). And for 90% of the applications, latency is the limiting factor, not burst transfer rate. This is exactly why you see almost no difference between Celeron and PII, even though Celeron has 66 MHz bus while PII has 100Mhz.
I can think of five or six showtopper bugs off the top of my head in Red Hat 6.0 that would have prevented the release from cooming close to shipping out the door had it been a serious commercial system, but it was released anyways.
I can think of five or six showtopper bugs off the top of my head in Windows 98 that would have prevented the release from cooming close to shipping out the door had it been a serious commercial system, but it was released anyways.
Does that mean *all* printer drivers have to be GPL? What if the company doesn't want to release the source? I don't see how it would encourage companies to release more printer drivers.
Debian comes with magicfilter package which does just that. You can send jpegs and stuff to the printer (besides plain text and postscript). So this is not entirely new concept. But I doubt how useful it is. You cannot make filters for every possible type of file. OK, so I can print pdf without Acrobat reader. Can I do the same with jpeg / gif / png / WordPerfect / as well? I'm sure it will be a cold day in hell before I'll be able to print MS Word documents that way. What I'm trying to say is that not only do you need drivers specific for every printer, but also for every file type...
I don't see what's so bad about the current printing system other then the lack of drivers. What we really need is more drivers for GhostScript.
So a couple of kids are suing Nintendo because they were "forced" to buy these cards??? Uhhm, don't you have to be 18 or something? Do they parents know they are doing this?... oh.. wait... they do! Nice going!
Before this story appeared, I thought the funniest lawsuit was the one in which a woman sued the pharmaceutical company because she ate contraceptive jelly and still got pregnant... I guess we have a new winner.
On the other hand, NameSecure's policy is exactly opposite to NSI's. They don't transfer the domain until they get the court order.
That is a reason enough to switch to NameSecure. Not to mention that the totally moronic email screw up is outrageous.
I run Mandrake 6.0 and I like it very much. I used to think of Mandrake as nothing more then RedHat with KDE slapped on top of it -- and I started to hate Redhat with a passion after it killed my partition table. That was until the article on /. that said Mandrake had been awarded Product of the Year. I immediately downloaded a copy and installed it (got to love the cable modem :).
/usr is counter-productive and confusing since all the KDE apps expect it to be under /opt/kde. Download an rpm of any KDE app -- it'll install itself under /opt/kde.
From what I can tell so far, it's an award well deserved. Although it still felt like RedHat initially (esp. the installation part), it turned out to be RedHat that actually works. And works very well I must say. Pentium optimizations turned out to speed up the system a lot. All the apps seem to have a significantly smaller memory footprint (I'm assuming that's the effect of the optimizations?), and that causes the system to swap much less and load apps faster. Oh, and the colorized gcc output is kind of neat.
There were, of course, a few things that I didn't like about it. First of all, KDE was not in the standard location. Putting KDE under
Secondly, and that's not something specific to KDE, it doesn't have the nice key mappings for vim that SuSE has. SuSE puts a lot of key mappings in the vimrc file so that the arrows, home/end, pgup/pgdn, etc. always work properly. No big deal -- I just copied the vimrc file.
Finally, for some reason, Netscape seems to crash a lot more often. Perhaps it has something to do with glibc2.1?
I can only hope that Mandrake 6.1 is just as good. However, I'm worried that Mandrake is starting to do what RedHat is doing -- ship beta and pre-release packages. I don't like that it ships with a pre-release kernel as well as betas of other apps, as Skeezix has pointed out. To Mandrake team: please please please don't repeat RedHat's mistakes.
Oh, and once again, great job guys!
I heard that Linux's 64-bit support (on Alpha at least) is not exactly as good as it should be. Technically, Linux has 64-bit address space; both kernel and apps can use it. But there is a problem with PCI cards. Some cards need to be able to read/write to memory, but they can address only 32 bit space. In order for them to work, the kernel must allocate memory for them below 1 gig, as the person who told me that claimed. DEC Unix(*) does that, but Linux does not. This is similar to some old ISA cards, for which memory had to be allocated below 16 Mb.
Can somebody confirm / deny / comment on that?
(*) I refuse to call it "Compaq Tru64". Compaq had nothing to do with it, other then buying Digital. Besides, does anybody else think "Tru64" is a stupid name?
Did anyone get lynx to work in Mandrake? It dies saying it can't create temporary file or something. What's up with that?
I also heard there is some kind of problem with gdb in Mandrake. Is that true?
WHat's wrong with using 64 bit pointers? And why would you have to recompile? Isn't it possible for the kernel to recognize both kinds and translate them accordingly?
I do agree that the segment stuff is a big and horrible hack rather then a real solution.
FPU on Athlons absolutely screams!!! It's close to 40% faster then same-clock Intel chips. Integer performance is not as impressive though. Only 8% (?) faster then Intel.
which episode did it come from?
I keep hearing that XF4.0 "will" have DRI which will make things "much faster". Question is *when* will XF4.0 be released and *how much* faster will things run? I don't think it is a good idea to have games run on top of X in any shape or form. X is still a huge overhead. When you run a game you don't want to waste any resources, esp. for something huge that just sits in the background. Would it not be much better to implement DRI (or some equivalent) in kernel, so that you don't need to run X?
As I said, I downloaded this demo from loki.com and the text file that came with the game said it will use DGA but only if you run it as root.
DISCLAIMER: this is not intended to be a flamebait. Just my experience, observations and opinion.
I tried playing Q2 under Linux. Basically you have two options: run it under X, in which case it runs in a tiny window; or run it under svgalib, which is quite outdated. Neither way is good. Q2 is noticeably slower under Linux then under Windows.
I also heard about the DGA mode in X. In fact I downloaded a demo of (forget what) from loki.com specifically to try DGA. Well, I must admit it actually works. But you have to run the game as root. Q2, on the other hand, doesn't support it.
When a game is ported to Linux, what *exactly* is it ported to? X? If so, that is a rather bad idea. X is a bottleneck for games.
I think graphics support should be a part of the kernel. Games should not require X to run. Only then can you get acceptable performance. I know lots of people object that, but
1. You always have an option not to compile it.
2. It is IMHO better then running games as root.
Is kernel framebuffers / ggi supposed to do that?
1 - Instantiated data
Passwords are the basic means of checking authorization, whether the protocol is obscure or not. I don't see why "password would violate the ban on security through obscurity".
I don't see either how shadow login can be considered an obscure protocol. The author admits himself that the protocol is open. Just because the passwords are hidden does not make the protocol obscure. Using the same logic one may argue that any kind of security system is obscure because it restricts access to data.
2 - time-limited secrets
That is correct. However, this approach is rather risky. You never know how long it will take for attackers to crack it. In fact, it would not be secure to use it more then once...
3 - obscurity as tripwire
OK. I get the point. But how can you connect to a web server if you don't know its port?
Besides, "Such measures do not make a given machine resistant to breach in the long term..."
The author concedes that this tactics can be used to *detect* the attack but not to stop it.
4 - Assymetric encryption
That is his strongest point. Assymetric encryption is indeed a form of security through obscurity. Just imagine what would happen if you find an algorithm to quickly factor large numbers into primes... So yes, he does make his point that any security system cannot be completely free of obscurity.