Marketing figured 8.1 wouldn't sell as many copies a 9.0
Why? I'm still running RH7.3. The reason I didn't upgrade to 8.0 is mainly that the.0 releases are by many considered to be problematic. I tried 7.0 when it was released and I hated it. I had decided to upgrade from 7.3 to 8.1 as soon as 8.1 was released. Now I start wondering if I should rather stay on 7.3 and wait for 9.1 to be released. Or is it about time I try another distribution?
I suppose that 32 bit data registers & ALU are still OK for most applications.
I suppose you are wrong. You need to store addresses somewhere, and you need to do calculations on addresses. Imagine the great with this 64bit address space I can create a 128GB array for my data, but I can only access the first 2^31 entries because the index must fit in a 32bit word certainly not what I'm looking forward to. And in fact I'd like to see GPRs larger than the bus with. If you want to measure time since the epoch (1970) in clockcycles, you'd be surprised how quickly 64 bits can become too small.
If you need more than 32 bit, you are probably doing cryptography anyway, so even 64 bits are too short.
I don't think cryptography is really one of the areas that would benefit much from 64bit (or more) processors. Symmetric ciphers are rarely designed to benefit from large bitwidth. They are rather made of a lot of operations on smaller units of 8-32 bits. Some of those operations are so special that they are not easily done on a general purpose CPU no matter what the bitwidth is. This is sometimes to some extent handled by tabelizing. Cryptographic algorithms would benefit a lot more from cryptographic hardware.
I know that. But AFAIK the patches for 3.5GB userspace per process are incompatible with PAE that gives you up to 64GB of physical address space. So you might have to choose between 3.5GB logical and 3.5GB physical on one side and 3GB logical and 64GB physical on the other.
Clearly, there's no significant need for 64-bit x86-compatible processors, because they've been available for purchase now for several years.
64-bit processors has been available for a few years, but none of them were x86-compatible. AMD is the first company trying to make such a processor. This might be what it takes to get 64-bit processors to a large number of users. I sincerely hope so, because we need 64-bit processors and has actually been needing them for a few years already, we want no more workarounds because of an insufficient architecture. If I cannot mmap my harddisk, my address space is too small.
post a link on slashdot to a FTP site with a 10 user max? I'll be waiting months to download this.
I used wget, it automatically retried. In fact it managed to start the download already at the fifth attempt. Either I was very lucky, or it is not that difficult to get access to. I wonder if that limit really is just 10.
No problem. Windows users would rather pay for software than having something of a better quality for freee. After all why would they otherwise use Windows?
Typically you pay at least four times as much per GB if you buy SCSI instead of IDE.
inexpensive SCSI drives.
Though a massproduced SCSI drive should be possible at prices comparable to an IDE drive of the same size and speed, they are very rare. In fact I never saw one. So I guess a lot of people would be happy if you would tell us where they can be bought.
I wonder how long before we'd get binary compatibility between other x86 unix OSs.
Using an Intel CPU doesn't mean they have to repeat all IBMs mistakes from the past. They have the oportunity to design a BIOS from scratch that doesn't have to be backwardcompatible. It can become a lot better from that. I hope, that if they really go Intel, at least they bitch realmode and go in protected mode as fast as possible. While an OS that runs on both platforms does not come for free, it shouldn't be a problem to reuse userspace code on very different hardwareplatforms, as long as the CPU is the same. Of course it requires a reasonable OS design. I bet it won't be a long time after such a Mac has been released before you can run Linux on it with all the binary executables you already have for x86. Even WMWare might work, which would be kind of interesting. I wonder how long time it will be before MS ships a Windows that runs natively on Mac. I also wonder how Apple feels about that possibility.
I however still wonder why anyone would design a new architecture with an obsolete CPU. A much better decission could be to use AMDs new soon to be released x86-64.
Get rid of X and you have a desktop OS that can actually compete.
Get rid of X and you have a textmode screen with a commandline. I don't think that can compete. I don't see any alternative to X if you want a GUI. I use network transparancy hundreds of times every day, there is no way I'd give it up. Sure X is not perfect, but it is not too bad either. Don't get rid of X before you have a usable alternative.
if you stick to a standard like VESA you should be OK for 75% of all cards
Remember that you need to be able to do it in protected mode. Doing this stuff in real or virtual 86 mode is a bad plan. Do you really think 75% of the VESA cards does actually have a BIOS that can be used from protected mode?
While that would be a good idea, it is not what is described by the article. Of course people are going to whine if they have to pay for this, and in particular if they have to pay for each mail they send. If implementing this would require the price of an internet conneciton to be increased by $1 per month, I'd be happy to pay. However the ISPs must understand, that they are not supposed to make money from each mail. The money are supposed to be payed to the recipient, who can then use them when writing emails himself. The case where you are exchanging emails with your friends should only require payment for the first few emails until you have witelisted each other. Once both parties have witelisted the other party, any payment already made should be returned. If implemented correctly, you are going to pay the first time you mail a person, and you get the money back once he replies. And whenever you get a spam mail you get an amount of money, you just must not reply to the spam. In some cases it would make sense for Alice to pay Bob for each email, while Bob does not pay back. That would make sense if the communication is done because Alice wants Bobs help for some problem. It would be Alice that had started the communication and choose to pay because she believe Bobs answer is worth much more than the payment.
Handy for a monitor, maybe, but you really don't want that with a projector.
You would not be forced to use it. But the feature could of course be improved by a configurable delay from the standby button is pressed until the relay switches off. But does the projector turn on automatically when the relay switches on again?
Are we at the point yet where we declare Google a monopoly and start rooting for a competing search engine just because?
If you want to make a competitive alternative to google, you must violate The Robots Exclusion Protocol. Why? Because you will find a lot of robots.txt files on the net that allows googlebot to index more pages than other robots. You could of course insist that this is unfair and program your own robot in a way that will make it download anything allowed to google, but that would be a violation. The best plan if you really want to get a lot of pages in spite of webservers misbehaving and being unfair would be to make three different crawlers each running on different sets of computers:
A well behaved crawler identifying itself correctly and downloading only what it is allowed to.
A crawler that identifies itself as googlebot and downloads anything allowed to google.
A crawler that identifies itself as IE and downloads anything allowed to one of the major crawlers or by the * matching. This one shouldn't download robots.txt but just use the version downloaded by the other crawlers.
It would be a nice feature if it was equiped with a relay, so the power to the monitor could be turned off when you use the standby button on the remote control. Unfortunately the specs seems to indicate that is not the case.
Tar works fine when the user actually remembers the exact path and filename.
It shouldn't be any major problem to build indexes over your tar files. What Linus argues that dump does incorrectly and tar does correctly is the reading of the filesystem. The way to read a live filesystem is through the filesystem API, not by blockwise reading of the device. All your arguments against tar and in favor of dump is about the output produced by the program. If you want output like dump produces it, then write a tool to read the filesystem in the way tar does and write output in the way dump does.
Slashdot Mirror
Marketing figured 8.1 wouldn't sell as many copies a 9.0
.0 releases are by many considered to be problematic. I tried 7.0 when it was released and I hated it. I had decided to upgrade from 7.3 to 8.1 as soon as 8.1 was released. Now I start wondering if I should rather stay on 7.3 and wait for 9.1 to be released. Or is it about time I try another distribution?
Why? I'm still running RH7.3. The reason I didn't upgrade to 8.0 is mainly that the
I suppose that 32 bit data registers & ALU are still OK for most applications.
I suppose you are wrong. You need to store addresses somewhere, and you need to do calculations on addresses. Imagine the great with this 64bit address space I can create a 128GB array for my data, but I can only access the first 2^31 entries because the index must fit in a 32bit word certainly not what I'm looking forward to. And in fact I'd like to see GPRs larger than the bus with. If you want to measure time since the epoch (1970) in clockcycles, you'd be surprised how quickly 64 bits can become too small.
If you need more than 32 bit, you are probably doing cryptography anyway, so even 64 bits are too short.
I don't think cryptography is really one of the areas that would benefit much from 64bit (or more) processors. Symmetric ciphers are rarely designed to benefit from large bitwidth. They are rather made of a lot of operations on smaller units of 8-32 bits. Some of those operations are so special that they are not easily done on a general purpose CPU no matter what the bitwidth is. This is sometimes to some extent handled by tabelizing. Cryptographic algorithms would benefit a lot more from cryptographic hardware.
I know that. But AFAIK the patches for 3.5GB userspace per process are incompatible with PAE that gives you up to 64GB of physical address space. So you might have to choose between 3.5GB logical and 3.5GB physical on one side and 3GB logical and 64GB physical on the other.
have to follow AMD with x86-64
If x86-64 becomes a success Intel might need to make AMD compatible CPUs. That would be kind of interesting.
2GB, and that's shared across all the apps.
:-)
Linux can do better than that. In Linux you get 3GB per process.
Clearly, there's no significant need for 64-bit x86-compatible processors, because they've been available for purchase now for several years.
64-bit processors has been available for a few years, but none of them were x86-compatible. AMD is the first company trying to make such a processor. This might be what it takes to get 64-bit processors to a large number of users. I sincerely hope so, because we need 64-bit processors and has actually been needing them for a few years already, we want no more workarounds because of an insufficient architecture. If I cannot mmap my harddisk, my address space is too small.
post a link on slashdot to a FTP site with a 10 user max? I'll be waiting months to download this.
I used wget, it automatically retried. In fact it managed to start the download already at the fifth attempt. Either I was very lucky, or it is not that difficult to get access to. I wonder if that limit really is just 10.
The first track is probably the best of the lot.
It really is.
programs that cost $30?
No problem. Windows users would rather pay for software than having something of a better quality for freee. After all why would they otherwise use Windows?
SCSI is only slightly more expensive than IDE.
Typically you pay at least four times as much per GB if you buy SCSI instead of IDE.
inexpensive SCSI drives.
Though a massproduced SCSI drive should be possible at prices comparable to an IDE drive of the same size and speed, they are very rare. In fact I never saw one. So I guess a lot of people would be happy if you would tell us where they can be bought.
I wonder how long before we'd get binary compatibility between other x86 unix OSs.
Using an Intel CPU doesn't mean they have to repeat all IBMs mistakes from the past. They have the oportunity to design a BIOS from scratch that doesn't have to be backwardcompatible. It can become a lot better from that. I hope, that if they really go Intel, at least they bitch realmode and go in protected mode as fast as possible. While an OS that runs on both platforms does not come for free, it shouldn't be a problem to reuse userspace code on very different hardwareplatforms, as long as the CPU is the same. Of course it requires a reasonable OS design. I bet it won't be a long time after such a Mac has been released before you can run Linux on it with all the binary executables you already have for x86. Even WMWare might work, which would be kind of interesting. I wonder how long time it will be before MS ships a Windows that runs natively on Mac. I also wonder how Apple feels about that possibility.
I however still wonder why anyone would design a new architecture with an obsolete CPU. A much better decission could be to use AMDs new soon to be released x86-64.
When can we post using beer? :)
How many Gb/s does that require?
Actually, its 8/10ths of an order of magnitude
Might depend on exactly which layers the meassurement is done at. Imagine that there could be two control bits between each byte.
drivers for the cards is what is hard for X
Indeed
Get rid of X and you have a desktop OS that can actually compete.
Get rid of X and you have a textmode screen with a commandline. I don't think that can compete. I don't see any alternative to X if you want a GUI. I use network transparancy hundreds of times every day, there is no way I'd give it up. Sure X is not perfect, but it is not too bad either. Don't get rid of X before you have a usable alternative.
if you stick to a standard like VESA you should be OK for 75% of all cards
Remember that you need to be able to do it in protected mode. Doing this stuff in real or virtual 86 mode is a bad plan. Do you really think 75% of the VESA cards does actually have a BIOS that can be used from protected mode?
Just moved in, eh?
Yes, just moved in four years ago. Still haven't unpacked all my stuff.
receive the same per email you get
While that would be a good idea, it is not what is described by the article. Of course people are going to whine if they have to pay for this, and in particular if they have to pay for each mail they send. If implementing this would require the price of an internet conneciton to be increased by $1 per month, I'd be happy to pay. However the ISPs must understand, that they are not supposed to make money from each mail. The money are supposed to be payed to the recipient, who can then use them when writing emails himself. The case where you are exchanging emails with your friends should only require payment for the first few emails until you have witelisted each other. Once both parties have witelisted the other party, any payment already made should be returned. If implemented correctly, you are going to pay the first time you mail a person, and you get the money back once he replies. And whenever you get a spam mail you get an amount of money, you just must not reply to the spam. In some cases it would make sense for Alice to pay Bob for each email, while Bob does not pay back. That would make sense if the communication is done because Alice wants Bobs help for some problem. It would be Alice that had started the communication and choose to pay because she believe Bobs answer is worth much more than the payment.
How much crap do you get a day in your postal mailbox?
About one per month. I'd be happy to get only one piece of spam by email each month.
derives it from the useragent.
We all know, that lots of people are lying about their useragent, simply because some servers misbehave if the useragent is not IE.
why wouldnt the monitor go to standby when the unit is turned to standby?
Of course it would. But do you want two units wasting power in stand by mode, when you could do with just one?
Handy for a monitor, maybe, but you really don't want that with a projector.
You would not be forced to use it. But the feature could of course be improved by a configurable delay from the standby button is pressed until the relay switches off. But does the projector turn on automatically when the relay switches on again?
If you want to make a competitive alternative to google, you must violate The Robots Exclusion Protocol. Why? Because you will find a lot of robots.txt files on the net that allows googlebot to index more pages than other robots. You could of course insist that this is unfair and program your own robot in a way that will make it download anything allowed to google, but that would be a violation. The best plan if you really want to get a lot of pages in spite of webservers misbehaving and being unfair would be to make three different crawlers each running on different sets of computers:
It would be a nice feature if it was equiped with a relay, so the power to the monitor could be turned off when you use the standby button on the remote control. Unfortunately the specs seems to indicate that is not the case.
Tar works fine when the user actually remembers the exact path and filename.
It shouldn't be any major problem to build indexes over your tar files. What Linus argues that dump does incorrectly and tar does correctly is the reading of the filesystem. The way to read a live filesystem is through the filesystem API, not by blockwise reading of the device. All your arguments against tar and in favor of dump is about the output produced by the program. If you want output like dump produces it, then write a tool to read the filesystem in the way tar does and write output in the way dump does.