Heck for the most part 32-bit ALU's
are over kill. For example, when I hit submit on this form it will prolly
strlen() the buffer. Chances are I won't write more than 64KB so why do you
need 32-bits to count that?
The odds are pretty low, but not zero. Thus, the code
needs to handle that case (especially since it's
most likely generic code that is not written specifically for Slashdot), and
to do that, it can either use 32-bit integers, or implement bignums.
The point is the ARM ====>instruction set===== is vastly superior.
It's a bit better then x86, but it's not that wonderful, and it's not the reason that ARMs are so low powered.
I've
heard rumors that Intel toyed with the idea of a Ghz ARM core.
It's quite likely; they've got 733MHz XScales now. However, don't be fooled into thinking that they perform anywhere near what a superscalar, out-of-order 733 MHz x86 CPU would achieve. Things like that are where the bulk of the power consumption comes from.
x86 has all of 4 registers. You can muster up 3 more if you don't like debugging.
8, not 4. One is for the stack, but you counted that for ARM as well. One (not three) more is for debugging, and is not necessary if you have sufficient debugging information outside the code.
ARM favours bundling [e.g. you can rotate/shift inside an instruction]
Yeah, I'm sure that's conducive to high-speed implementations.
The ARM instruction set also sports generic multipliers [e.g. not just to one pair of registers]
So does x86 these days. It's been there since at least the 386 (maybe earlier); try to keep up.
blah blah blah.
Indeed.
I'm no particular fan of the x86 instruction set, but you could at least damn it for the things it is guilty of.
States cannot take away rights. The right to travel is a right guaranteed in the 9th ammendment.
What right is California taking away here? The right to pollute? Is that guaranteed by the 9th Amendment too? Since you chose not to respond to my point that this has nothing to do with regulating travel, surely it can't be that...
Plus, its yet another really STOOPID idea, as I've pointed out already. And it will work to increase pollution, not decrease it.
It may very well be a stupid idea, but that doesn't make it Unconstitutional. After all, stupidity must be protected by the 9th Amendment too, right?:-)
I was not talking about driving someone elses car, I'm talking about driving my own car.
But I thought you had a Right To Travel, laws be damned?
In any case, I see you ignored the other analogy, of blasting your speech at a high volume, using amplification equipment that you own, of course.:-)
This right is protected by the constitution (in that the constituion does not give the government the right to regulate travel, and thus that right is retained according to the constitution.)
Which constitution are you talking about? The U.S. constitution gives the states the right to regulate pollution (which is what this is about; it has nothing to do with travel) by way of the 10th amendment. The California constitution, like most state constitutions, does not follow the limited powers model of the U.S. constitution, but rather says what the government cannot do.
The only reason that Congress is restricted in the way it is is to establish a separation of powers between the states and the federal government. If this were being done by the federal government, you might have a point, but it's not, and so you don't.
No, travel by car is not a priviledge.
By your argument, free speech is a fundamental right, but to put that speech into a news paper that oyu own the press for is a priviledge.
The free speech clause prohibits laws against actions based on the speech component of the action. It does not prohibit restrictions on non-speech components, such as using someone else's printing press without their permission, or blasting one's speech at 100 dB in a residential neighborhood at 3 in the morning. By your argument, both of these would be a fundamental right, since they involve speech.
Similarly, the right to liberty of movement keeps the government from forcing you to stay where you are, but it does not stop it from regulating specfic means of transportation, as long as such regulations are not made on the basis of certain classes of people whom they do not wish to be allowed to travel, or are otherwise intended to abridge the right to liberty.
Driving a vehicle that fills a neighborhood with smog is no different, from a rights perspective, from filling it with high-amplitude sound waves. The fact that some other right was being exercised at the same time is irrelevant.
Besides, freedom of the press in explicitly listed in the U.S. Constitution in addition to freedom of speech.:-)
So what? The government shouldn't be pushing any sort of god on the people, no matter what book, legend, epic poem, or comic strip it's based on. The particular beliefs of those who added "under God" to the pledge are about as relevant to its Constitutionality as the color of their socks on the day of that unfortunate occurrence.
I don't have to do that now. My server does, but see above about its load. Besides, the number of lookups it does for outgoing mail is dwarfed by the number it needs to do for incoming mail, and even more by those issued with some casual web browsing, so it wouldn't make much of a difference to the servers and networks I'm requesting the DNS data from either.
Why would you want to bother with all the crap involved in sending an email when you can let your ISP worry about it
Would you care to enumerate said "crap"? It's trivial to do; inbound is considerably more of a headache. Routing the mail to my ISP's server would be more work, albeit not by much.
Those people who actually know anything about SMTP actually pay for rack space and/or a real Internet connection.
What a bunch of arrogant bullshit! I happen to have a "real Internet connection", but I'll likely switch to a consumer-level connection at some point, as I'm having a hard time justifying the cost. If I were to do so, would my knowledge of the SMTP protocol or the method of setting up an SMTP server suddenly be wiped from my brain? Are others incapable of acquiring such knowledge because they never decided (or were able) to spend the extra money in the first place?
When you have read and completely understand RFC 821, 822, 2821, 2822, 1034, 1035, 1123, etc. then come talk to us.
...and bought rackspace or a "real" internet connection, right? While I certainly don't want to discourage the reading of RFCs, I don't see why it's necessary to know the byte-level format of a DNS request in order to configure a mail server to properly send outgoing mail.
Until then, go back to your Kazaa.
Ah, so now people who haven't read all of the RFCs you listed (or are we back to talking about those with cable or ADSL?) are not only inherently ignorant, but also, without exception, flagrantly ignore copyright law and load their systems with all kinds of malicious software. Uh huh.
And how happy will you be when Apple decides to grab your nifty keen new software and re-license it under a commercial NON free type license?
What difference does it make? You've still got the original, and people will only have to deal with Apple's license if they choose to use Apple's enhancements.
It seems to me that they would be under no obligation to compensate you for anything.
Of course not. If you wanted compensation, why did you release it as free software?
I wonder if they could also prevent you from further development on the code you wrote?
They couldn't. Once something is in the public domain, it stays there; Apple could only copyright their derived work.
That's poor design. There's no reason to use more than a single file for the cache
There's no reason to not use separate files, unless you're working around a crappy filesystem.
As for reasons to use it, besides cleanliness, you wouldn't have issues of fragmented sub-files within the file as objects are removed from the cache and objects of other sizes are added. By using individual files, you'd get to deal with fragmentation on the level of the whole filesystem, making it much more likely something will exist that will fit. Plus, due to maintaining separate codebases for both the outer and inner filesystems, both are likely to be worse due to not having whatever enhancements were made to the other.
If it's slow as hell, I wouldn't say it works.
You're right; I wouldn't say such filesystems work.
Sort of. Data management should be done in shared libraries, in user space,
not in the kernel.
That's an argument for putting the filesystem itself in userspace, not for the ugly filesystem-in-a-filesystem hacks that you seem to want.
If the system provides a filesystem that doesn't suck, whatever the state of the supervisor bit may be when its code executes, why not use it?
As for shared libraries, as opposed to some sort of server task, that removes the ability to have reasonable concurrent access to the data in question by multiple processes, and increases the odds of corruption if the app crashes.
I didn't pay anything for.NET extensions, as
I neither have nor want them (they wouldn't do me much good without Windows).
Are.NET extensions currently free? If so, you should
consider yourself lucky to get a free (well, except for having to actually agree to the EULA) $5 insurance policy with it. Unless you can prove
that it was intentional or grossly negligent on Microsoft's part, it's your own responsibility to keep
backups and buy your cat a chastity belt (or choose not to use the untrustworthy software). And if you can prove that, I doubt the EULA is going to make much of a difference.
Not all copies of Windows are bought via
an OEM's bundle. The amount actually paid for
Windows could be quite significant in the
case of site licenses. In the case of an OEM
bundle, you should be looking to the OEM to
provide any warrantees.
I believe you're thinking about Alpha (and to be pedantic, some instructions targetting r31 can be used as prefetches, as opposed to a simple NOP). r31 on PPC is a regular register.
IIRC, you also can't use r0 as a register in the addi instruction (you must use addic. instead), and there may be other non-load/store cases. After having been bitten by GCC picking r0 for an addi inline assembly instruction when I asked it for a general register, I can't really look at r0 as being completely general purpose. That doesn't mean that it's as restricted as r0 on MIPS, or that there are limitations on what value you can stick in there.
Actually, x86 has 7 general purpose registers (you probably forgot ESI, EDI, and EBP), and PPC has 31 (register zero has usage restrictions).
More importantly, though, with the speeds of current x86 hardware, and by using some sort of binary translation,
it should be possible to run PPC software on an x86 at least as fast as the first PPCs (and probably significantly faster).
So yes, one should "try again" on modern hardware.:-)
So, would that be like the way Apple's look-and-feel
lawsuit had a permanent chilling effect on the
adoption of Windows in corporate environments, even
though Windows "dodged the bullet" that time?
Or perhaps like the lawsuit over BSD, or any of numerous other
unsuccessful lawsuits that have been brought over
the years? I would imagine that most large
corporations would be used to these sorts of
games by now.
Yeah, so maybe warcraft II doesn't work on linux. It doesn't work without a cd-rom drive either. If I don't have a cd-rom drive is it legal for me to just download it without paying?
No, but it should be legal (but unfortunately probably isn't) for you to buy the CD, get a friend with a CD-ROM drive to convert it to media you can read (or send it to you over the network), and hack the game so that it doesn't obnoxiously require the CD to be present to play.
A reimplementation of the engine for Linux (or any other OS) is no different from a hack to disable CD checking. Both allow one who has purchased the game to play it under different circumstances. Blizzard gets every bit as much profit as it did before, minus the handful of people that are content to play it with replacement artwork and such.
If the latter is such a concern for Blizzard, they could easily set up a system whereby a valid Warcraft 2 CD key is required to download FreeCraft (or any other derivative work that someone might wish to produce).
What difference does it make? They apparently wanted multiplayer Civilization, and Civilization on platforms it previously did not support, not something else. It's their time to spend as they wish, not yours.
So why do Alpha, PPC, etc. have those things, when both have 31/32 registers?
The proper answer is, "ARM doesn't need them because it is targeted at low power applications, not high performance."
The odds are pretty low, but not zero. Thus, the code needs to handle that case (especially since it's most likely generic code that is not written specifically for Slashdot), and to do that, it can either use 32-bit integers, or implement bignums.
Guess which is faster?
My, we're feeling mature today.
The point is the ARM ====>instruction set===== is vastly superior.
It's a bit better then x86, but it's not that wonderful, and it's not the reason that ARMs are so low powered.
I've heard rumors that Intel toyed with the idea of a Ghz ARM core.
It's quite likely; they've got 733MHz XScales now. However, don't be fooled into thinking that they perform anywhere near what a superscalar, out-of-order 733 MHz x86 CPU would achieve. Things like that are where the bulk of the power consumption comes from.
x86 has all of 4 registers. You can muster up 3 more if you don't like debugging.
8, not 4. One is for the stack, but you counted that for ARM as well. One (not three) more is for debugging, and is not necessary if you have sufficient debugging information outside the code.
ARM favours bundling [e.g. you can rotate/shift inside an instruction]
Yeah, I'm sure that's conducive to high-speed implementations.
The ARM instruction set also sports generic multipliers [e.g. not just to one pair of registers]
So does x86 these days. It's been there since at least the 386 (maybe earlier); try to keep up.
blah blah blah.
Indeed.
I'm no particular fan of the x86 instruction set, but you could at least damn it for the things it is guilty of.
Actually, I think Budweiser and our current President are of roughly comparable quality... :-P
What right is California taking away here? The right to pollute? Is that guaranteed by the 9th Amendment too? Since you chose not to respond to my point that this has nothing to do with regulating travel, surely it can't be that...
Plus, its yet another really STOOPID idea, as I've pointed out already. And it will work to increase pollution, not decrease it.
It may very well be a stupid idea, but that doesn't make it Unconstitutional. After all, stupidity must be protected by the 9th Amendment too, right? :-)
That was a "stolen" Klingon ship, not the Enterprise.
But I thought you had a Right To Travel, laws be damned?
In any case, I see you ignored the other analogy, of blasting your speech at a high volume, using amplification equipment that you own, of course. :-)
This right is protected by the constitution (in that the constituion does not give the government the right to regulate travel, and thus that right is retained according to the constitution.)
Which constitution are you talking about? The U.S. constitution gives the states the right to regulate pollution (which is what this is about; it has nothing to do with travel) by way of the 10th amendment. The California constitution, like most state constitutions, does not follow the limited powers model of the U.S. constitution, but rather says what the government cannot do.
The only reason that Congress is restricted in the way it is is to establish a separation of powers between the states and the federal government. If this were being done by the federal government, you might have a point, but it's not, and so you don't.
The free speech clause prohibits laws against actions based on the speech component of the action. It does not prohibit restrictions on non-speech components, such as using someone else's printing press without their permission, or blasting one's speech at 100 dB in a residential neighborhood at 3 in the morning. By your argument, both of these would be a fundamental right, since they involve speech.
Similarly, the right to liberty of movement keeps the government from forcing you to stay where you are, but it does not stop it from regulating specfic means of transportation, as long as such regulations are not made on the basis of certain classes of people whom they do not wish to be allowed to travel, or are otherwise intended to abridge the right to liberty.
Driving a vehicle that fills a neighborhood with smog is no different, from a rights perspective, from filling it with high-amplitude sound waves. The fact that some other right was being exercised at the same time is irrelevant.
Besides, freedom of the press in explicitly listed in the U.S. Constitution in addition to freedom of speech. :-)
So what? The government shouldn't be pushing any sort of god on the people, no matter what book, legend, epic poem, or comic strip it's based on. The particular beliefs of those who added "under God" to the pledge are about as relevant to its Constitutionality as the color of their socks on the day of that unfortunate occurrence.
How so?
it reduces the load on your server
The load on my server is already negligible.
and you do not need to do DNS lookups.
I don't have to do that now. My server does, but see above about its load. Besides, the number of lookups it does for outgoing mail is dwarfed by the number it needs to do for incoming mail, and even more by those issued with some casual web browsing, so it wouldn't make much of a difference to the servers and networks I'm requesting the DNS data from either.
Why would you want to bother with all the crap involved in sending an email when you can let your ISP worry about it
Would you care to enumerate said "crap"? It's trivial to do; inbound is considerably more of a headache. Routing the mail to my ISP's server would be more work, albeit not by much.
Those people who actually know anything about SMTP actually pay for rack space and/or a real Internet connection.
What a bunch of arrogant bullshit! I happen to have a "real Internet connection", but I'll likely switch to a consumer-level connection at some point, as I'm having a hard time justifying the cost. If I were to do so, would my knowledge of the SMTP protocol or the method of setting up an SMTP server suddenly be wiped from my brain? Are others incapable of acquiring such knowledge because they never decided (or were able) to spend the extra money in the first place?
When you have read and completely understand RFC 821, 822, 2821, 2822, 1034, 1035, 1123, etc. then come talk to us.
...and bought rackspace or a "real" internet connection, right? While I certainly don't want to discourage the reading of RFCs, I don't see why it's necessary to know the byte-level format of a DNS request in order to configure a mail server to properly send outgoing mail.
Until then, go back to your Kazaa.
Ah, so now people who haven't read all of the RFCs you listed (or are we back to talking about those with cable or ADSL?) are not only inherently ignorant, but also, without exception, flagrantly ignore copyright law and load their systems with all kinds of malicious software. Uh huh.
Thus, it's obviously the basis for the HURD's release schedule.
What difference does it make? You've still got the original, and people will only have to deal with Apple's license if they choose to use Apple's enhancements.
It seems to me that they would be under no obligation to compensate you for anything.
Of course not. If you wanted compensation, why did you release it as free software?
I wonder if they could also prevent you from further development on the code you wrote?
They couldn't. Once something is in the public domain, it stays there; Apple could only copyright their derived work.
When was OpenVMS placed under the GPL (or any other open source license)?
There's no reason to not use separate files, unless you're working around a crappy filesystem.
As for reasons to use it, besides cleanliness, you wouldn't have issues of fragmented sub-files within the file as objects are removed from the cache and objects of other sizes are added. By using individual files, you'd get to deal with fragmentation on the level of the whole filesystem, making it much more likely something will exist that will fit. Plus, due to maintaining separate codebases for both the outer and inner filesystems, both are likely to be worse due to not having whatever enhancements were made to the other.
If it's slow as hell, I wouldn't say it works.
You're right; I wouldn't say such filesystems work.
That's an argument for putting the filesystem itself in userspace, not for the ugly filesystem-in-a-filesystem hacks that you seem to want. If the system provides a filesystem that doesn't suck, whatever the state of the supervisor bit may be when its code executes, why not use it?
As for shared libraries, as opposed to some sort of server task, that removes the ability to have reasonable concurrent access to the data in question by multiple processes, and increases the odds of corruption if the app crashes.
Are .NET extensions currently free? If so, you should
consider yourself lucky to get a free (well, except for having to actually agree to the EULA) $5 insurance policy with it. Unless you can prove
that it was intentional or grossly negligent on Microsoft's part, it's your own responsibility to keep
backups and buy your cat a chastity belt (or choose not to use the untrustworthy software). And if you can prove that, I doubt the EULA is going to make much of a difference.
Not all copies of Windows are bought via an OEM's bundle. The amount actually paid for Windows could be quite significant in the case of site licenses. In the case of an OEM bundle, you should be looking to the OEM to provide any warrantees.
I think both you and a certain moderator need to get a dictionary and look up the word "greater".
I believe you're thinking about Alpha (and to be pedantic, some instructions targetting r31 can be used as prefetches, as opposed to a simple NOP). r31 on PPC is a regular register.
IIRC, you also can't use r0 as a register in the addi instruction (you must use addic. instead), and there may be other non-load/store cases. After having been bitten by GCC picking r0 for an addi inline assembly instruction when I asked it for a general register, I can't really look at r0 as being completely general purpose. That doesn't mean that it's as restricted as r0 on MIPS, or that there are limitations on what value you can stick in there.
More importantly, though, with the speeds of current x86 hardware, and by using some sort of binary translation, it should be possible to run PPC software on an x86 at least as fast as the first PPCs (and probably significantly faster).
So yes, one should "try again" on modern hardware. :-)
Or perhaps like the lawsuit over BSD, or any of numerous other unsuccessful lawsuits that have been brought over the years? I would imagine that most large corporations would be used to these sorts of games by now.
I didn't think so.
No, but it should be legal (but unfortunately probably isn't) for you to buy the CD, get a friend with a CD-ROM drive to convert it to media you can read (or send it to you over the network), and hack the game so that it doesn't obnoxiously require the CD to be present to play.
A reimplementation of the engine for Linux (or any other OS) is no different from a hack to disable CD checking. Both allow one who has purchased the game to play it under different circumstances. Blizzard gets every bit as much profit as it did before, minus the handful of people that are content to play it with replacement artwork and such.
If the latter is such a concern for Blizzard, they could easily set up a system whereby a valid Warcraft 2 CD key is required to download FreeCraft (or any other derivative work that someone might wish to produce).
What difference does it make? They apparently wanted multiplayer Civilization, and Civilization on platforms it previously did not support, not something else. It's their time to spend as they wish, not yours.