the DEMOLITION MAN (1993) quote: -------- Lenina Huxley: [T]aco Bell was the only restaurant to survive the Franchise Wars. John Spartan: So? Lenina Huxley: So, now all restaurants are Taco Bell. --------
and "E.T. the Extra Terrestrial" (1982) key scene where the film's main human character, 9-year-old Elliott, lured E.T. of the woods with Reese's Pieces
The main reason Sawfish 2.0 sucks is that no-one is working on it right now. It's based on the old GTK+ architecture and despirately needs a rewrite. Metacity is what GNOME (at least Sun GNOME) will ultimately use. It's currently more limitted than Sawfish, but it's really great. Try it out!
As for the 2 panel quirks, please report the bug to either GNOME or Ximian (who's going to release Ximian GNOME 2.0 soon). It should be *really* easy to fix. It sounds like a bug that no-one noticed. If you're quick, it might end up in the next Ximian or GARGNOME update.
> > Ignored release notes > > Ignored Various READMES > > Ignored known gotchas > Doesn't exactly sound like a ready for the > desktop product to me.
These are installation issues, not usage features. If you try to install MacOSX on the original Mac or on the PC because you didn't read the release notes, you'd get similar problems. You'd also get similar problems if you automatic upgrade from Windows 98 to Windows 2000 without checking if Windows 2000 supports the new hardware.
If you don't want to set it up yourself correctly, you have to do some reading. If you don't want to set it up yourself, wait for Ximian or your distribution to set it up for you.
What counts is, how does it behave when you install it correctly? That question wasn't answered since the system was not installed correctly. GIGO applies as always.
Aren't there laws against dumping? http://www.investorwords.com/d4.htm#dump ing
All companies sell below cost from time to time to clear inventory and once and a while they sell things at or below cost for limited promotional periods. But when losses are expected to be extended for long periods of time so as to hurt the competition, you have a clear case of dumping.
IANAL, so I don't know if the U.S. has domestic dumping laws, but they definitely have dumping laws on exports, as do many other countries. This has the beginnings of a very strong international case against Microsoft.
It doesn't necessarily mean it's bad news. It may even be good news.
When Eazel died, Nautilus development didn't die. Instead, it expanded and resulted in a really nice, more focused and componentized part of GNOME. Why? Becuse Nautilus now grows in the direction the community wants, not in the direction that the Eazel wanted, so business model-related features/bloat and GNOME-duplicated functionality were stripped away.
If you feel strongly about eCos, set up a CVS on sourceforge or savannah.gnu.org and see if anyone on the Debian mailing list is interesting in porting Debian to eCos (like they do for HURD, FreeBSD, Linux, and Win32 (although this port is *really* basic)). Or submit an "Ask Slashdot" call for developers and see who is interested. Either way, the source gives you a lot of power to control your OS choice.
Definitely. I've worked on both Unix and Windows. Windows "knowledge" goes out of date very quickly since every year or two the old API and UI is put in "maintenance mode" or completely dropped. In Unix, things are more stable.
Suppose you have a programmer in 1992 with 3 years experience and transported him/her to 2002. If that programmer was a Windows programmer, he'd have a hard time finding a job today and have a hard time adapting. If that programmer was a Unix programmer, he shouldn't find it too difficult to find a job or adapt to Linux today.
It's not that Unix hasn't changed much, it's just that most of the changes in Unix are not gratuitous. Technologies are more modularized and centralized and technical advances tend to build on established technologies. Technology and experience are investments so you want to maximize their returns.
In Windows, technology is fashion. It changes regularly and is dumped when it's no longer a buzzword. (Take a look at all the unrelated and obsoleted Windows database APIs that were introduced in the last 10 years.)
For an example of this difference, take a look at the Linux kernel and the Windows base OS. In Linux, nearly every new concept seems to want to use either the mmap model or the "everything is a file" model and follows common initialization and update APIs. In Windows, every new concept requires a new data structure with new APIs and new initialization and update APIs. There's a lot more to learn and programming on Windows tends to be a lot more complicated on Windows.
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 2, Informative
Not really. GNOME's GConf works like a database (installable schemas with defaults) with any back end you want (XML, LDAP, Postgre, raw files). It's only used for configuration (e.g. user preferences) not anything critical, so you can blow it away or damage it and your system will return to reasonable defaults. You should also be able to share them between different installations, and have a registry chain so that defaults can be maintained on a central server and users can make local changes on their servers. It also has notifications so you can be notified if a specific key changes. With notifications, there's no need to restart your application (or server) just so that the new settings can take place (no reboots either!).
And herein, IMHO, lies the single biggest weakness in XP. In all the focus on passing unit tests (which are written first) and constantly refactoring, they have deliberately lessened the focus on a clean, maintainable design, and left it essentially to chance. If your development team consists purely of top-10% programmers who work well together, then certainly they will "refactor mercilessly" and maintain/develop a tidy design. However, most project teams don't, and in my experience will be "at the mercy of refactoring" instead.
Yes. Unit tests alone don't solve the problem which is why you need to combine it with a few other practises:
customer (even virtual customer) active involvement of clear incremental non-technical specifications. These specification must also be approved by programmers on technical grounds.
short life cycles (2 weeks or so) and incremental changes.
Other practises like pair programming (i.e. continuous online code reviews and design sessions) also help ensure better quality and ensure that everyone is familar with the code.
Customer involvement ensures that you're actually doing what you're supposed to be doing. Unit tests (which may include complexity measurement tests) ensure that your changes don't break anything on technical grounds (remember complexity measurements can also be unit tests). Forcing short cycles ensures that if there are problems, they're found out early. When a problem does occur (Agile methodologies assume they will), you and the customer can negotiate the appropriate solution. That six month scenerio isn't really possible. If a major architectural change is required, it needs to be broken up into manageable increments that can be done in parallel to feature implementation.
Of course, no methodology is a panacea. You can write FORTRAN-like code in any language, including Java. But Agile methodologies tend to expose the problems sooner so you can deal with them. Bad practises tend to get weeded out early and dealt with.
> In fact, I can see some would even argue that > XP hinders fixing crappy code (reasoning on > request, but I'm not going to feed the trolls > uninvited:-)).
Sure. One key part of XP is the ability to write good unit tests. As long as your unit tests are good, you can be comfortable in changing your code quickly. If the code is crappy, the code won't pass the unit tests, and you won't be able to change it as easily.
In this case, the only way I see that XP can be applied properly is to define a set of test cases that give the results that the crappy code is generating -- even if it's wrong. You would refactor the code until it became good code that gave crappy results, then write other test cases for good results and then evolve the code until it became good code that gave good results. While all this is going on, you need to be able to add new features and fix old bugs and possibly provide some backwards compatibility to reproduce the crappy behaviour since some people might depend on it.
Depending on the size of the project, the installed base, how much time you have to work on it, and the evolution speed of the project, it may be easier and better to rewrite from scratch and introduce a new product that is mostly like the original product.
It's definitely better to get things right the first time.
"Don't run MS Windows" doesn't necessarily mean "Run RedHat Linux 7.3 on the Intel". It means, run anything else. If we have a diverse ecosystem: * MS Windows 2000 * MS Windows NT * MS Windows 98 * Other MS Windows * MacOSX * MacOS * RedHat Linux 7.3 on i386 * RedHat Linux 7.2 on i386 * RedHat Linux 6.2 on i386 * RedHat on other platforms * SuSE current on i386 * SuSE current on PowerPC * SuSE previous version on any platform * Debian current on i386 * Debian current on PowerPC * Debian previous version on any platform * Gentoo current on i386 * Gentoo on other platforms * Any other Linux on any other platforms * FreeBSD current on i386 * FreeBSD current on PowerPC * FreeBSD previous version on any platform * OpenBSD current on i386 * OpenBSD current on PowerPC * OpenBSD previous version on any platform * HURD on any platform * Plan9 on any platform * QNX on any platform * (this list was really abbreviated, but you get the picture)
with diverse window management (KDE, GNOME, MacOSX, Win32, GNUstep, Berlin, Plan9, Raw X,....)
and no standard office environment (with proper interoperability) like OpenOffice, KOffice, GNOME Office, Hancomm Office, Gobe Office, WordPerfect, Raw XML, Latex,...
and a security default setup in the OS and applications where you rarely need to be "root",
you get an ecosystem where it's extremely difficult (if not impossible) to write viruses that spread quickly and effect everyone.
Or you're a terrorist or a member of a hate group or you want to plot revenge on someone and you want to find out as much about a class of people so you can target your attacks more effectively.
Would you rather penetrate MI6? Or the Department of Work and Pensions?
> I'm not saying I distrust any podunk agency. > I'd much rather not particularly need to. > Desperately. > --Dan
> Uniquely Restrictive. Break it down. It is > restrictive in that it imposes restrictions.
It doesn't impose any restrictions that aren't available in copyright law. If you ignore the GPLed license on some software, you're free to use it, just like GPLed software. If you want to distribute that software, you can't because of copyright law. The GPL gives you *permission* to distribute the software if you do certain things. So the GPL is "Uniquely Permissive", *not* "Uniquely Restrictive".
> The most important restriction (as noted here, > there, elsewhere, and everywhere) is that if > you use some GPL code, the whole package has to > be GPL.
No on many accounts.
If you use a GPLed application but don't link to it, you can freely distribute it. Microsoft distributes GCC with their Unix compatibility layer and they definitely don't release their software.
Also, if you read the license, you'll see that you can use and even link GPLed software to a non-GPLed application. You can't, however, distribute that application.
It's clear that you don't understand I don't have the skill to make you understand, so I'll stop here.
But for the record: * programs don't do anything either. They are an expression of an idea. Machines that evaluate these ideas actually do things. * mathematical proofs are computer programs that evaluate to true of false (many can be directly translated to Prolog) * but the above is beside the point. The creation of mathematical proofs is every much a craft as the creation of computer programs and the impact of the resulting work is often more profound than any computer program (which will be obsolete in 10 years anyway). But mathemeticians share techics and results because there is value to the sharing. * Newton said nothing about morality. He simply said, in a round about way, that there is value in sharing the expression of ideas because they tend to build on each other. There's nothing to retract and you must believe it's true because otherwise you wouldn't be wasting your time reading posts and you certainly wouldn't be trying to share your ideas with me.
That's pretty much all I have to say. If you wish to have the last word, you may. I won't reply back, no matter what you say.
> Computer programs are constructs. They are > built from raw materials (bits, at the lowest > level; instructions for the more abstractly > minded) and perform a function. They are more > like machines than they are like something from > math or the sciences.
Just because something can be modelled by a machine, doesn't mean that it is a machine. As I've said, the mathematical proof of the 4 colour problem can be modelled by a machine (I could give you the schematics within a few months). Give me a decade and I can model Fermat's last theorem too (yes it is possible, but it's really complicated).
You should also know that any computer program can be modelled with mathematics.
> The constituents of the sciences and of > mathematics aren't crafted things; they're > discoveries of principles, relations, or facts.
The creation of a mathematical proof is very similar to the creation of a computer program. Neither are discoveries. Robinson's Non-standard Analysis is a proof in point. It involves extending regular mathematics in a way that cannot be discovered, because neither the statement "Robinson's Non-standard Analysis is false" nor "Robinson's Non-standard Analysis is true" contradict mathematics. It's something outside math, yet there is a useful bridge between regular math and Robinson's invention that allows you to do things and discover things in regular math much easier than you would have otherwise.
> The argument, which you advocated, that > software should be shared like scientific > knowledge just doesn't hold any water.
There you go again with the "should". I say it gains value through sharing. There is no moral imperative to share. Read again.
> First of all, you are clearly mistaken if you > consider natural resources and crafted things > to be morally and economically equivalent.
Huh? You brought morality into this, not me. Take a look at both my reply and the post you replied to. It's clear you didn't read my post.
> You're trying to say that source code is > abstract knowledge, and should be shared so > that others may learn from it. . That's > bullshit. Source code is a crafted, constructed > thing.
Nope. Read what I said. I said that *you* lose the advantages of input and feedback, so it's a good idea for you to share.
But as a side note, do you really think that abstract knowledge isn't crafted? Newton's works didn't just appear out of thin air. It took time, patience, ingenuity, and craftmanship. Yes craftmanship. Mathemeticians pride themselves on esthetics as least as much as computer scientists, if not moreso. It's not enough to solve a problem, the solution must be beautiful. The 4 colour problem was proved correct by brute force enumeration of all the posibilities. Mathemeticians still don't consider it to be solved because it doesn't have a proof crafted for it.
And if you think that a mathematical proof can't be as complicated as a program, I suggest you look at the proof of Fermat's last theorem.
And do you really think that crafted things are 100% independent and don't owe their inspiration to other crafted things? Most novelists an song writers will tell you that their work is inspired by and includes parts of the styles of other writers and musicians.
The difference between a natural resource and something that requires human effort to create is only a matter of scarcity.
If you had to create your own water from oxygen and hydrogen, or create your own air by converting carbon dioxide into oxygen and carbon you wouldn't think about customizing the available water and air with scents or flavours or integrating them into different utilities. You'd think about producing it (through human effort) and hoarding it.
Conversely, if free software were abundant, you won't think about the cost of producing it, you'd think about customization, bug fixing, and system integration.
The word abundant is the key. *If* free software dominated the economy, it would be abundant, wouldn't it? That's why the whole "If all software were free, programmers would lose their jobs" argument is bogus. Programmers would still find programming jobs, just in different programming jobs (see above). Of course, if free software doesn't have the power to dominate the economy, this argument would disappear, but then so would the fears about it dominating.
Now if you think of an idea and you don't want to share, that's fine. It's your loss as much as mine. You'd be losing all the valuable input we could provide you and you'd be losing the opportunity to increase your reputation and thus employability and the good will of customers.
Keep in mind that perhaps your idea isn't as big a contribution as you believe. Newton said, "If I had seen so far, it is because I stood on the shoulders of gaints." Newton's contributions are by no means insignificant, but he recognized that his contributions builded on a large body of other contributed work that was far larger than his own ideas. *Because* those other ideas were abundant and freely available, he was able to do great things himself. Never mind that it cost effort to produce those ideas.
I don't see how this could be morally objectionable.
> The software economy would collapse, and > hundreds of thousands of people in the US alone > would be out of work.
Imagine a world where air, water, and sunlight were free. Imagine the economic nightmare. If water were free then all the bottled water producers, utility companies, canteen makers would go out of business. If air were free, all the air purification systems, air conditioners, perfume manufacturers would go out of business. If sunlight were free, all the lamp makers, light bulb makers, flashlight makers, and candle makers would go out of business.
Of course, this isn't what's happened, at least in my part of the world.
Why?
Because even free things need packaging, customization, integration, bugetting, and quality assurance and because it's free, the demand for things increase dramatically. Take water, for instance. If producing water were expensive, people would not need garden hoses because they would not be watering their lawns. They would certainly not use it in water engines and fire hydrants, water cooling jackets, water guns, fountains, and bath products because these things would be too expensive to be useful.
One good thing about this is that the Linux Standards base version 2.0 is now a lot easier. It only has to deal with Red Hat (and Mandrake which tries to be a more or less superset of Red Hat), United Linux, and Debian. This means that a lot more can be standardized.
The GPL makes a guarentee that the software in question will have it's source sharable for the lifetime of the software and ensures that any investment you make in GPLed software won't be closed off and resold by someone else who don't want to share.
Could a license be made that allows this to happen with patents. In particular: * This license in irrrevocable * This license is freely licensed for GPLed software * This license is freely licensed for all free software subject to the condition that: 1. The software is not linked to non-free software 2. If the software contains any patents, those patents must be freely licensed to any free software.
First of all, I think that the license generator is an excellent idea. Artists and programmers are not license lawyers, yet they need to deal with this issue. A site devoted to the commons is a great asset and generating easy to understand license descriptions is important.
However I do have a few nitpicks and suggestions:
* Some of the choice seem contradictory. For instance, someone may choose to have a no-derived works and copyleft. There needs to be a way of sorting this out.
* Some of the choices seem ambigious. Is copyleft the same as copyleft+attribution? Are either compatible with the GPL? Novel's original free software license was copyleft, but it was GPL incompatible because Novel's license had stricter licensing terms.
* There are several other variations of licenses that are not included that people find important. For instance, I may not mind if my work is quoted verbatum in a larger work or I may allow annotations or even deletions, so long as they are made explicit. Or I may allow changes to my work but all changes must be given to the public. Or they may wish their work to become licensed under a freer license (e.g. public domain, GPL, BSD) after a certain period of time so they can make money on it first. For an interesting look at a few more, take a look at:
http://www.panix.com/~kingdon/licenses.html I think that there are no more than 15 main characteristics that distinguish between most source available licenses. classifying licenses along these lines would really help sort out what each license means. It's sad that licenses are more made for lawyers, than for the people who use them.
* Relating to the above point, it would be desirable to be able to use the 15 main characteristics to not only define a license but also to look at commonly used licenses that are close to this one. For instance, there may be a license that has 3 of the 4 characteristics you consider most important. If you want users of your work to feel comfortable with your license, you'd more than likely choose a popular license, even if you have to give up on a few points. This feature allows you to reduce the license fragmentation.
* Finally, I'd suggest that you integrate the Librock License Awareness System into your web site:
http://www.mibsoftware.com/librock/lidesc/index.ht ml
http://www.mibsoftware.com/librock/lidesc/user.htm 1. This software allows you to determine if two licenses are compatible and may be combined into a greater work. It's best to be aware of licensing issues before you combine source code since afterwards it may take more pain to become compliant than you wish. 2. Also also importnat when you wish to choose your license since it can alert you to unintended consequences. For instance, if you choose a license with the clause "you are free to modify this work but may only be distribute it or any derivatived work non-commercially" (i.e. an Alladin-like license), you may be upset that it's not GPL compatible. If GPL compatibility is important to you but you're not willing to give up your license on your current work (you don't want people making money redistributing your work before you have a chance to), you may be okay about making it GPL compatible after a certain amount of time or you may make other concessions.
Slashdot Mirror
If you look at:
the DEMOLITION MAN (1993) quote:
--------
Lenina Huxley: [T]aco Bell was the only restaurant to survive the Franchise Wars.
John Spartan: So?
Lenina Huxley: So, now all restaurants are Taco Bell.
--------
and "E.T. the Extra Terrestrial" (1982) key scene where the film's main human character, 9-year-old Elliott, lured E.T. of the woods with Reese's Pieces
you'll see it's been around for a while.
The main reason Sawfish 2.0 sucks is that no-one is working on it right now. It's based on the old GTK+ architecture and despirately needs a rewrite. Metacity is what GNOME (at least Sun GNOME) will ultimately use. It's currently more limitted than Sawfish, but it's really great. Try it out!
As for the 2 panel quirks, please report the bug to either GNOME or Ximian (who's going to release Ximian GNOME 2.0 soon). It should be *really* easy to fix. It sounds like a bug that no-one noticed. If you're quick, it might end up in the next Ximian or GARGNOME update.
> > Ignored release notes
> > Ignored Various READMES
> > Ignored known gotchas
> Doesn't exactly sound like a ready for the
> desktop product to me.
These are installation issues, not usage features. If you try to install MacOSX on the original Mac or on the PC because you didn't read the release notes, you'd get similar problems. You'd also get similar problems if you automatic upgrade from Windows 98 to Windows 2000 without checking if Windows 2000 supports the new hardware.
If you don't want to set it up yourself correctly, you have to do some reading. If you don't want to set it up yourself, wait for Ximian or your distribution to set it up for you.
What counts is, how does it behave when you install it correctly? That question wasn't answered since the system was not installed correctly. GIGO applies as always.
Aren't there laws against dumping?p ing
http://www.investorwords.com/d4.htm#dum
All companies sell below cost from time to time to clear inventory and once and a while they sell things at or below cost for limited promotional periods. But when losses are expected to be extended for long periods of time so as to hurt the competition, you have a clear case of dumping.
IANAL, so I don't know if the U.S. has domestic dumping laws, but they definitely have dumping laws on exports, as do many other countries. This has the beginnings of a very strong international case against Microsoft.
It doesn't necessarily mean it's bad news. It may even be good news.
When Eazel died, Nautilus development didn't die. Instead, it expanded and resulted in a really nice, more focused and componentized part of GNOME. Why? Becuse Nautilus now grows in the direction the community wants, not in the direction that the Eazel wanted, so business model-related features/bloat and GNOME-duplicated functionality were stripped away.
If you feel strongly about eCos, set up a CVS on sourceforge or savannah.gnu.org and see if anyone on the Debian mailing list is interesting in porting Debian to eCos (like they do for HURD, FreeBSD, Linux, and Win32 (although this port is *really* basic)). Or submit an "Ask Slashdot" call for developers and see who is interested. Either way, the source gives you a lot of power to control your OS choice.
Definitely. I've worked on both Unix and Windows. Windows "knowledge" goes out of date very quickly since every year or two the old API and UI is put in "maintenance mode" or completely dropped. In Unix, things are more stable.
Suppose you have a programmer in 1992 with 3 years experience and transported him/her to 2002. If that programmer was a Windows programmer, he'd have a hard time finding a job today and have a hard time adapting. If that programmer was a Unix programmer, he shouldn't find it too difficult to find a job or adapt to Linux today.
It's not that Unix hasn't changed much, it's just that most of the changes in Unix are not gratuitous. Technologies are more modularized and centralized and technical advances tend to build on established technologies. Technology and experience are investments so you want to maximize their returns.
In Windows, technology is fashion. It changes regularly and is dumped when it's no longer a buzzword. (Take a look at all the unrelated and obsoleted Windows database APIs that were introduced in the last 10 years.)
For an example of this difference, take a look at the Linux kernel and the Windows base OS. In Linux, nearly every new concept seems to want to use either the mmap model or the "everything is a file" model and follows common initialization and update APIs. In Windows, every new concept requires a new data structure with new APIs and new initialization and update APIs. There's a lot more to learn and programming on Windows tends to be a lot more complicated on Windows.
Not really. GNOME's GConf works like a database (installable schemas with defaults) with any back end you want (XML, LDAP, Postgre, raw files). It's only used for configuration (e.g. user preferences) not anything critical, so you can blow it away or damage it and your system will return to reasonable defaults. You should also be able to share them between different installations, and have a registry chain so that defaults can be maintained on a central server and users can make local changes on their servers. It also has notifications so you can be notified if a specific key changes. With notifications, there's no need to restart your application (or server) just so that the new settings can take place (no reboots either!).
Windows registries are nothing like this.
- customer (even virtual customer) active involvement of clear incremental non-technical specifications. These specification must also be approved by programmers on technical grounds.
- short life cycles (2 weeks or so) and incremental changes.
- Other practises like pair programming (i.e. continuous online code reviews and design sessions) also help ensure better quality and ensure that everyone is familar with the code.
Customer involvement ensures that you're actually doing what you're supposed to be doing. Unit tests (which may include complexity measurement tests) ensure that your changes don't break anything on technical grounds (remember complexity measurements can also be unit tests). Forcing short cycles ensures that if there are problems, they're found out early. When a problem does occur (Agile methodologies assume they will), you and the customer can negotiate the appropriate solution. That six month scenerio isn't really possible. If a major architectural change is required, it needs to be broken up into manageable increments that can be done in parallel to feature implementation.Of course, no methodology is a panacea. You can write FORTRAN-like code in any language, including Java. But Agile methodologies tend to expose the problems sooner so you can deal with them. Bad practises tend to get weeded out early and dealt with.
> In fact, I can see some would even argue that :-)).
> XP hinders fixing crappy code (reasoning on
> request, but I'm not going to feed the trolls
> uninvited
Sure. One key part of XP is the ability to write good unit tests. As long as your unit tests are good, you can be comfortable in changing your code quickly. If the code is crappy, the code won't pass the unit tests, and you won't be able to change it as easily.
In this case, the only way I see that XP can be applied properly is to define a set of test cases that give the results that the crappy code is generating -- even if it's wrong. You would refactor the code until it became good code that gave crappy results, then write other test cases for good results and then evolve the code until it became good code that gave good results. While all this is going on, you need to be able to add new features and fix old bugs and possibly provide some backwards compatibility to reproduce the crappy behaviour since some people might depend on it.
Depending on the size of the project, the installed base, how much time you have to work on it, and the evolution speed of the project, it may be easier and better to rewrite from scratch and introduce a new product that is mostly like the original product.
It's definitely better to get things right the first time.
"Don't run MS Windows" doesn't necessarily mean "Run RedHat Linux 7.3 on the Intel". It means, run anything else. If we have a diverse ecosystem:
....)
...
* MS Windows 2000
* MS Windows NT
* MS Windows 98
* Other MS Windows
* MacOSX
* MacOS
* RedHat Linux 7.3 on i386
* RedHat Linux 7.2 on i386
* RedHat Linux 6.2 on i386
* RedHat on other platforms
* SuSE current on i386
* SuSE current on PowerPC
* SuSE previous version on any platform
* Debian current on i386
* Debian current on PowerPC
* Debian previous version on any platform
* Gentoo current on i386
* Gentoo on other platforms
* Any other Linux on any other platforms
* FreeBSD current on i386
* FreeBSD current on PowerPC
* FreeBSD previous version on any platform
* OpenBSD current on i386
* OpenBSD current on PowerPC
* OpenBSD previous version on any platform
* HURD on any platform
* Plan9 on any platform
* QNX on any platform
* (this list was really abbreviated, but you get the picture)
with diverse window management (KDE, GNOME, MacOSX, Win32, GNUstep, Berlin, Plan9, Raw X,
and no standard office environment (with proper interoperability) like OpenOffice, KOffice, GNOME Office, Hancomm Office, Gobe Office, WordPerfect, Raw XML, Latex,
and a security default setup in the OS and applications where you rarely need to be "root",
you get an ecosystem where it's extremely difficult (if not impossible) to write viruses that spread quickly and effect everyone.
Or you're a terrorist or a member of a hate group or you want to plot revenge on someone and you want to find out as much about a class of people so you can target your attacks more effectively.
Would you rather penetrate MI6? Or the Department of Work and Pensions?
> I'm not saying I distrust any podunk agency.
> I'd much rather not particularly need to.
> Desperately.
> --Dan
Exactly.
> Uniquely Restrictive. Break it down. It is
> restrictive in that it imposes restrictions.
It doesn't impose any restrictions that aren't available in copyright law. If you ignore the GPLed license on some software, you're free to use it, just like GPLed software. If you want to distribute that software, you can't because of copyright law. The GPL gives you *permission* to distribute the software if you do certain things. So the GPL is "Uniquely Permissive", *not* "Uniquely Restrictive".
> The most important restriction (as noted here,
> there, elsewhere, and everywhere) is that if
> you use some GPL code, the whole package has to
> be GPL.
No on many accounts.
If you use a GPLed application but don't link to it, you can freely distribute it. Microsoft distributes GCC with their Unix compatibility layer and they definitely don't release their software.
Also, if you read the license, you'll see that you can use and even link GPLed software to a non-GPLed application. You can't, however, distribute that application.
File formats are only a part of the puzzle.
Another piece of the puzzle is protocols, such as SAMBA and the protocol Exchange uses for it's groupware functionality.
The line in the document:
> So far Symantec has not received any
> submissions of this virus from customers.
is rather suspicious. If no-one has ever reported this virus, does it mean that Symantec created it?
There's also no information on how it would infect Linux systems. Does it affect user files or does it use buffer overflow to gain root access?
It's clear that you don't understand I don't have the skill to make you understand, so I'll stop here.
But for the record:
* programs don't do anything either. They are an expression of an idea. Machines that evaluate these ideas actually do things.
* mathematical proofs are computer programs that evaluate to true of false (many can be directly translated to Prolog)
* but the above is beside the point. The creation of mathematical proofs is every much a craft as the creation of computer programs and the impact of the resulting work is often more profound than any computer program (which will be obsolete in 10 years anyway). But mathemeticians share techics and results because there is value to the sharing.
* Newton said nothing about morality. He simply said, in a round about way, that there is value in sharing the expression of ideas because they tend to build on each other. There's nothing to retract and you must believe it's true because otherwise you wouldn't be wasting your time reading posts and you certainly wouldn't be trying to share your ideas with me.
That's pretty much all I have to say. If you wish to have the last word, you may. I won't reply back, no matter what you say.
> Computer programs are constructs. They are
> built from raw materials (bits, at the lowest
> level; instructions for the more abstractly
> minded) and perform a function. They are more
> like machines than they are like something from
> math or the sciences.
Just because something can be modelled by a machine, doesn't mean that it is a machine. As I've said, the mathematical proof of the 4 colour problem can be modelled by a machine (I could give you the schematics within a few months). Give me a decade and I can model Fermat's last theorem too (yes it is possible, but it's really complicated).
You should also know that any computer program can be modelled with mathematics.
> The constituents of the sciences and of
> mathematics aren't crafted things; they're
> discoveries of principles, relations, or facts.
The creation of a mathematical proof is very similar to the creation of a computer program. Neither are discoveries. Robinson's Non-standard Analysis is a proof in point. It involves extending regular mathematics in a way that cannot be discovered, because neither the statement "Robinson's Non-standard Analysis is false" nor "Robinson's Non-standard Analysis is true" contradict mathematics. It's something outside math, yet there is a useful bridge between regular math and Robinson's invention that allows you to do things and discover things in regular math much easier than you would have otherwise.
> The argument, which you advocated, that
> software should be shared like scientific
> knowledge just doesn't hold any water.
There you go again with the "should". I say it gains value through sharing. There is no moral imperative to share. Read again.
> First of all, you are clearly mistaken if you
> consider natural resources and crafted things
> to be morally and economically equivalent.
Huh? You brought morality into this, not me. Take a look at both my reply and the post you replied to. It's clear you didn't read my post.
> You're trying to say that source code is
> abstract knowledge, and should be shared so
> that others may learn from it. . That's
> bullshit. Source code is a crafted, constructed
> thing.
Nope. Read what I said. I said that *you* lose the advantages of input and feedback, so it's a good idea for you to share.
But as a side note, do you really think that abstract knowledge isn't crafted? Newton's works didn't just appear out of thin air. It took time, patience, ingenuity, and craftmanship. Yes craftmanship. Mathemeticians pride themselves on esthetics as least as much as computer scientists, if not moreso. It's not enough to solve a problem, the solution must be beautiful. The 4 colour problem was proved correct by brute force enumeration of all the posibilities. Mathemeticians still don't consider it to be solved because it doesn't have a proof crafted for it.
And if you think that a mathematical proof can't be as complicated as a program, I suggest you look at the proof of Fermat's last theorem.
And do you really think that crafted things are 100% independent and don't owe their inspiration to other crafted things? Most novelists an song writers will tell you that their work is inspired by and includes parts of the styles of other writers and musicians.
The difference between a natural resource and something that requires human effort to create is only a matter of scarcity.
If you had to create your own water from oxygen and hydrogen, or create your own air by converting carbon dioxide into oxygen and carbon you wouldn't think about customizing the available water and air with scents or flavours or integrating them into different utilities. You'd think about producing it (through human effort) and hoarding it.
Conversely, if free software were abundant, you won't think about the cost of producing it, you'd think about customization, bug fixing, and system integration.
The word abundant is the key. *If* free software dominated the economy, it would be abundant, wouldn't it? That's why the whole "If all software were free, programmers would lose their jobs" argument is bogus. Programmers would still find programming jobs, just in different programming jobs (see above). Of course, if free software doesn't have the power to dominate the economy, this argument would disappear, but then so would the fears about it dominating.
Now if you think of an idea and you don't want to share, that's fine. It's your loss as much as mine. You'd be losing all the valuable input we could provide you and you'd be losing the opportunity to increase your reputation and thus employability and the good will of customers.
Keep in mind that perhaps your idea isn't as big a contribution as you believe. Newton said, "If I had seen so far, it is because I stood on the shoulders of gaints." Newton's contributions are by no means insignificant, but he recognized that his contributions builded on a large body of other contributed work that was far larger than his own ideas. *Because* those other ideas were abundant and freely available, he was able to do great things himself. Never mind that it cost effort to produce those ideas.
I don't see how this could be morally objectionable.
> The software economy would collapse, and
> hundreds of thousands of people in the US alone
> would be out of work.
Imagine a world where air, water, and sunlight were free. Imagine the economic nightmare. If water were free then all the bottled water producers, utility companies, canteen makers would go out of business. If air were free, all the air purification systems, air conditioners, perfume manufacturers would go out of business. If sunlight were free, all the lamp makers, light bulb makers, flashlight makers, and candle makers would go out of business.
Of course, this isn't what's happened, at least in my part of the world.
Why?
Because even free things need packaging, customization, integration, bugetting, and quality assurance and because it's free, the demand for things increase dramatically. Take water, for instance. If producing water were expensive, people would not need garden hoses because they would not be watering their lawns. They would certainly not use it in water engines and fire hydrants, water cooling jackets, water guns, fountains, and bath products because these things would be too expensive to be useful.
Would this be the case you're refering to? There's no mention of a theft.
7 -0 373.txt
http://www.courts.gov.bc.ca/jdb-txt/sc/97/03/s9
One good thing about this is that the Linux Standards base version 2.0 is now a lot easier. It only has to deal with Red Hat (and Mandrake which tries to be a more or less superset of Red Hat), United Linux, and Debian. This means that a lot more can be standardized.
"I just don't get it I guess, it just seems like there are already so many standards."
As the old saying goes, the nice thing about standards is that there are so many to choose from.
The GPL makes a guarentee that the software in question will have it's source sharable for the lifetime of the software and ensures that any investment you make in GPLed software won't be closed off and resold by someone else who don't want to share.
Could a license be made that allows this to happen with patents. In particular:
* This license in irrrevocable
* This license is freely licensed for GPLed software
* This license is freely licensed for all free software subject to the condition that:
1. The software is not linked to non-free software
2. If the software contains any patents, those patents must be freely licensed to any free software.
The math is a bit complicated, but I've been able to compress it into one line of pseudocode. Can you should me where the bug is?
For all X, Explanation(X) = if X makes sense then change X until it doesn't, otherwise return bogus reason for X.
I sent them the following feedback on their idea. Hopefully others will do the same.
o -o -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-oo -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-oo -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
t mlm
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
-o-o-o-o-o-o-o-
-o-o-o-o-o-o-o-
First of all, I think that the license generator is an excellent idea. Artists and programmers are not license lawyers, yet they need to deal with this issue. A site devoted to the commons is a great asset and generating easy to understand license descriptions is important.
However I do have a few nitpicks and suggestions:
* Some of the choice seem contradictory. For instance, someone may choose to have a no-derived works and copyleft. There needs to be a way of sorting this out.
* Some of the choices seem ambigious. Is copyleft the same as copyleft+attribution? Are either compatible with the GPL? Novel's original free software license was copyleft, but it was GPL incompatible because Novel's license had stricter licensing terms.
* There are several other variations of licenses that are not included that people find important. For instance, I may not mind if my work is quoted verbatum in a larger work or I may allow annotations or even deletions, so long as they are made explicit. Or I may allow changes to my work but all changes must be given to the public. Or they may wish their work to become licensed under a freer license (e.g. public domain, GPL, BSD) after a certain period of time so they can make money on it first. For an interesting look at a few more, take a look at:
http://www.panix.com/~kingdon/licenses.html
I think that there are no more than 15 main characteristics that distinguish between most source available licenses. classifying licenses along these lines would really help sort out what each license means. It's sad that licenses are more made for lawyers, than for the people who use them.
* Relating to the above point, it would be desirable to be able to use the 15 main characteristics to not only define a license but also to look at commonly used licenses that are close to this one. For instance, there may be a license that has 3 of the 4 characteristics you consider most important. If you want users of your work to feel comfortable with your license, you'd more than likely choose a popular license, even if you have to give up on a few points. This feature allows you to reduce the license fragmentation.
* Finally, I'd suggest that you integrate the Librock License Awareness System into your web site:
http://www.mibsoftware.com/librock/lidesc/index.h
http://www.mibsoftware.com/librock/lidesc/user.ht
1. This software allows you to determine if two licenses are compatible and may be combined into a greater work. It's best to be aware of licensing issues before you combine source code since afterwards it may take more pain to become compliant than you wish.
2. Also also importnat when you wish to choose your license since it can alert you to unintended consequences. For instance, if you choose a license with the clause "you are free to modify this work but may only be distribute it or any derivatived work non-commercially" (i.e. an Alladin-like license), you may be upset that it's not GPL compatible. If GPL compatibility is important to you but you're not willing to give up your license on your current work (you don't want people making money redistributing your work before you have a chance to), you may be okay about making it GPL compatible after a certain amount of time or you may make other concessions.