It's not much unlike the GPL in that respect (the difference being that you can write proprietary software with Qt if you pay, and you can't do it at all with the GPL).
This isn't really true. Caldera uses the GPL extensively in just this way. They own the copyright for a lot of the stuff they produce, and if you want it under a non-GPL license, you have to pay them. This is nearly identical to the QPL.
The difference is that what Caldera does provides much more benefit to the community. You cannot use portions of Qt in a GPLed program because of the incompatible licenses. And you cannot make a purely free fork of Qt -- any extensions to Qt have to be distributed under some sort of license that allows proprietary use by Troll Tech (I don't remember the exact terms).
Caldera uses a symmetrical license -- it obeys the GPL, you obey the GPL, everyone has equal rights. But Troll is more equal than everyone else with Qt -- it can do whatever it wants with your patches to Qt, but you don't have the same rights. You can't say "this extension I wrote is only available to free software programs" -- and you probably don't want to, but they don't even give you the choice.
This could be more important if/when Qt moves to embedded or otherwise Abnormal environments. In an embedded environment, things are often statically linked and integrated. But if you want to integrate Qt into general graphical interface, you will have to give up a lot of the control of your code to Troll Tech. The same is true with the GPL, but in that case you are giving up a lot of control to the community, not a company. That's what Open Source/Free Software is all about: community. The QPL is one-way, centralized on Troll Tech.
Where have you been for the last decade? Perl killed shell scripting for non-trivial automation years ago.
So you've chsh -s/usr/perl ? I know I'd never do such a thing.
I spend a lot of time in the shell, writing what amounts to very small scripts (piping, substitution, etc) that never make it past the interactive command line. And sometimes, after writing the same thing many times, I make a script of it.
And it's so very easy to write a script, because I've been writing the same thing on the command line. The transition is nearly seemless. A shell is a direct connection to Un*x commands, with only a thin veneer of control structures and variables.
I'm sure there are interactive versions/frontends to perl, but I haven't personally seen them. bash is always pleasantly interactive, always present, nearly standard, has a low syntactic burden for its intended realm, and allows me to program interactively. (why would anyone want a non-interactive interpreted language? At least C has an excuse)
Why not created a domain where the pornographic sites are. Perhaps a.sex or a.xxx or whatever. Then they could at least have a better chance of blocking some traffic.
I don't think this would help much. Legitimate porn sites aren't the problem. Those are the sites you find if you are looking for them.
The real problem is sites you find when you aren't looking for them. These are mostly spammers -- email, usenet, search engines. Looking up "monkey" shouldn't give you porn sites -- but I've seen kids do just that and get 50% of the results as porn. If kids are getting pornographic email, parents aren't going to let them have email at all -- and I want children to be able to communicate. These are the problems.
Parents can't be expected to monitor their children's activity completely -- this simply isn't practical. Nor is it practical for schools.
However, I think filtering could be okay if it only targetted misleading sites, email, and posts. This might include pyramid-schemes (though education is much more important and effective here) but wouldn't include all porn, risque geocity sites, hate sites, or nearly anything based solely on content. Fraud is illegal, and filtering out fraudulent content doesn't harm anyone's first ammendment rights.
OTOH, these fraudulent sites are exactly the ones that are hardest to filter. Heuristic-based filtering is bound to make mistakes, and that's exactly the problem. Making it easy to bypass the filters is one possibility to counter this. It isn't really a problem for a child or adult to be able to bypass a filter if it requires extra action. Mostly children do the right thing, and adults should be allowed to bypass whatever they want.
I really think children should be able to do the wrong thing -- that's part of learning. But they shouldn't be able to do the wrong thing without trying. That's the valid argument for filtering, and denying that the problem exists isn't the right answer.
Hmmm... I don't know if it is a 'definition', but by 'First Order Object' I meant an object, defined as a specfic part of the language grammer, which has a parent of 'Object' and inherits from nothing else.
I don't see any particular advantage to having tuples -- or any other class -- directly inheriting from Object. There are a lot of shared functionality between tuples and lists, and even dictionaries.
The particular class inheritance isn't really a matter of functionality. In Smalltalk Integers don't even inherit directly from Object, nor True or False. I don't think that implies they aren't important to the language.
Even languages where 'everything is an object' like Python often do this as an optimization and/or to provide support for language features that rely on the first order object.
Almost every language provides some optimization for tuples. The only exceptions I can think of are Lisp languages, where lists are more important than tuples, and maybe some low-functionality languages like m4 (which hardly count).
Python does have some syntactic sugar for tuples, and I won't say that's unimportant. But I don't think that makes something quite first-order or not. (doesn't Icon have similar syntactic sugar?)
In Smalltalk you can do "#(1 2 3)" to make a tuple, or even "{x. y. z}" if you are using Squeak (which is the only Smalltalk I'm really familiar with). For other collections, you can use "#(1 2 3) as: Set" which will inline a Set into the code (as opposed to creating it at runtime). You can even do "{a. b}:= #(1 2)" in Squeak, though nobody uses it and for half the releases it's broken.
In Scheme and other Lisps lists are more important, but their functionality is probably more powerful, since they are used for everything (even the syntax). There's no unpacking for assignment, but then assignment is almost looked down on:-/
I don't think Python is the most of anything. That's not bad, but it's definately a language of refinement not revolution. The only really novel think, I think, is the indentation.
I can't quite decide what a first order object is... if someone has a good definition, I'd be curious to see it. But, from my intuition of what a first order object is, lots of languages are as powerful in this way as Python.
In Smalltalk, for instance, collections (of which tuples would only be a subset) are objects on par with anything else -- integers, booleans, etc. Collections and their associated functionality are one of my favorite parts of Smalltalk.
Though I haven't used them, my impression of APL and J (a successor) are that they allow manipulation of collections -- arrays and matrices -- superior to most languages.
And any Lisp treats lists as first-class objects, and usually vectors (equivalent to tuples and arrays) as well.
What's always struck me is how people could stand not to have collections as first-class objects. C with it's horrid pointer arithmetic, Tcl with it's disfunctional string/lists... ugh. Collections of objects are one of the fundamental parts of programming, right along with numbers and bytes. Every language should consider collections as a core part of the language.
Most languages don't allow the sort of implicit packing and unpacking of tuples that Python does (as in a, b = (1, 2)) -- though there are a number. I don't think there's anything Python does that some other language hasn't done before. Not to criticize Python for it. It's not wrong to learn from the past.
Debian is a bunch of.debs. If you install all of them, you get a Debian system. Using the rpm format wouldn't suddenly make that Debian system a Redhat system. And it wouldn't make a Redhat-oriented rpm compatible with the Debian system.
I get the impression this is already a problem with the various rpm-based systems. There are certain RPMs that will break a SuSE system, for instance, no?
Using RPM won't solve much. Alien already solves that problem. And, having used alien, I can see why that solution doesn't solve the real problems involved. It doesn't suddenly make RPMs compatible with a Debian system.
What I've been confused about is the things ports advocates never mention.
From what advocates say, it seems like the ports system makes building a system fairly straight-forward, but I don't know how it deals with changing a system.
Can you uninstall programs with make uninstall?
Does it recognize the problem that occurs when app A requires libfoo v5, and app B requires libfoo v4? What happens when you install app A? Does it upgrade libfoo and break app B?
I really don't know the answers to these questions. Ports seems like a very ad hoc system, which isn't a great way to ensure system integrity. But as I said, I don't really know.
Writing a tool to create one of many binary distribution formats is a waste of time. It makes far more sense for the free software community to use a single binary package utility.
If I want to install an.rpm on my Debian system, I can do so now. But it installs things in places they don't really belong and there are some other problems.
A single binary package doesn't really relate to the problem at hand. The problem at hand is: how can you install a program on different systems, so it is installed appropriately to each operating system? A single binary package only makes alien obsolete, but solves none of the difficult problems involved.
Autoconf simply edits makefiles. There is no common init file for package systems that could be used in the same way.
Editting makefiles is far more difficult than init files. Consider how long the init file for a package is, and the length of the makefiles for the same package? The makefile is always more complicated and more fragile.
Makefiles were solved first because that's the order in which things work -- programs are programmed, and only then are they worth installing. But it doesn't mean makefiles were easier.
Debian (.deb) packages contain more than just files and a list of dependencies. For one thing, the menus in your window managers are updated automatically.
This is where I think the difference between packages and policy gets fuzzy. The Debian menu system is as much a part of Debian Policy as it is part of the Debian Packaging System.
And you can't follow Debian Policy strictly without ending up with the Debian system. So these portable packages don't follow policy -- which is bad, and is why alien isn't The Answer. Or, they do follow policy by having all the information necessary for every OS/distribution on which they are installed. But then each author needs to know about the requirements of all the operating systems, and if the OS is changed ("innovated":) then the packages won't really be correct any longer.
I don't think there will be a magic bullet for packages until operating systems are so commoditized that there is effectively only one. And that's a long ways coming.
Thus, a new package can find out where it can install itself and how to link to everything it needs, without messing with system-level software. Not only that, but since the meta-information for everything is gonna be sitting right there, the software can not only resolve dependencies but also suggest configuration changes in its dependencies!
This has the same problem that all distributions have to deal with -- the combinatorial aspect of interdependancies and conflicts.
Which program/package controls which package? Which one Knows more about the others, and so has the wisdom to deal with installation? The problem I see in the Windows installation process is that each application thinks it's Right and does whatever it takes to make it work, even though that application is ignorant of what is necessary to make the entire system work.
I wouldn't trust any package to be too smart -- a centralized system (like an RPM database and all that infrastructure) is restrictive but can keep the system sane and make it possible to look in from the outside and figure things out. I don't see an ad hoc system (which is what you propose) capable of doing this.
Documentation is something most coders hate, but without the docs how the hell are we gonna encourage newbies to use our software?
It's not going to be with documentation. Honestly, how many users want to read documentation? How many of them see a fat manual and feel happy?
Making things automated and intuitive will be more important. Documentation will be essential to create the future gurus out of the raw material of newbies, but it won't make Linux ready for the masses. Not that making new gurus isn't essential...
Distributions and desktop environments are going to be the ones to make Linux more user friendly. Distibutions particularly, because a well-made distribution can make all the little pieces fit together automatically, where a desktop environment has a more limited involvement.
Re:A game as boring as EQ or AC
on
Anarchy Online
·
· Score: 1
I must admit I haven't seen or played Ultima Online. I only toyed with Everquest a little and heard a friend speak on his obsession more than I cared to listen to:-) From what you say, Ultima Online sounds a lot better than Everquest. My (mistaken) impression was that these various games were pretty similar.
Re:Shameless plug for a free version of this: MUQ
on
Anarchy Online
·
· Score: 2
I just spent the last several hours looking at this all, and I must say I'm very impressed. I didn't get the impression that MUQ was quite at the point of making real worlds/MUDS, but the infrastructure looks really good.
The documentation, I must say, is very good for the first public release. The author definately seems like he wants this to be used and understood by others. The docs put most systems to shame.
Also, compared to many open-source game efforts, this is the product of a very mature programmer. Nothing against the young and enthusiastic, but they make many mistakes that have been made before -- I know I would. For building a strong infrastructure this would not do. And MUQ is all about infrastructure. I think he mentioned that he was the original author of the Citadel BBS system -- so it should be apparent that he's been around a while now.
Re:A game as boring as EQ or AC
on
Anarchy Online
·
· Score: 2
Though I never tried any of them very long, those online games always stuck me as rather boring as well. I think the problem with them is that they are only a small step above Quake et. al. when it comes to doing constructive.
I think constructive games are much more fun -- games where you make something, or design something. Civilization has always been a favorite of mine because of this. In Quake you build nothing -- everything lasts only as long as you stay alive. In the RPG games you build your character, becoming more and more powerful.
But the worlds themselves are just as static as in Quake. They can't be changed, if you kill the creatures they all come back eventually, and it gives the feel that nothing ever accomplishes anything.
In a game where you could build fortresses, develop inter-player politics, etc., would be much more fun. I think the emphasis on 3D graphics has held back the genre. 3D graphics are fine and all, but are technically difficult and bandwidth-hungry. With tile graphics you would be able to work a lot harder on the other parts of gameplay.
As I remember it, the original NeXT interface didn't have any root menus, just the wharf.
I wouldn't be surprised that NeXT was forward-thinking when it came to hardware, since the hardware itself was always top-of-the-line (perhaps to a fault). The icons where pretty big (64x64, I think). The original screens were 4-color (black, white, two shades of gray) so that would explain the original color scheme (very grey). But they were big and fairly high resolution.
I don't think GNUStep/OpenStep/NeXTStep whatever is really going to ever be any sort of standard, IMHO. Nice interface, nice technology, but too far from mainstream interfaces.
I don't think the interfaces are a problem at all. NeXTStep isn't really all that novel in its interface -- basically a polishing of the Mac interface. Windows looks more like NeXT than Macs.
But that won't be the problem -- the biggest issue is, IMHO, Objective C. Now, I'm not saying anything bad about Objective C, but it's a new language to most people, and people get weird about that sort of thing. It doesn't have the hype behind it that Java does, the history and maturity of C, or the mainstream acceptance of C++. Too bad, it's better than all of them.
Well, Enlightenment isn't actually the official GNOME windowmanager -- it was the de facto standard for a while, but even that has changed as (it seems) Raster has been moving away from GNOME and in his own direction.
But, those things aside, GNOME and GNUStep aren't really related, even though they are both sponsered by GNU. GNOME was a reaction to KDE/Qt, and demanded much shorter-term success. GNUStep, because it was ambitious and a little monolithic, took a long time to get to a usable point. It actually preceded GNOME by several years, but development languished while the core developers worked on the basic functionality -- essentially writing the standard library for Objective C.
Ironically, while Window Maker is part of GNUStep, it doesn't use any of the GNUStep functionality, being written entirely in C (not Objective C). I guess this was done because the author (Alfred Kojima, I think) wanted to make it functional apart from GNUStep, and before GNUStep -- both of which have been accomplished.
But as a result, it's only a matter of policy that Window Maker is part of GNUStep, while I imagine the rest of GNUStep will be connected at more of an architectural level, being based on Objective C, the Foundation libraries, and all that.
I'm not sure, but I don't think the question was so much a matter of whether the code could be stolen right out -- that's an issue in all Free Software, but for the most part doesn't seem to be too big a problem.
The question seemed to me to be if it was possible to protect the code from being manipulated. If they have well-defined, open interfaces between everything with a high level of modularity, it might be possible for some person (but probably a company) to use many of these modules with some replaced by their proprietary modules. The product as a whole would be proprietary, though many of the pieces would not be. This would obviously be in violation of the spirit of the GPL.
The GPL does try to protect against this very thing. A GPL program cannot link -- even dynamically -- to anything less free than the GPL -- or, conversely, linking to a GPLed library can only be done by something that is GPLed. There is a (possibly dangerous) exclusion for system libraries -- but in a Win32 environment, that exclusion is obviously quite necessary as well.
It's not clear whether the GPL's protection would also would be true for other interfaces -- what is a shared library? Is a CORBA interface a form of shared library? Is it protected under the GPL? Other interfaces? I think this is the issue in question. The output of a GPLed program is specifically not covered under the GPL, but output and interface can be a fuzzy distinction at times.
Some people question whether you can protect an interface. That is, does fair use protect the use of all public interfaces? I believe the author of Ghostscript had these very same questions. You can read an interesting interview with him where he talks about these things and why he used a different license.
One thing you might do is to clarify your own interpretation of the GPL in this context. This is something Reiser did for ReiserFS -- and he got a lot of flack for it, because he was adding something the the GPL. But I think it makes sense, since Linus has made his (I think flawed) interpretation of the GPL in regard to binary-only modules, you shouldn't let that be seen as the de facto interpretation in regards to your software.
So someone could read your code, see a nifty idea/algorithm, and use it with impunity.
I don't think the GPL really tries to protect the ideas or algorithms. That's the sort of thing software patents address, and I don't anyone wants to propose that sort of solution.
Copyright pretty much protects the code itself, not the underlying idea behind it. It protects the expression -- you aren't violating copyright when you copy a plotline, after all, just when you copy the expression of that plotline.
Thank goodness -- or else all sitcoms would be horribly mired in copyright law.
This would open up a new world of spamming, the crack spam. If you could crack a businesses email delivery system, send a million USPS.gov emails advertising your get rich quick scheme, and charge it to the business you cracked into, who is going to pay the $100,000+ charge you just racked up. Investigators would obviously know where to start looking, but if you were good enough at covering your tracks and kept your mouth shut, they wouldn't have any evidence and they couldn't do anything.
It wouldn't happen. The legal controls on the USPS are pretty stiff. What good would advertising a get-rich-quick-scheme be if you couldn't tell people how to contact you or something related to you? Then it wouldn't be hard to track you down.
The punishment for sending mail like this wouldn't be $50 an email or anything like the current anti-spam laws. You'd be tampering with the USPS, which has specific laws covering it, and you'd almost certainly go to jail.
Even sending fraudulent mail with the USPS is specifically covered in laws, so even without cracking the system, simply sending pyramid-scheme mail is illegal, and those laws are enforced.
As someone else pointed out, in some cases people will give up charging royalties on their patent if there is a great deal of incentive in having a part in the standard. Of course, this isn't always enough motivation, but maybe that could be changed.
How about bidding? Bidding is done in all sorts of situations, and where institutions are involved (like in a large corporation, a government, or a standards body) and there isn't bidding, it's often a sign of corruption, because of the conflict of interests when chosing an implementor. As many of the people defining standards are employed in their respective industries, the potential for conflict of interest should be taken very seriously (though I fear it is not).
I can see bidding work well with something like sound compression. The standards body says: we'll pay a single fee to a company for their sound compression, and they will in turn give up all future rights to charge royalties on that patent. You could weight the quality of implementations against the bid, so a compressor that was 10% worse than another would have to underbid by at least 10%. (deciding on "10% worse" would have to be somewhat subjective, but it could be done)
There is a great deal of incentive -- if the standard becomes widely implemented (all the more likely because patents don't restrict it) and a company's compression isn't part of the standard, it's potential profits are negligable.
This could bring competition back into the highly anti-competitive realm of patents. It could also keep patent-holders from robbing us all blind. However, it requires some capital on the part of the standards bodies (not impossible) and some will on the part of the standard-makers (again, not impossible). But altogether, there's just too much money being made (stolen) to imagine it could change easily.
IMHO while this article questioned nearly all of Corel's latest Linux moves, it ignored virtually all of the larger issues which make Corel a good member of the Linux community
I don't think Red Herring was really talking about being a good member of any community -- I don't think they really cared. It's a site for investors, and Corel could be a bunch of cutthroat bastards and get a good review, if they were a bunch of profitable bastards.
Gopher wasn't the web without graphics. Gopher was a hiarchy of text files, which could be accessed remotely. It didn't have hyperlinks. It wasn't a "web" of anything. It was a bunch of nodes. And, as such, it worked fine, but it wasn't quite enough to be revolutionary.
Crossreferencing is far more important to the spread of the web than graphics, IMHO. With crossreferencing, adding something to the web increases the value of all the web, not just your site. Instead of the web being just someplace where you can put content to make it public, the web is a whole system. That, and the web came to be around the time when people started to be able to access it in large numbers.
Graphics aren't unimportant, but they weren't even much of an option when gopher was around, and they weren't very exciting when the web was starting either.
Slashdot Mirror
The difference is that what Caldera does provides much more benefit to the community. You cannot use portions of Qt in a GPLed program because of the incompatible licenses. And you cannot make a purely free fork of Qt -- any extensions to Qt have to be distributed under some sort of license that allows proprietary use by Troll Tech (I don't remember the exact terms).
Caldera uses a symmetrical license -- it obeys the GPL, you obey the GPL, everyone has equal rights. But Troll is more equal than everyone else with Qt -- it can do whatever it wants with your patches to Qt, but you don't have the same rights. You can't say "this extension I wrote is only available to free software programs" -- and you probably don't want to, but they don't even give you the choice.
This could be more important if/when Qt moves to embedded or otherwise Abnormal environments. In an embedded environment, things are often statically linked and integrated. But if you want to integrate Qt into general graphical interface, you will have to give up a lot of the control of your code to Troll Tech. The same is true with the GPL, but in that case you are giving up a lot of control to the community, not a company. That's what Open Source/Free Software is all about: community. The QPL is one-way, centralized on Troll Tech.
I spend a lot of time in the shell, writing what amounts to very small scripts (piping, substitution, etc) that never make it past the interactive command line. And sometimes, after writing the same thing many times, I make a script of it.
And it's so very easy to write a script, because I've been writing the same thing on the command line. The transition is nearly seemless. A shell is a direct connection to Un*x commands, with only a thin veneer of control structures and variables.
I'm sure there are interactive versions/frontends to perl, but I haven't personally seen them. bash is always pleasantly interactive, always present, nearly standard, has a low syntactic burden for its intended realm, and allows me to program interactively. (why would anyone want a non-interactive interpreted language? At least C has an excuse)
The real problem is sites you find when you aren't looking for them. These are mostly spammers -- email, usenet, search engines. Looking up "monkey" shouldn't give you porn sites -- but I've seen kids do just that and get 50% of the results as porn. If kids are getting pornographic email, parents aren't going to let them have email at all -- and I want children to be able to communicate. These are the problems.
Parents can't be expected to monitor their children's activity completely -- this simply isn't practical. Nor is it practical for schools.
However, I think filtering could be okay if it only targetted misleading sites, email, and posts. This might include pyramid-schemes (though education is much more important and effective here) but wouldn't include all porn, risque geocity sites, hate sites, or nearly anything based solely on content. Fraud is illegal, and filtering out fraudulent content doesn't harm anyone's first ammendment rights.
OTOH, these fraudulent sites are exactly the ones that are hardest to filter. Heuristic-based filtering is bound to make mistakes, and that's exactly the problem. Making it easy to bypass the filters is one possibility to counter this. It isn't really a problem for a child or adult to be able to bypass a filter if it requires extra action. Mostly children do the right thing, and adults should be allowed to bypass whatever they want.
I really think children should be able to do the wrong thing -- that's part of learning. But they shouldn't be able to do the wrong thing without trying. That's the valid argument for filtering, and denying that the problem exists isn't the right answer.
The particular class inheritance isn't really a matter of functionality. In Smalltalk Integers don't even inherit directly from Object, nor True or False. I don't think that implies they aren't important to the language.
Almost every language provides some optimization for tuples. The only exceptions I can think of are Lisp languages, where lists are more important than tuples, and maybe some low-functionality languages like m4 (which hardly count).Python does have some syntactic sugar for tuples, and I won't say that's unimportant. But I don't think that makes something quite first-order or not. (doesn't Icon have similar syntactic sugar?)
In Smalltalk you can do "#(1 2 3)" to make a tuple, or even "{x. y. z}" if you are using Squeak (which is the only Smalltalk I'm really familiar with). For other collections, you can use "#(1 2 3) as: Set" which will inline a Set into the code (as opposed to creating it at runtime). You can even do "{a. b} := #(1 2)" in Squeak, though nobody uses it and for half the releases it's broken.
In Scheme and other Lisps lists are more important, but their functionality is probably more powerful, since they are used for everything (even the syntax). There's no unpacking for assignment, but then assignment is almost looked down on :-/
I don't think Python is the most of anything. That's not bad, but it's definately a language of refinement not revolution. The only really novel think, I think, is the indentation.
In Smalltalk, for instance, collections (of which tuples would only be a subset) are objects on par with anything else -- integers, booleans, etc. Collections and their associated functionality are one of my favorite parts of Smalltalk.
Though I haven't used them, my impression of APL and J (a successor) are that they allow manipulation of collections -- arrays and matrices -- superior to most languages.
And any Lisp treats lists as first-class objects, and usually vectors (equivalent to tuples and arrays) as well.
What's always struck me is how people could stand not to have collections as first-class objects. C with it's horrid pointer arithmetic, Tcl with it's disfunctional string/lists... ugh. Collections of objects are one of the fundamental parts of programming, right along with numbers and bytes. Every language should consider collections as a core part of the language.
Most languages don't allow the sort of implicit packing and unpacking of tuples that Python does (as in a, b = (1, 2)) -- though there are a number. I don't think there's anything Python does that some other language hasn't done before. Not to criticize Python for it. It's not wrong to learn from the past.
I get the impression this is already a problem with the various rpm-based systems. There are certain RPMs that will break a SuSE system, for instance, no?
Using RPM won't solve much. Alien already solves that problem. And, having used alien, I can see why that solution doesn't solve the real problems involved. It doesn't suddenly make RPMs compatible with a Debian system.
From what advocates say, it seems like the ports system makes building a system fairly straight-forward, but I don't know how it deals with changing a system.
Can you uninstall programs with make uninstall?
Does it recognize the problem that occurs when app A requires libfoo v5, and app B requires libfoo v4? What happens when you install app A? Does it upgrade libfoo and break app B?
I really don't know the answers to these questions. Ports seems like a very ad hoc system, which isn't a great way to ensure system integrity. But as I said, I don't really know.
A single binary package doesn't really relate to the problem at hand. The problem at hand is: how can you install a program on different systems, so it is installed appropriately to each operating system? A single binary package only makes alien obsolete, but solves none of the difficult problems involved.
Editting makefiles is far more difficult than init files. Consider how long the init file for a package is, and the length of the makefiles for the same package? The makefile is always more complicated and more fragile.Makefiles were solved first because that's the order in which things work -- programs are programmed, and only then are they worth installing. But it doesn't mean makefiles were easier.
And you can't follow Debian Policy strictly without ending up with the Debian system. So these portable packages don't follow policy -- which is bad, and is why alien isn't The Answer. Or, they do follow policy by having all the information necessary for every OS/distribution on which they are installed. But then each author needs to know about the requirements of all the operating systems, and if the OS is changed ("innovated" :) then the packages won't really be correct any longer.
I don't think there will be a magic bullet for packages until operating systems are so commoditized that there is effectively only one. And that's a long ways coming.
Which program/package controls which package? Which one Knows more about the others, and so has the wisdom to deal with installation? The problem I see in the Windows installation process is that each application thinks it's Right and does whatever it takes to make it work, even though that application is ignorant of what is necessary to make the entire system work.
I wouldn't trust any package to be too smart -- a centralized system (like an RPM database and all that infrastructure) is restrictive but can keep the system sane and make it possible to look in from the outside and figure things out. I don't see an ad hoc system (which is what you propose) capable of doing this.
Making things automated and intuitive will be more important. Documentation will be essential to create the future gurus out of the raw material of newbies, but it won't make Linux ready for the masses. Not that making new gurus isn't essential...
Distributions and desktop environments are going to be the ones to make Linux more user friendly. Distibutions particularly, because a well-made distribution can make all the little pieces fit together automatically, where a desktop environment has a more limited involvement.
I must admit I haven't seen or played Ultima Online. I only toyed with Everquest a little and heard a friend speak on his obsession more than I cared to listen to :-) From what you say, Ultima Online sounds a lot better than Everquest. My (mistaken) impression was that these various games were pretty similar.
The documentation, I must say, is very good for the first public release. The author definately seems like he wants this to be used and understood by others. The docs put most systems to shame.
Also, compared to many open-source game efforts, this is the product of a very mature programmer. Nothing against the young and enthusiastic, but they make many mistakes that have been made before -- I know I would. For building a strong infrastructure this would not do. And MUQ is all about infrastructure. I think he mentioned that he was the original author of the Citadel BBS system -- so it should be apparent that he's been around a while now.
I think constructive games are much more fun -- games where you make something, or design something. Civilization has always been a favorite of mine because of this. In Quake you build nothing -- everything lasts only as long as you stay alive. In the RPG games you build your character, becoming more and more powerful.
But the worlds themselves are just as static as in Quake. They can't be changed, if you kill the creatures they all come back eventually, and it gives the feel that nothing ever accomplishes anything.
In a game where you could build fortresses, develop inter-player politics, etc., would be much more fun. I think the emphasis on 3D graphics has held back the genre. 3D graphics are fine and all, but are technically difficult and bandwidth-hungry. With tile graphics you would be able to work a lot harder on the other parts of gameplay.
I wouldn't be surprised that NeXT was forward-thinking when it came to hardware, since the hardware itself was always top-of-the-line (perhaps to a fault). The icons where pretty big (64x64, I think). The original screens were 4-color (black, white, two shades of gray) so that would explain the original color scheme (very grey). But they were big and fairly high resolution.
But that won't be the problem -- the biggest issue is, IMHO, Objective C. Now, I'm not saying anything bad about Objective C, but it's a new language to most people, and people get weird about that sort of thing. It doesn't have the hype behind it that Java does, the history and maturity of C, or the mainstream acceptance of C++. Too bad, it's better than all of them.
But, those things aside, GNOME and GNUStep aren't really related, even though they are both sponsered by GNU. GNOME was a reaction to KDE/Qt, and demanded much shorter-term success. GNUStep, because it was ambitious and a little monolithic, took a long time to get to a usable point. It actually preceded GNOME by several years, but development languished while the core developers worked on the basic functionality -- essentially writing the standard library for Objective C.
But as a result, it's only a matter of policy that Window Maker is part of GNUStep, while I imagine the rest of GNUStep will be connected at more of an architectural level, being based on Objective C, the Foundation libraries, and all that.
The question seemed to me to be if it was possible to protect the code from being manipulated. If they have well-defined, open interfaces between everything with a high level of modularity, it might be possible for some person (but probably a company) to use many of these modules with some replaced by their proprietary modules. The product as a whole would be proprietary, though many of the pieces would not be. This would obviously be in violation of the spirit of the GPL.
The GPL does try to protect against this very thing. A GPL program cannot link -- even dynamically -- to anything less free than the GPL -- or, conversely, linking to a GPLed library can only be done by something that is GPLed. There is a (possibly dangerous) exclusion for system libraries -- but in a Win32 environment, that exclusion is obviously quite necessary as well.
It's not clear whether the GPL's protection would also would be true for other interfaces -- what is a shared library? Is a CORBA interface a form of shared library? Is it protected under the GPL? Other interfaces? I think this is the issue in question. The output of a GPLed program is specifically not covered under the GPL, but output and interface can be a fuzzy distinction at times.
Some people question whether you can protect an interface. That is, does fair use protect the use of all public interfaces? I believe the author of Ghostscript had these very same questions. You can read an interesting interview with him where he talks about these things and why he used a different license.
One thing you might do is to clarify your own interpretation of the GPL in this context. This is something Reiser did for ReiserFS -- and he got a lot of flack for it, because he was adding something the the GPL. But I think it makes sense, since Linus has made his (I think flawed) interpretation of the GPL in regard to binary-only modules, you shouldn't let that be seen as the de facto interpretation in regards to your software.
Copyright pretty much protects the code itself, not the underlying idea behind it. It protects the expression -- you aren't violating copyright when you copy a plotline, after all, just when you copy the expression of that plotline.
Thank goodness -- or else all sitcoms would be horribly mired in copyright law.
And, relatedly, do you see places where MS seemed to plan to make DOS better, but instead let it languish while they worked towards Windows?
The punishment for sending mail like this wouldn't be $50 an email or anything like the current anti-spam laws. You'd be tampering with the USPS, which has specific laws covering it, and you'd almost certainly go to jail.
Even sending fraudulent mail with the USPS is specifically covered in laws, so even without cracking the system, simply sending pyramid-scheme mail is illegal, and those laws are enforced.
How about bidding? Bidding is done in all sorts of situations, and where institutions are involved (like in a large corporation, a government, or a standards body) and there isn't bidding, it's often a sign of corruption, because of the conflict of interests when chosing an implementor. As many of the people defining standards are employed in their respective industries, the potential for conflict of interest should be taken very seriously (though I fear it is not).
I can see bidding work well with something like sound compression. The standards body says: we'll pay a single fee to a company for their sound compression, and they will in turn give up all future rights to charge royalties on that patent. You could weight the quality of implementations against the bid, so a compressor that was 10% worse than another would have to underbid by at least 10%. (deciding on "10% worse" would have to be somewhat subjective, but it could be done)
There is a great deal of incentive -- if the standard becomes widely implemented (all the more likely because patents don't restrict it) and a company's compression isn't part of the standard, it's potential profits are negligable.
This could bring competition back into the highly anti-competitive realm of patents. It could also keep patent-holders from robbing us all blind. However, it requires some capital on the part of the standards bodies (not impossible) and some will on the part of the standard-makers (again, not impossible). But altogether, there's just too much money being made (stolen) to imagine it could change easily.
Crossreferencing is far more important to the spread of the web than graphics, IMHO. With crossreferencing, adding something to the web increases the value of all the web, not just your site. Instead of the web being just someplace where you can put content to make it public, the web is a whole system. That, and the web came to be around the time when people started to be able to access it in large numbers.
Graphics aren't unimportant, but they weren't even much of an option when gopher was around, and they weren't very exciting when the web was starting either.