Under US patent law, I don't know that a free-software patent-pool would do anything significant except waste money--a better solution is to, when you come up with an idea for something new, create a reference implementation. This stops anyone else from gaining a pat for it, in the future, as you can easily demonstrate prior art.
Also, being able to say that something is unpatented helps assure everyone that no one--not even you--are going to abuse a patent. Witness PNG.
`Computer science' is *not* `computer literacy'
on
ArsDigita University
·
· Score: 1
"It seems with a computer science degree, half of anything you learned more than a year ago is obsolete" "1994 they were using Win3.11/Dos5. 1995, Win95A. '96-Win95B. 1998 - Win98. 1999 - Win98SE. Toss in the changes made to Windows NT/2000 (That would be from 3.51 to W2K) and all of the different *nixs and look what you have..."
So? Where's the connection between these two statements?
Upon starting his CS education, a friend of mine told me that he was suprised that the CS curricula didn't include courses on how to use various operating systems and other pieces of software.
I told him that CS wasn't about being able to use some piece of software (or hardware), but about the concepts that go into the creation of those things.
There are indeed operating-systems courses that one may take when persuing a CS degree, but those are in OS-design, not -use.
CS isn't about learning to use the latest version of Windows anymore than mathematics is about knowing where all of the buttons on the latest TI graphing calculator are.
"Personally, although I support the GPL, I don't think that binaries linking to a piece of code should be a derivative work"
Being nit-picky over what `derivative work' means is not what the GPL for (that's what the LGPL is for;))--the point of saying `you can only use my code to produce free software' is exactly that.
When I say that, I mean that I don't want anyone using my code to create more non-free software--I don't care about the thechnical issues that pertain to how exactly their program uses the code in mine--I know that my code would be used to remove user freedoms, and I say `no', to that, by licensing it under something like the GPL.
Now, if you just want to use one of my GPL'd libraries, but you don't think that it's useful enough for you to release your project under the same terms, then don't use my library--I don't want lots of users for myself, I want lots of free software for the users:)
Something is illegal. You can get around it--you can still do it without getting caught. Many people won't do it, though. Maybe the things falling under heavy regulation will never become so popular as to be the only way. So?
It doesn't matter if you can get around it, and it doesn't matter whether eBooks will ever or never become more popular than paper books--if you don't support something, don't let it become law. If there's something broken, fix it.
"try to make mesa work - hah! try to get/dev/3dfx to work - hah! install game try to make game use mesa - hah!"
Here's something that I've been through:
0] try to get proprietary binaries to run 1] fail to get said binaries to run 2] wonder why they don't run 3] give up on trying to make them run (the most that I can do is reinstall the binaries, which are still proken) 4] `uninstall' program, which nukes msvcrt*.dll, breaking OS 5] say, `damnit!'; lay head on table; sulk 6] fix operating system 7] write my own damned program that works exactly as I want ^_^
By the way: I just built a new computer (with a Voodoo 3 board), installed a Linux GNU on it, and then installed XFree86 4.0. Then I discovered that I needed DirectX 7GlideV3. I'll give that a go in a week or two--I'll let you know how it goes ^_^
In Windows: 1. dowload and install drivers 2. download and install directX 3. reboot (we can ignore this) 4. configure drivers 5. play games
using X: 1. download latest X binaries in chosen format and install them 2. X -configure; startx 3. play games
That's not so hard, is it? If nobody's built binaries, and you don't know how, then ask someone to do it for you.
If you don't want to do a build from source (or don't want to do XXX), you don't really have to--the free-unix world isn't `one size fits all'.
Jeez; `you don't have GL installed properly' is equivalent to `you don't have directX'. If I want to pick on Windows, I can say, `Why do I have to download a new version of dirextX--why doesn't my video driver just work? Why do I have to download a different version of directX if I'm running NT or 9x? Why do I have to get Windows 2000 just to get the newest directX for NT?'.
"The English language has only one word, "free", to represent two concepts..."
The English language has two words to represent two concepts: "gratuitous", as in, "we're giving out gratuitous beer", and "unfettered", as in, "unfettered software":)
Actually, there are a good deal more than two, like "complimentary", "liberal", and of course, "free", as in, "free of (bonds|charge|restraints|taxes|.+)".
Of course, the only word that many people understand following "free of" is "charge". Hunh.
Frank Zappa said, "If we cannot be free, then at least we can be cheap!"
"The only reason this will come back to bite them is because they assigned the rights to the general public"
... except, they didn't assign their rights to the general public--`GPL' is not the same as `public domain'.
The GPL entitles the licensee to use, modify, and redistribute the source code, optionally accompanied by binaries. That's it.
The licensee does not have the right to distributes lone binaries or binaries linked against proprietary libraries; the licensee does not have the right to sublicense or in other ways change the license of any part of the software. The licensee does not have the right to do anything that would restrict the future liberty of the software(-users).
The copyright-holder of the software, on the other hand, does have the right to do everything listed above.
What would happen in a situation with the traditional `you can use it, and that's it' license?
With almost any license, licensees get usage-rights, so any statement by almost any author that it has `all rights to the software, exclusively' sounds less than entirely valid.
Once you've given something to someone, under any license that doesn't state `we can revoke this license', you can't just take it back, can you?
As far as simple redistribution is concerned (as in this case), how is the GPL different than any other freeware license?
"How do you fork something and add hooks to your own apps while leaving everyone else out in the cold ?"
Exactly--this kind of forced incompatibility is one of the things that the GPL is designed to prevent; I think that RMS said, `no one can impose an incompatibility on you, because you're free to remove that incompatibility'.
When everything can interoperate, software-developers can't rely on lock-in, and they <EM>shouldn't</EM> have to rely on lock-in, anyway.
BSD forked, a long time ago; does anyone really care? Has the fork hurt BSD? Has it forced incompatibilities on all of the users all of the branches of BSD?
"What is the reason for limiting the number of TLD's?"
A better question is, `what is the reason for having suffixes on TLDs?', and the answer might be that it allows different entities wanting the same name for different reasons to have that same name.
"It seems to me it'd be just as well to allow any organization to register a single TLD as their own."
It sounds like you mean, `drop the suffixes' (unless a full name of just "ibm" would be illegal).
I think that the suffixes on domain-names are akin to suffixes or prefixes on file-names (they're an easy way to have and differentiate between several files with the same name but different types).
"I would assume that, in this architecture, if you change one of the instances, it creates a new copy and does not modify the original file. This would allow you to have only one copy of a configuration file that needs to be copied to each user's directory for possible customization and only have the extra copies made if someone did, in fact, customize. Can anyone out there who really knows about Single Instance Store care to comment? "
I don't expect that they've got this working exactly like unix links, because that would really change the semantics in the file-system;
What would make more sense (and what it sounds more like, reading the article) is that links are used where content is identical, and links are replace by `real data' when the content becomes non-identical.
Ideally, rather than duplicating an entire file when a few bytes change, only these new, changed bytes are represented on the disk as `real', and the other bytes, which are still identical to those in another file, remain links/pointers--stripping out redundant data (and you can do all of this at the level of how the file-system stores data, underneath the level of `how the file-system presents things to userspace').
This is what's known as file-system compression:) Compression has been used in MS OSs (sortof: how did doublespace work?), and has also been used in many other OSs and file-systems.
Of course, it'd be really nice to have symlinks and hardlinks, too:)
I'd also like to see another type of link, which I haven't seen anywhere, yet: it acts like a hard link, but, when the `official' (initial?) copy/link goes away, all of these links go away (like `aliases' in Netscape's bookmark-files).
Somehow, though, "Geeko the chameleon" sounds better than "Geeko the gecko". It has a better rhythm. I think that I just prefer things ending in "eon" to things enging in "o", too:)
"Can you drag a range of text from an emacs window and drop-insert it into a vi window? Or can you drop a JPEG file from the desktop into your text? Or when you get some new application, do you have to learn all new command-keys and shortcuts, or recalibrate your muscle memory for the way the menus work and so forth?
That's what a standard GUI API is for..."
Except... that's not what a standard API is for--
There actually is a (somewhat) standard drag'n'drop protocol....
Note that I say "protocol", rather than "API", and note that protocol is rather independant of API. As noted at the XDND web-site, there are several APIs supporting the same protocol.
As for whether I can do drag'n'drop between applications written with different APIs: yes, I can--examples include doing drag'n'drop between Motif-based Netscape and GTK+-based GMC. I believe that there are also versions of VI and Emacs that support drag'n'drop of text and images (GNU Emacs, under X, is not such a beast, but this does not stem from the mere fact that it uses a different API).
As for key-bindings.... Key-bindings have even less to do with the API than drag'n'drop does.
"I like both desktop environments, personally, but I don't like the separation like that. Is there anything we could do like that, other than have window manager/desktop environment/tk wars?"
0] help the GNOME/KDE/etc. teams make the environments' component tools all play nicely together, or...
1] help the wxWindows group improve/finish their ports.
Why does it matter whether unrelated projects use the same API or not? You choose the GUI and API that you fid most pleasant, or that best suits your application. If my application can interact with other applications in all of the important ways, why should I care what API the other guy is using? It doesn't affect me.
This sounds like another holy war. Jeez. I use emacs. The guy next to me is using VIM. What do I care? I can still read and write each other's files, right?
Re:But there's an important choice we don't have
on
Gnome 1.1.4 Released
·
· Score: 1
I'll agree that there isn't a choice between different free compilers, and I'll agree that it is a *massive* effort to write a brand new compiler....
I'd really like answered: why do you want more compilers? Or, in other words: what do you hope to find that's different?
`cc' commands aren't really like `desktop' software, where you can completely change the UI, and be able to say, `I like this better because it has a friendlier UI'--mainly because it breaks compatibility with every other compiler and makefile and configure script in a big way. Hm. If a different set of command-line arguments is all you want, it shouldn't be too hard to write a front end (just for when the user is manually using gcc) that converts from user-specific command-line-style to a native gcc command-line.
Having that said, the only other aspects of compilers that I can think of are the languages that they support, the platforms that they compile to and the quality of the output that they produce; in the first and second cases, it's really not so necessary to write an entirely new compiler-system, because you can write a front-end `compiler' for the C-compiler, or a back-end, or even just the assembler component. Hm. I'm assuming that the AC was referring to the whole compilation system--the preprocessor, the compiler, the assembler, the linker..., rather than just the compiler....
Anyway, to the last point: performance: Wanting a better-performing compiler is valid, regardless of how good GCC is (always try to make things better, eh?), but that really doesn't seem like a reason for maintaining two compilers--is the justification `some people want a low-quality compiler and some want a high-quality compiler'? Actually..., that may be a good point (I rather like having a slow system to test things on, just because it makes differences in the qualities of algorithms so evident), but still not one that warrants two different compilers, because the compiler takes optimisation switches. There might be specific types of algorithms or code-segments that one compiler is better at compiling, and so one could say `I use X when compiling type-x code, and I use Y when compiler type-y code', but, since we have the ability to do so, I'd still argue that it's better to fold all of the goodness into something like GCC. Then, there are, of course... rewrites of GCC (ie: 1, 2).
Slashdot Mirror
Under US patent law, I don't know that a free-software patent-pool would do anything significant except waste money--a better solution is to, when you come up with an idea for something new, create a reference implementation. This stops anyone else from gaining a pat for it, in the future, as you can easily demonstrate prior art.
Also, being able to say that something is unpatented helps assure everyone that no one--not even you--are going to abuse a patent. Witness PNG.
"It seems with a computer science degree, half of anything you learned more than a year ago is obsolete"
"1994 they were using Win3.11/Dos5. 1995, Win95A. '96-Win95B. 1998 - Win98. 1999 - Win98SE. Toss in the changes made to Windows NT/2000 (That would be from 3.51 to W2K) and all of the different *nixs and look what you have..."
So? Where's the connection between these two statements?
Upon starting his CS education, a friend of mine told me that he was suprised that the CS curricula didn't include courses on how to use various operating systems and other pieces of software.
I told him that CS wasn't about being able to use some piece of software (or hardware), but about the concepts that go into the creation of those things.
There are indeed operating-systems courses that one may take when persuing a CS degree, but those are in OS-design, not -use.
CS isn't about learning to use the latest version of Windows anymore than mathematics is about knowing where all of the buttons on the latest TI graphing calculator are.
"The only really new language that's come out has been Java"
Eh? What's so new about Java?
"Personally, although I support the GPL, I don't think that binaries linking to a piece of code should be a derivative work"
Being nit-picky over what `derivative work' means is not what the GPL for (that's what the LGPL is for;))--the point of saying `you can only use my code to produce free software' is exactly that.
When I say that, I mean that I don't want anyone using my code to create more non-free software--I don't care about the thechnical issues that pertain to how exactly their program uses the code in mine--I know that my code would be used to remove user freedoms, and I say `no', to that, by licensing it under something like the GPL.
Now, if you just want to use one of my GPL'd libraries, but you don't think that it's useful enough for you to release your project under the same terms, then don't use my library--I don't want lots of users for myself, I want lots of free software for the users:)
"I don't think using MaPlay code to play MP3 files instead of WAV files justifies that an entire game's source tree must be GPL'd."
If the library is that trivial, then either make a deal with the developers whose code you're using, or don't use said code.
"Obviously it should be for Open Source reasons but is the enforcement of GPL valid?"
'as valid as any other license.
Why wouldn't it be?
Something is illegal.
You can get around it--you can still do it without getting caught.
Many people won't do it, though.
Maybe the things falling under heavy regulation will never become so popular as to be the only way.
So?
It doesn't matter if you can get around it, and it doesn't matter whether eBooks will ever or never become more popular than paper books--if you don't support something, don't let it become law. If there's something broken, fix it.
"try to make mesa work - hah! /dev/3dfx to work - hah!
try to get
install game
try to make game use mesa - hah!"
Here's something that I've been through:
0] try to get proprietary binaries to run
1] fail to get said binaries to run
2] wonder why they don't run
3] give up on trying to make them run (the most that I can do is reinstall the binaries, which are still proken)
4] `uninstall' program, which nukes msvcrt*.dll, breaking OS
5] say, `damnit!'; lay head on table; sulk
6] fix operating system
7] write my own damned program that works exactly as I want ^_^
By the way: I just built a new computer (with a Voodoo 3 board), installed a Linux GNU on it, and then installed XFree86 4.0. Then I discovered that I needed DirectX 7GlideV3. I'll give that a go in a week or two--I'll let you know how it goes ^_^
In Windows:
1. dowload and install drivers
2. download and install directX
3. reboot (we can ignore this)
4. configure drivers
5. play games
using X:
1. download latest X binaries in chosen format and install them
2. X -configure; startx
3. play games
That's not so hard, is it?
If nobody's built binaries, and you don't know how, then ask someone to do it for you.
If you don't want to do a build from source (or don't want to do XXX), you don't really have to--the free-unix world isn't `one size fits all'.
Jeez; `you don't have GL installed properly' is equivalent to `you don't have directX'. If I want to pick on Windows, I can say, `Why do I have to download a new version of dirextX--why doesn't my video driver just work? Why do I have to download a different version of directX if I'm running NT or 9x? Why do I have to get Windows 2000 just to get the newest directX for NT?'.
"Neither patent has merit... And I say that one bad patent deserves another ;)" ... leading to a world full of bad patents.
wxStudio (http://wxstudio.linuxbox.com/)also seems to be coming along fairly well.
"The English language has only one word, "free", to represent two concepts..."
The English language has two words to represent two concepts: "gratuitous", as in, "we're giving out gratuitous beer", and "unfettered", as in, "unfettered software":)
Actually, there are a good deal more than two, like "complimentary", "liberal", and of course, "free", as in, "free of (bonds|charge|restraints|taxes|.+)".
Of course, the only word that many people understand following "free of" is "charge". Hunh.
Frank Zappa said, "If we cannot be free, then at least we can be cheap!"
"The only reason this will come back to bite them is because they assigned the rights to the general public"
... except, they didn't assign their rights to the general public--`GPL' is not the same as `public domain'.
The GPL entitles the licensee to use, modify, and redistribute the source code, optionally accompanied by binaries. That's it.
The licensee does not have the right to distributes lone binaries or binaries linked against proprietary libraries; the licensee does not have the right to sublicense or in other ways change the license of any part of the software. The licensee does not have the right to do anything that would restrict the future liberty of the software(-users).
The copyright-holder of the software, on the other hand, does have the right to do everything listed above.
What would happen in a situation with the traditional `you can use it, and that's it' license?
With almost any license, licensees get usage-rights, so any statement by almost any author that it has `all rights to the software, exclusively' sounds less than entirely valid.
Once you've given something to someone, under any license that doesn't state `we can revoke this license', you can't just take it back, can you?
As far as simple redistribution is concerned (as in this case), how is the GPL different than any other freeware license?
Isn't there a problem with `new desktop paradigm'?
Do you want a new GUI model, or do you want to stick with the `desktop' model?
"Actually, a Qubit is the distance from your elbow to the tips of your fingers."
Isn't that a `cubit'?
Kwoobit....
My highschool, in new hampshire, bought a digital video camera, which records onto mididiscs, a few months ago, I think.
"How do you fork something and add hooks to your own apps while leaving everyone else out in the cold ?"
Exactly--this kind of forced incompatibility is one of the things that the GPL is designed to prevent; I think that RMS said, `no one can impose an incompatibility on you, because you're free to remove that incompatibility'.
When everything can interoperate, software-developers can't rely on lock-in, and they <EM>shouldn't</EM> have to rely on lock-in, anyway.
Incompatibilities only <EM>slow</EM> progress.
Linux is going to fork? So?
BSD forked, a long time ago; does anyone really care? Has the fork hurt BSD?
Has it forced incompatibilities on all of the users all of the branches of BSD?
I'm really tempted to sit down and make Linux able to run FreeBSD binaries....
It shouldn't be that hard, eh?
"What is the reason for limiting the number of TLD's?"
A better question is, `what is the reason for having suffixes on TLDs?', and the answer might be that it allows different entities wanting the same name for different reasons to have that same name.
"It seems to me it'd be just as well to allow any organization to register a single TLD as their own."
It sounds like you mean, `drop the suffixes' (unless a full name of just "ibm" would be illegal).
I think that the suffixes on domain-names are akin to suffixes or prefixes on file-names (they're an easy way to have and differentiate between several files with the same name but different types).
"I would assume that, in this architecture, if you change one of the instances, it creates a new copy and does not modify the original file. This would allow you to have only one copy of a configuration file that needs to be copied to each user's directory for possible customization and only have the extra copies made if someone did, in fact, customize. Can anyone out there who really knows about Single Instance Store care to comment? "
I don't expect that they've got this working exactly like unix links, because that would really change the semantics in the file-system;
What would make more sense (and what it sounds more like, reading the article) is that links are used where content is identical, and links are replace by `real data' when the content becomes non-identical.
Ideally, rather than duplicating an entire file when a few bytes change, only these new, changed bytes are represented on the disk as `real', and the other bytes, which are still identical to those in another file, remain links/pointers--stripping out redundant data (and you can do all of this at the level of how the file-system stores data, underneath the level of `how the file-system presents things to userspace').
This is what's known as file-system compression:)
Compression has been used in MS OSs (sortof: how did doublespace work?), and has also been used in many other OSs and file-systems.
Of course, it'd be really nice to have symlinks and hardlinks, too:)
I'd also like to see another type of link, which I haven't seen anywhere, yet: it acts like a hard link, but, when the `official' (initial?) copy/link goes away, all of these links go away (like `aliases' in Netscape's bookmark-files).
Somehow, though, "Geeko the chameleon" sounds better than "Geeko the gecko". It has a better rhythm.
I think that I just prefer things ending in "eon" to things enging in "o", too:)
"Can you drag a range of text from an emacs window and drop-insert it into a vi window? Or can you drop a JPEG file from the desktop into your text? Or when you get some new application, do you have to learn all new command-keys and shortcuts, or recalibrate your muscle memory for the way the menus work and so forth?
That's what a standard GUI API is for..."
Except... that's not what a standard API is for--
There actually is a (somewhat) standard drag'n'drop protocol....
Note that I say "protocol", rather than "API", and note that protocol is rather independant of API.
As noted at the XDND web-site, there are several APIs supporting the same protocol.
As for whether I can do drag'n'drop between applications written with different APIs: yes, I can--examples include doing drag'n'drop between Motif-based Netscape and GTK+-based GMC.
I believe that there are also versions of VI and Emacs that support drag'n'drop of text and images (GNU Emacs, under X, is not such a beast, but this does not stem from the mere fact that it uses a different API).
As for key-bindings....
Key-bindings have even less to do with the API than drag'n'drop does.
"I like both desktop environments, personally, but I don't like the separation like that. Is there anything we could do like that, other than have window manager/desktop environment/tk wars?"
0] help the GNOME/KDE/etc. teams make the environments' component tools all play nicely together, or...
1] help the wxWindows group improve/finish their ports.
Why does it matter whether unrelated projects use the same API or not?
You choose the GUI and API that you fid most pleasant, or that best suits your application.
If my application can interact with other applications in all of the important ways, why should I care what API the other guy is using? It doesn't affect me.
This sounds like another holy war.
Jeez. I use emacs. The guy next to me is using VIM. What do I care? I can still read and write each other's files, right?
I'll agree that there isn't a choice between different free compilers, and I'll agree that it is a *massive* effort to write a brand new compiler....
I'd really like answered: why do you want more compilers? Or, in other words: what do you hope to find that's different?
`cc' commands aren't really like `desktop' software, where you can completely change the UI, and be able to say, `I like this better because it has a friendlier UI'--mainly because it breaks compatibility with every other compiler and makefile and configure script in a big way.
Hm. If a different set of command-line arguments is all you want, it shouldn't be too hard to write a front end (just for when the user is manually using gcc) that converts from user-specific command-line-style to a native gcc command-line.
Having that said, the only other aspects of compilers that I can think of are the languages that they support, the platforms that they compile to and the quality of the output that they produce; in the first and second cases, it's really not so necessary to write an entirely new compiler-system, because you can write a front-end `compiler' for the C-compiler, or a back-end, or even just the assembler component. Hm.
I'm assuming that the AC was referring to the whole compilation system--the preprocessor, the compiler, the assembler, the linker..., rather than just the compiler....
Anyway, to the last point: performance:
Wanting a better-performing compiler is valid, regardless of how good GCC is (always try to make things better, eh?), but that really doesn't seem like a reason for maintaining two compilers--is the justification `some people want a low-quality compiler and some want a high-quality compiler'?
Actually..., that may be a good point (I rather like having a slow system to test things on, just because it makes differences in the qualities of algorithms so evident), but still not one that warrants two different compilers, because the compiler takes optimisation switches.
There might be specific types of algorithms or code-segments that one compiler is better at compiling, and so one could say `I use X when compiling type-x code, and I use Y when compiler type-y code', but, since we have the ability to do so, I'd still argue that it's better to fold all of the goodness into something like GCC.
Then, there are, of course... rewrites of GCC (ie: 1, 2).