While the things you mention are important, having a completely OO OS (and I'm not referring simply to the kernel here) will make it easier for people to develop for the platform. This, in turn, will result in faster development for the platform, which allows your goals to be met more quickly and easily.
I'm sorry, but you won't give the grocery store clerk across the street a copy of RH 6.1 Intel or Alpha, who is already running Win98 on his Gateway and expect him to install/configure/use it successfully.
Well, I'd hope you wouldn't expect him to be able to successfully install Linux/alpha on anything win98 will run on.:-)
Also, Diablo was not working barely after it came out; I had the game for quite a while back when I used a K6-2 and all that I could do with Diablo in Wine was play the movies.
Wine doesn't work to well for those of us with non-x86 processors. Of course, neither do most commercial games, though there are exceptions (like Civ:CTP).
Think of the memory consumption (if it's not being wasteful, why then did you claim that in this case using long was sub-optimal?).
I don't remember saying that, though it is a valid concern. Overall, though, I doubt the breakage that would result from sizeof(void*)>sizeof(long) would be outweighed by the memory savings.
IIRC, that's an old K&R thing and in ANSI C, pointers and ints are completely different animals and can never be inter-converted. Or maybe that's just the upcoming new ANSI standard.
I don't have the C spec here, and it's not in the C++ spec, so I'll take your word for it. However, without an integer type big enough to hold a pointer, how are you going to compare a pointer to another using operators like <? And there is a lot of code out there that does assume that sizeof(void*)<=sizeof(long).
Indeed, why use a 64-bit chip at all?
Because a 32-bit address space is too small? So that when you need to manipulate 64-bit data, you can do it efficiently? Why use 32-bit processors, then? Once upon a time, a 16-bit CPU was a high-end chip (in the PC world, at least).
But more on topic, very little portable ANSI C code will make profitable use of a 64-bit long
And how much code out there is portable ANSI C?
If you are going to write non-portable code, why even bother sticking to the standard?
So that the code can run on 99.9999% of the machines someone may want to run it on, instead of, say, 85%, or 50%, or 1%, depending on how far you deviate from the standard and what assumptions you make?
No, it doesn't. There would be far more breakage with a 32-bit long on alpha.
Longs are only required to have the range of a 32-bit number, so it is wasteful to include more bits.
IIRC, C requires long to be large enough to hold a pointer. On non-NT alpha, that's 64 bits.
64 bit operations on an alpha are no slower than 32 bit operations, so it's not really being wasteful.
Why use a 64-bit chip if you're only ever going to use half of it?
which is, I suppose, good for networking code, though I fear people will abuse it; IMHO it's better the way it is where you should chop everything up manually into whatever format the protocol takes
Some people abuse virtually all aspects of the language as it is; I don't think that should be the only thing keeping new features out. As for protocols, with types of a guaranteed size, you can use the struct as the protocol itself (as long as you put everything in network byte order, of course... and htonX functions for the fixed types would help.) It also helps for accessing structures on disk, talking to devices, etc.
On a machine with 64 bit ints, as on a machine with 32 bit ints, ints and longs are the same (assuming the compiler was competently designed; it could fit the standard without being). So I guess gcc, ccc, and all other non-NT compilers for the alpha are not competently designed? They use 32-bit ints and 64-bit longs. (NT has a 32-bit long).
While we waited in line we watched a couple of 10 year old boys competing to see who could find the hardest porn. It wasn't too easy: the museum home page had no links to general search engines and no way to type in a URL.
Heh, that reminds me of contests I've had with my roommates in the past, where the goal is to navigate, in as few clicks as possible, from yahooligans to porn. No typing was allowed, either URLs or into search engines. I believe the record was around 7 clicks.
Some special CDDA+Data formats seem to prevent in some way digital audio extraction. In order to listen to them in my car (so a legal copy), I've tried to make copy of two of David Bowie's back catalogue remastered CDs published by EMI in the late 1999. On these two CDs, I got a SCSI error while extracting the last track (tried with three CD readers and different DAE utilities)
I've noticed that problem with Weird Al's latest (not trying to copy, but just using DAE to play it since I have no audio cable), however the point at which it screws up is past where the final track *should* have ended (and indeed does end on a conventional CD player). Do yours fail during the music itself?
Isn't that some kind of copy-protection too ?
It could be, but there's always the possibility that there was a bug in whatever produced the CDs. Remember, "Never attribute to malice what can be sufficiently explained by stupidity".
In other word you can redistribute the object file and ask your user to link it themselves
More specifically, it would be ld.so (or equivalent) running on the user's system that links it for you. All the user has to do for this to happen is run the binary.
I still don't find it very useful, it would cause less problem to reimplement the GPL program than to try to cirumvent the GPL
I'm not advocating the circumvention of the GPL; however, to many corporations, putting their extensions in a proprietary library looks a lot more attractive to them than either releasing them under the GPL or reimplementing the GPLed code. And to be honest, if I absolutely have to use proprietary code, I'd rather have the amount which is proprietary be as little as possible; given a choice between a GPL core and a proprietary library, and a completely proprietary program, I'll choose the GPL core.
Yup, but what good is it to you if you can't redistribute it without breaking the GPL?
You can distribute the unlinked executable; you can't distribute a statically linked binary or the image in memory formed by dynamically linking with non-GPL code.
I don't think you are right to be as categoric, after all,a library is distinct from the software that links against it, so I could modify a GPL'd software to link with a non-(L)GPL library given your reasoning.
That was my point. What is the difference, legally speaking, between a module and a dynamically loaded library? Even in the technical sense, modules are usually implemented as dynamic libraries which, instead of being automatically loaded along with the program, are loaded with a call to dlopen().
In both cases, the distributed executable, and certainly the distributed source code, contain no non-GPL code.
Besides, if you really think about the consequences of your interpretation, it leads to absurdities. Suppose there is a program distributed under the GPL which requires a dynamically linked proprietary library to function. According to you, this would violate the license. Then, a compatible replacement library is released under the GPL. This release, which is completely independent of the code in question, now makes distribution of the original program under the GPL legal. It's even worse the other way around: Suppose that the original library is under the GPL, but all copies of said library are destroyed. All that remains is a compatible proprietary replacement. Now the original program can no longer be distributed under the GPL.
Could you point out the section of the GPL that prohibits non-GPL modules, rather than talking about the "very point" of the license which means absolutely nothing in court?
The GPL restricts distribution, not use. The binary only, or otherwise non-GPL module is distributed as a distict entity from the GPLed code, and as such is not subject to the GPL. The GPLed code, as distributed, contains no non-GPL code. It is the user that links the two together at runtime, which also is not prohibited. As long as the user doesn't distribute a core dump or other post-link binary, there is no violation.
If you are not happy you can fork the kernel and make it truly GPL, but don't count on us to follow you and don't forget to call it otherwise than Linux (Lunix if you want, or Trollix).
Huh? Representations of numbers have bases, not the numbers themselves. The problem with radix sort is when you have a very large range of possible values (such as when you treat strings as large numbers); the amount of memory needed for the buckets and the time to collect the results from the buckets is exponential in the chosen base. Thus, for large numbers (such as strings) you need to choose a comparatively small base, which means you have to repeat the process many times.
The DMCA has nothing to do with whether copyrighted software is used to carry out the protection (and you can't copyright a technique, BTW); it is the material being protected that must be under copyright for the law to apply. For example, for the encryption program, you should claim copyright on the text itself that you wish to send.
And why would you need to use a program to generate a copyrighted encryption program? Most available encryption software is already copyrighted.
There is nothing in the GPL that prohibits making a profit on distribution... you simply can't change the license, so that they can't prevent, for example, cheapbytes from distributing the same software for a much lower price. The FSF itself charges quite a bit for their CDROM distributions (up to the deluxe set of $5000 for all GNU software compiled for your platform of choice). They also charge corporations more than individuals. The GPL enforces the freedom of the software, not the distribution price.
--
Re:64-bit won't be relevant to PCs until 2003, 200
on
News on Pentium IV
·
· Score: 1
What 32-bit cruft?
The only 32-bit code running on my linux/alpha box is netscape.
RMS claims that the GPL applies to enhancements in the form of dynamically loaded libraries, which may be distributed independently of a program.
IANAL, but I don't see how. If company X distributes a proprietary.so that can be loaded by a GPL program, who is violating copyright? Not the makers of the.so, as it is in no way derived from the GPL program. The GPL doesn't change copyright law. Who else could be in violation? It can't be the writer of the GPL program, as he/she has no involvement with the plugin. It's also not the user who loads the plugin, as the GPL only restricts distribution of derived works, and the derived work is not created until runtime. About the only thing it prevents you from doing in this instance is distributing a core file with the plugin loaded.
If he is right, I see no reason not to extend it to executable files that use a GPLed programs interfaces, be they command line or dynamic linker-based.
That would be a bad thing, even if it were possible. Now netscape can't run an external app by calling the shell, if it happens to be bash? What about apps calling syscalls of a GPL kernel? Web browsers connecting to a GPL web server? It would have disastruous consequences.
This is one of my pet peeves about the GPL: that the definition of modifications is too strict. If I write a set of programs and scripts that form a system when used together (for example, RCS), I'd like to be able to use the GPL to ensure that no company can enhance the system by adding more programs to my collection, and then release the enhancements as proprietary.
You can't do this without restricting bundling in general, which would prohibit putting, say, netscape 4.x and linux on the same CD. Even then, they could distribute their enhancements independently, and nothing you put in your license can stop them, as their product is not a derivative work of yours, but simply something that works with it.
And precisely how would the GPL keep Microsoft from porting IE and other apps to Linux? As long as they don't link any third party GPLed code with their own, they would be under no obligation to release source. Bundling a closed source product with a GPLed product is completely legal.
Slashdot Mirror
And it's perfectly easy (and quite common) to be object oriented without cout, and to not be object oriented with cout.
--
--
I'm sorry, but you won't give the grocery store clerk across the street a copy of RH 6.1 Intel or Alpha, who is already running Win98 on his Gateway and expect him to install/configure/use it successfully.
Well, I'd hope you wouldn't expect him to be able to successfully install Linux/alpha on anything win98 will run on. :-)
--
No, but code that assumes sizeof(long)>=sizeof(void*) will run on the vast majority of computers in common use.
--
Starcraft, OTOH, did work nicely...
--
--
I don't remember saying that, though it is a valid concern. Overall, though, I doubt the breakage that would result from sizeof(void*)>sizeof(long) would be outweighed by the memory savings.
IIRC, that's an old K&R thing and in ANSI C, pointers and ints are completely different animals and can never be inter-converted. Or maybe that's just the upcoming new ANSI standard.
I don't have the C spec here, and it's not in the C++ spec, so I'll take your word for it. However, without an integer type big enough to hold a pointer, how are you going to compare a pointer to another using operators like <? And there is a lot of code out there that does assume that sizeof(void*)<=sizeof(long).
Indeed, why use a 64-bit chip at all?
Because a 32-bit address space is too small? So that when you need to manipulate 64-bit data, you can do it efficiently? Why use 32-bit processors, then? Once upon a time, a 16-bit CPU was a high-end chip (in the PC world, at least).
But more on topic, very little portable ANSI C code will make profitable use of a 64-bit long
And how much code out there is portable ANSI C?
If you are going to write non-portable code, why even bother sticking to the standard?
So that the code can run on 99.9999% of the machines someone may want to run it on, instead of, say, 85%, or 50%, or 1%, depending on how far you deviate from the standard and what assumptions you make?
--
No, it doesn't. There would be far more breakage with a 32-bit long on alpha.
Longs are only required to have the range of a 32-bit number, so it is wasteful to include more bits.
which is, I suppose, good for networking code, though I fear people will abuse it; IMHO it's better the way it is where you should chop everything up manually into whatever format the protocol takes
Some people abuse virtually all aspects of the language as it is; I don't think that should be the only thing keeping new features out. As for protocols, with types of a guaranteed size, you can use the struct as the protocol itself (as long as you put everything in network byte order, of course... and htonX functions for the fixed types would help.) It also helps for accessing structures on disk, talking to devices, etc.
--
between the quote and my text. It showed up that way in preview. Slashdot ate it when I submitted.
--
--
Heh, that reminds me of contests I've had with my roommates in the past, where the goal is to navigate, in as few clicks as possible, from yahooligans to porn. No typing was allowed, either URLs or into search engines. I believe the record was around 7 clicks.
--
I've noticed that problem with Weird Al's latest (not trying to copy, but just using DAE to play it since I have no audio cable), however the point at which it screws up is past where the final track *should* have ended (and indeed does end on a conventional CD player). Do yours fail during the music itself?
Isn't that some kind of copy-protection too ?
It could be, but there's always the possibility that there was a bug in whatever produced the CDs. Remember, "Never attribute to malice what can be sufficiently explained by stupidity".
--
More specifically, it would be ld.so (or equivalent) running on the user's system that links it for you. All the user has to do for this to happen is run the binary.
I still don't find it very useful, it would cause less problem to reimplement the GPL program than to try to cirumvent the GPL
I'm not advocating the circumvention of the GPL; however, to many corporations, putting their extensions in a proprietary library looks a lot more attractive to them than either releasing them under the GPL or reimplementing the GPLed code. And to be honest, if I absolutely have to use proprietary code, I'd rather have the amount which is proprietary be as little as possible; given a choice between a GPL core and a proprietary library, and a completely proprietary program, I'll choose the GPL core.
--
"I swear, I just ran it through that filter to reduce the background noise..."
--
You can distribute the unlinked executable; you can't distribute a statically linked binary or the image in memory formed by dynamically linking with non-GPL code.
I don't think you are right to be as categoric, after all,a library is distinct from the software that links against it, so I could modify a GPL'd software to link with a non-(L)GPL library given your reasoning.
That was my point. What is the difference, legally speaking, between a module and a dynamically loaded library? Even in the technical sense, modules are usually implemented as dynamic libraries which, instead of being automatically loaded along with the program, are loaded with a call to dlopen().
In both cases, the distributed executable, and certainly the distributed source code, contain no non-GPL code.
Besides, if you really think about the consequences of your interpretation, it leads to absurdities. Suppose there is a program distributed under the GPL which requires a dynamically linked proprietary library to function. According to you, this would violate the license. Then, a compatible replacement library is released under the GPL. This release, which is completely independent of the code in question, now makes distribution of the original program under the GPL legal. It's even worse the other way around: Suppose that the original library is under the GPL, but all copies of said library are destroyed. All that remains is a compatible proprietary replacement. Now the original program can no longer be distributed under the GPL.
--
The GPL restricts distribution, not use. The binary only, or otherwise non-GPL module is distributed as a distict entity from the GPLed code, and as such is not subject to the GPL. The GPLed code, as distributed, contains no non-GPL code. It is the user that links the two together at runtime, which also is not prohibited. As long as the user doesn't distribute a core dump or other post-link binary, there is no violation.
--
Sorry, but Lunix is already taken.
--
--
--
And why would you need to use a program to generate a copyrighted encryption program? Most available encryption software is already copyrighted.
--
--
The only 32-bit code running on my linux/alpha box is netscape.
IANAL, but I don't see how. If company X distributes a proprietary .so that can be loaded by a GPL program, who is violating copyright? Not the makers of the .so, as it is in no way derived from the GPL program. The GPL doesn't change copyright law. Who else could be in violation? It can't be the writer of the GPL program, as he/she has no involvement with the plugin. It's also not the user who loads the plugin, as the GPL only restricts distribution of derived works, and the derived work is not created until runtime. About the only thing it prevents you from doing in this instance is distributing a core file with the plugin loaded.
If he is right, I see no reason not to extend it to executable files that use a GPLed programs interfaces, be they command line or dynamic linker-based.
That would be a bad thing, even if it were possible. Now netscape can't run an external app by calling the shell, if it happens to be bash? What about apps calling syscalls of a GPL kernel? Web browsers connecting to a GPL web server? It would have disastruous consequences.
You can't do this without restricting bundling in general, which would prohibit putting, say, netscape 4.x and linux on the same CD. Even then, they could distribute their enhancements independently, and nothing you put in your license can stop them, as their product is not a derivative work of yours, but simply something that works with it.
And precisely how would the GPL keep Microsoft from porting IE and other apps to Linux? As long as they don't link any third party GPLed code with their own, they would be under no obligation to release source. Bundling a closed source product with a GPLed product is completely legal.