Slashdot Mirror

For all the popularity of MP3, remember that Fraunhofer holds patents on it, making the creation of a legal, legitimate, Free encoder impossible.

Support Ogg ... use Ogg Vorbis for your audio encoding/storage needs. ;-)

I expect that a whopping lot of people would not consider Linux, The Kernel to be terribly useful for terribly much. After all, it doesn't include:

• A shell such as zsh; note that the notion of separating OS from shell was largely due to Multics, where the command language had its commands reference programs.
• A C library as an interface to programs, such as GLIBC
• Some set of initialization controls as with init
• ... And then the whole set of "user space" stuff, including compilers, text editors, file tools, word processors, and such...
• ... And if you want to do anything graphical, you'll be using something that is recognizably "not Linux," whether you use SVGAlib or XFree86.

The question of where the OS "stops," and where "non-OS stuff" starts is incredibly unclear.

It is not an outrageous thing to argue that Linux is "just the kernel;" that certainly does represent something that is recognizably associated with Linux, and most other components such as GLIBC, X11, GNOME, KDE, GCC, and such are decidedly not specific to Linux as they are used with other OSes of whatever provenance.

It is also not an outrageous thing to think that an "operating system" might include a bunch of additional abstractions that make it useful, which could well include GLIBC, X11, GNOME, KDE, and such.

I prefer to live in the "realm of ambiguity:"

• I would consider MS-DOS to be, while rather sparse in functionality, providing little more than a CP/M program loader, along with a userspace defined by COMMAND.COM , ANSI.SYS and some other .SYS file whose name escapes me, to indeed be an "operating system."

  It is a minimal OS, to be sure; note that you need the program loader, terminal controller, and ( whatever the INIT equivalent is) to have some semblance of a functioning system.

• I'm not sure where to draw the line with Linux.
• Someone using Linux to build embedded systems might stop the line very shortly past init by implementing a custom userspace.
• Someone using Linux to deploy Internet "WebSurfing" Kiosks might consider the "OS" part of the system to include everything below a surface loosely defined by X11; the "application" side being the JavaScript and Java stuff that people might run atop Mozilla.
• On that "kiosk," if they used cfengine to clean up the system configuration every time a new user logs on, there's some ambiguity as to whether:
  • The "operating system" includes cfengine, or
  • The "operating system" includes cfengine plus the scripts used to clean up "system" stuff.

The author of the magazine article in question obviously holds to a dogma that includes some portion of the "GUI" as part of the "operating system."

I would contend that in a heterogeneous world with computer systems used for different things, there's not a good straight answer to this.

I expect that a whopping lot of people would not consider Linux, The Kernel to be terribly useful for terribly much. After all, it doesn't include:

• A shell such as zsh; note that the notion of separating OS from shell was largely due to Multics, where the command language had its commands reference programs.
• A C library as an interface to programs, such as GLIBC
• Some set of initialization controls as with init
• ... And then the whole set of "user space" stuff, including compilers, text editors, file tools, word processors, and such...
• ... And if you want to do anything graphical, you'll be using something that is recognizably "not Linux," whether you use SVGAlib or XFree86.

The question of where the OS "stops," and where "non-OS stuff" starts is incredibly unclear.

It is not an outrageous thing to argue that Linux is "just the kernel;" that certainly does represent something that is recognizably associated with Linux, and most other components such as GLIBC, X11, GNOME, KDE, GCC, and such are decidedly not specific to Linux as they are used with other OSes of whatever provenance.

It is also not an outrageous thing to think that an "operating system" might include a bunch of additional abstractions that make it useful, which could well include GLIBC, X11, GNOME, KDE, and such.

I prefer to live in the "realm of ambiguity:"

• I would consider MS-DOS to be, while rather sparse in functionality, providing little more than a CP/M program loader, along with a userspace defined by COMMAND.COM , ANSI.SYS and some other .SYS file whose name escapes me, to indeed be an "operating system."

  It is a minimal OS, to be sure; note that you need the program loader, terminal controller, and ( whatever the INIT equivalent is) to have some semblance of a functioning system.

• I'm not sure where to draw the line with Linux.
• Someone using Linux to build embedded systems might stop the line very shortly past init by implementing a custom userspace.
• Someone using Linux to deploy Internet "WebSurfing" Kiosks might consider the "OS" part of the system to include everything below a surface loosely defined by X11; the "application" side being the JavaScript and Java stuff that people might run atop Mozilla.
• On that "kiosk," if they used cfengine to clean up the system configuration every time a new user logs on, there's some ambiguity as to whether:
  • The "operating system" includes cfengine, or
  • The "operating system" includes cfengine plus the scripts used to clean up "system" stuff.

The author of the magazine article in question obviously holds to a dogma that includes some portion of the "GUI" as part of the "operating system."

I would contend that in a heterogeneous world with computer systems used for different things, there's not a good straight answer to this.

Three words: Not GPL Compatible. I'd suggest MPL/GPL disjunction (like the Gecko engine, soon) or GPL with permission to link (like libstdc++, Guile, and the GNU Ada libraries).

Three words: Not GPL Compatible. I'd suggest MPL/GPL disjunction (like the Gecko engine, soon) or GPL with permission to link (like libstdc++, Guile, and the GNU Ada libraries).

RMS (and the FSF) do not forbid making a profit. They encourage it. Check out this philosophy page for more information.

Two other issues here: "pirate" is really the wrong word to use in almost every instance. Try "unauthorized sharing". And having source but only being allowed to write a patch for it severely stunts software development. That's why Minix didn't fly, but Linux (as a kernel) did.

One of the few things here that was almost correct: nobody has a right to make a profit by restricting others. In any way.

There's "funny 'cause it's true" but this post is only funny if you believe a (rather common) misconception.

Since HURD is a mutually recursive acronym, it's quite hard to say the entire phrase. :)

It's the GNU kernel, which has been in development for well over a decade, based on the Mach microkernel. And yeah, it's still not ready for prime-time, although you can install Debian's unstable distribution for it. The Kernel Cousin project has a section for its Debian mailing list.

The problem is also deeper than that. Look at HURD's main page:

Updated: 23 Jan 1999 matthias
Also:
The last official release was the 0.2 binary distribution of June 1997. At the moment, the Hurd developers and people from the Debian Project are assembling a new distribution; it will become the 0.3 distribution.

Gnu is regrettably not known for its popular, open style of development, and it probably doesn't have the people behind it that BSD has. Look at kt.linuxcare.com, and contrast the linux-kernel mailing list with the HURD's. One is much less enjoyable than the other; one is philosophical in tone at times.

The main thing people always forget about Open Source projects is also the most important: You have to care about the people you work with.

http://www.gnu.org/copyleft/lesser.html& lt;/a>

This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.

Why you shouldn't use the Library GPL for your next library

http://www.gnu.org/philosophy/wh y-n ot-lgpl.html

Useful resources: http://www.gnu.org/philosophy/li cen se-list.html

http://www.gnu.org/copyleft/lesser.html& lt;/a>

This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.

Why you shouldn't use the Library GPL for your next library

http://www.gnu.org/philosophy/wh y-n ot-lgpl.html

Useful resources: http://www.gnu.org/philosophy/li cen se-list.html

http://www.gnu.org/copyleft/lesser.html& lt;/a>

This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.

Why you shouldn't use the Library GPL for your next library

http://www.gnu.org/philosophy/wh y-n ot-lgpl.html

Useful resources: http://www.gnu.org/philosophy/li cen se-list.html

Is there any way to better filter the slashdot comments? Maybe something could be done using Mozilla's new Formzilla?

Well, if you're using Emacs, (and who isn't ?), then you can use the Mail/News reader GNUS, to view slashdot comments as if they were a newsgroup.

Doing this is so cool, because you can take advantage of both the slashdot scoring system, and GNUS filtering/kill filing.

See here for instructions on setting up GNUS.

Regardless of the grammatical correctness discussed elsewhere, I'm curious as to how a codec can be incompatible with Unix. Not currently implemented for Unix, yes, but incompatible, no. It's just a stream of bytes at the end of the day -- and that's *very* compatible with Unix.

Any stream of bytes is compatible with the UNIX® components that correspond to GNU Fileutils (`chgrp', `chmod', `chown', `cp', `dd', `df', `dir', `dircolors', `du', `install', `ln', `ls', `mkdir', `mkfifo', `mknod', `mv', `rm', `rmdir', `sync', `touch', and `vdir'). On the other hand, GNU Binutils (`ar', `c++filt', `demangle', `gas', `gprof', `ld', `nlmconv', `nm', `objcopy', `objdump', `ranlib', `size', `strings', and `strip') and GNU libc are the packages that really matter for building and running programs on a GNU/Linux system, and they can't handle Win32 very well ;-)

Regardless of the grammatical correctness discussed elsewhere, I'm curious as to how a codec can be incompatible with Unix. Not currently implemented for Unix, yes, but incompatible, no. It's just a stream of bytes at the end of the day -- and that's *very* compatible with Unix.

Any stream of bytes is compatible with the UNIX® components that correspond to GNU Fileutils (`chgrp', `chmod', `chown', `cp', `dd', `df', `dir', `dircolors', `du', `install', `ln', `ls', `mkdir', `mkfifo', `mknod', `mv', `rm', `rmdir', `sync', `touch', and `vdir'). On the other hand, GNU Binutils (`ar', `c++filt', `demangle', `gas', `gprof', `ld', `nlmconv', `nm', `objcopy', `objdump', `ranlib', `size', `strings', and `strip') and GNU libc are the packages that really matter for building and running programs on a GNU/Linux system, and they can't handle Win32 very well ;-)

Regardless of the grammatical correctness discussed elsewhere, I'm curious as to how a codec can be incompatible with Unix. Not currently implemented for Unix, yes, but incompatible, no. It's just a stream of bytes at the end of the day -- and that's *very* compatible with Unix.

Any stream of bytes is compatible with the UNIX® components that correspond to GNU Fileutils (`chgrp', `chmod', `chown', `cp', `dd', `df', `dir', `dircolors', `du', `install', `ln', `ls', `mkdir', `mkfifo', `mknod', `mv', `rm', `rmdir', `sync', `touch', and `vdir'). On the other hand, GNU Binutils (`ar', `c++filt', `demangle', `gas', `gprof', `ld', `nlmconv', `nm', `objcopy', `objdump', `ranlib', `size', `strings', and `strip') and GNU libc are the packages that really matter for building and running programs on a GNU/Linux system, and they can't handle Win32 very well ;-)

The fact is, I've never bought into the two Big Ideas of the OS movement. I simply don't agree with the Stallman argument that software "ownership" is an Extremely Evil concept. (No, I don't want to get into that argument right now. That would be very Off-Topic.) Nor do I agree that the Bazaar is always going to produce better software than the Cathedral.

That being said, it's pretty clear to me that some projects absolutely must be open-source. For one thing, OS software methods do work better some of the time. The Cathedral has dicked around with GUIs for decades and given us the Xerox Star, Microsoft Windows, OpenWindows, and the ultimate in unprogrammable bloatware, CDE. The Open-Source community has been around for a few years, and has almost absent-mindedly given us KDE, GNOME, Englightenment (which I personally find esthetically appealing even though my brain isn't wired to use it), etc.

Even the closed-source Mac is an example of this. Even if you accept all the fancy usability design principles the Mac is based on (and I personally feel that the Mac is overrated in this respect -- benefiting from the absence of competing usability design principles) you have to admit that Apple is doing a lousy job of maintaining them.

A more important consideration is simple security. Bruce Schneier has convinced me that the only way to secure system software is to expose the source code. That enables the user community to verify security claims. The alternative is to rely on the untestable assertions of closed-source developers.

__________

Note that the DoD did require the GPL when they funded the development of the GNU Ada front-end to GCC, aka GNAT, a while ago (circa 1995).

Now GNAT is of course still free software and ACT and ACT Europe are continuing the development and offer paying support services. Up to now they released sources from time to time, but it looks like the Ada front-end sources will be included soon in the CVS GCC repository, see the discussions on the GCC mailing list.

Disclaimer: I worked for ACT, but I no longer do, and at work I'm a client of ACT support services.

The ZDNet story mentions that the code is licensed under the GPL and the Sun Industry Standard Source License (SISSL). They stated that compliance to both licenses is necessary. They may be smoking crack and completely off (I haven't checked - there wasn't anything obvious at openoffice.org), but if not there are problems with this. IIRC the GPL forbids the addition of restrictions of any kind, so while it's possible to allow alternate license terms it is not possible to apply the GPL and another license simultaneously if the second license adds any restrictions. Also, according to the GNU license list page the SISSL is not GPL compatible.

First of all, by the GCC Steering Committee's own admission 2.96 is NOT likely to have compatibility problems with C programs. Where talking C++ here as the main problem (as you mentioned). So a lot of software won't be affected.

2) Few companies or groups are going to release only for RedHat. They either release something that works on several distributions (thus avoiding this "problem"), or they'll release separately for different distributions. Either way I don't see how you'll be getting tied to RedHat.

C) In the unlikely event that they're releasing binary only for RedHat chances are they're not going to release only for 7.0. They'll want to maintain compatibility with 6.0+ at least so they'll either compile for 6.x which will make the binary compatible with 7.0 and other distributions or they'll provide separate binaries for 7.0 and 6.x.

In summary, unless a program vendor doesn't care enough about their users to want to offer support for more than just RedHat 7.0 there won't be a problem. If they do then it is the vendor at fault, so why blame RedHat? There are always ways to tie a program to a particular distribution if you want to, and that hasn't changed AFAICS.

. . .Surely there is no better indication that intellectual property is primarily of value to those who are already powerful and wealthy (Drahos 1995; Patel 1989).

Any hypothetical scenario that depends on the invention of "tamper-proof hardware" isn't worth worrying about.

Ah, but it doesn't require tamper-proof hardware, only hardware that is sufficiently tamper-resistant.

Here's one piece of the puzzle: let's say that the digital link between a future digital monitor and your video card is encrypted, meaning that open-source software with the keys embedded would defeat the purpose.

...meaning that open-source video drivers for such hardware could conceivably be illegal for much the same reason DeCSS is.

Open Source operating systems suddenly become very, very screwed.

Expand this approach to other hardware.

Game, set, match. I hope you enjoyed your right to read while it lasted.

By the way, Intel is already working on this.

HAND ^_^

Actually, C and Fortran code will probably be compatible, but code in other languages, most notably C++ due to incompatibilities in symbol encoding (``mangling''), the standard library and the application binary interface (ABI), is likely
to fail in some way.

According to the GCC release timeline, there has not been any official releases since 2.95.2 on 24 October 1999. Major releases appear to be released once a year, so the next one should be due any time now. However, the lack of any minor releases in nearly a year - rather than every three to six months - gives the impression that development has stalled. While I'm sure GCC 3.0 will be as great as previous major releases, it's little comfort for those just want small, minor improvements to the current version.

...considering four out of the fourteen members of the steering committee are from Red Hat.

This is quite a significant issue, as libraries compiled with one release of G++ by one person may not work with another release of G++ by someone else.

This appears to be the root of the problems I had running Opera; it would generally run OK until I actually tried to load in a web page, at which point it would discover it had just tried to violate a segment. That was with the statically-linked version; a dynamically-linked version will be at even greater risk of ABI violations...

I do think that ESR is the first to submit detailed essays about Open Source, and I tout him as being one of the most influential people in regards to open source.

Bad move on Red Hat's part.

Step 1: Get the development tools. This will let you compile programs for the BSD layer. The basic idea here is to download the Darwin disk image and copy the development tools from Darwin to Mac OS X Beta. MacAddict has the details including a shell script that will move all the right stuff for you.

Step 2: Download the latest bash source code (bash/bash-2.04.tar.gz) from a GNU mirror site.

Step 3: Untar and compile it. The only real trick is the command line options for the configure script. I got it to work with the slightly incorrect:

./configure --without-bash-malloc --host=bsd

Step 4: Install it. Mac OS X Beta doesn't have a /usr/local directory when you install it. I created one by hand but I'm pretty sure that the make install would create the directory structure fine.

Step 5: Configure it. Go into Terminal's prefs and change the default shell from tcsh to bash. Set up bash config files cribbing the settings from tcsh's config files. Move things around. Have fun.

Compiling UNIX-type stuff for Mac OS X isn't that bad. I have done it with ncftp 3, readline, tintin++, and bash so far. Usually it's just a tweak here and there and it works fine. Have fun playing with it.

In addition to the points mentioned above about how to use LILO w/reiserFS you can use GRUB.

/Duncan

Duncan Watson

GUI IDE's are great, but we already have Glade. What we need is GUILE-GTK+ bindings and Glade-GUILE.

And yes, I started programming with BASIC, and I have used Visual Basic extensively, and boy, is it a pain. I wish my first language had been Pascal, or Java, or Python (although the latter two didn't exist).

I have to second you on that. The Right To Read came off as alarmist when it was first published a few years ago. But as time goes on, I find myself saying, "Richard (Chicken Little) Stallman was right."

No country that I am aware of has directly stated in law that people have the right to freedom of thought. They come at it indirectly, protecting other freedoms that are the outward manifestations of it. The closest are references to freedom of conscience. I's starting to wonder if it is time to have a repository online for time-stamped, encrypted documents containing our personal thoughts on various technical topics, just to protect ourselves from having something too similar claimed as someone else's intellectual property tomorrow.

I'm surprised there aren't already a hundred posts in this thread containing THIS LINK TO THE RIGHT TO READ STORY

It's worth noting that the author is publishing this under the Open Content Publication License as opposed to the GNU Free Documentation License which seems just as adequate.

In his foot note, the author even states, "The best known license for applying the open-source concept to other forms of expression besides computer code is the OPL." He does not explain why.

\begin{rant}\begin{flame}{FULL}Get your head out of your ass. MS is breaking ASCII and RFC 822, Just try and read a comersal webpage without IE, notice all those lovely ?s they are MS fucking over ASCII and ISO Latin-1. isn't nice to know we are going to a world where a company dictats all modes of comunication? Just think about what will happen when the DMCA and the UCTIA get in full force there will not be an internet. Just think Right to read and Letter from 2020 and tell us that this is the world you want to happen. The corret resonce to someone who does these things is a FULL FLAME respoce in hopes that either a they get with the standards or commit suicide. (virtual preferd but real aceptable.) \end{flame} A full diplomate discorse my also be usefull, take your pick. Breaking standand is a bad thing, actully MS should have bin given the INTERNET DEATH PENATLY long ago but alas they are too big. \end{rant}

Several features set Gale apart from other instant messaging systems.

Because they produce snapshots on a regular basis, everyone who downloads them is encouraged to submit the test results to this database so that regular information can be collected: http://gcc.gnu.org/testresults/

I was reading "Extreme Programming Explained" which seemed to also have a good philosophy (although I haven't gotten very good at it yet), which is to *first* write a test case for the objects that you're designing, and *then* write the code. When the tests pass, the code is complete. This way the automated test suite can be run many times a day, and you can track regressions that way.

I'm rambling, so I'll stop now! =)

PostScript is a trademark of Adobe Systems, but Aladdin Enterprises (not the StuffIt maker) has produced a portable GPL'd PostScript interpreter and tools called the GhostScript package. It even includes the GhostView PDF viewer for those platforms that have X11 servers.
<O
( \
XGNOME vs. KDE: the game!

Here's a soft (virtual) keyboard that uses GTK:
http://www.gnu.org/software/gtkeyboard/gtkeyboard. html
It can do QWERTY and some international layouts, and even the OPTI layout (similar to FITALY but faster). You can run X, Emacs, etc. with just the mouse. It has word completion too (similar to what Stephen Hawking uses, but GPLed), which speeds up text entry.

Don't forget that QNX will release RTP on Monday, and Sun has released Solaris on both Sparc & Intel platforms (and source too).
Additionally Nortel has released FIPA-OS for agent based transactions.
Add these to Linux (don't forget HURD), BSD, Inferno, Plan 9, the traditional UNIXs, and of course the Windows family there are almost too many choices.
All we need now is for Palm & Microsoft to joint the open source crowd.
Any chance of Compaq releasing VMS? How about IBM releasing VM & MVS?

Wait a second.

"The compiler is gcc 2.96"???

You mean it will have 2.96 also installed, right?

2.96 is being worked on heavily. It is not stable by any means, and the release is likely to be months away. (see the release criteria for an idea of the work left to do).

Yes, GCC 3.0 will be cool. A new standard compliant C++ library. A Java compiler (both to native and bytecode). A standard C++ ABI that will be adhered to (so you can link and dinamically link code written by any >=3.0 version). It WILL compile the Linux kernel correctly (Otherwise it won't be released, see the criteria). But none of this stuff is there, or is usable right now.

Which snapshot are they shipping? I'm sure the GCC team will love to have more bug reports, but not on an old snapshot whose bugs have been fixed.

GCC 3.0 is not ready for prime time. I don't know what RH is thinking. (AFAIK the GCC maintainers are not behind this)

(Note to zealots: If your platform is not a first tier or second tier platform, that doesn't mean they don't care, it just means that they will be relying on YOU to do the testing. See this, this, and all the intervining discussion. don't restart the flame war here)

Wait a second.

"The compiler is gcc 2.96"???

You mean it will have 2.96 also installed, right?

2.96 is being worked on heavily. It is not stable by any means, and the release is likely to be months away. (see the release criteria for an idea of the work left to do).

Yes, GCC 3.0 will be cool. A new standard compliant C++ library. A Java compiler (both to native and bytecode). A standard C++ ABI that will be adhered to (so you can link and dinamically link code written by any >=3.0 version). It WILL compile the Linux kernel correctly (Otherwise it won't be released, see the criteria). But none of this stuff is there, or is usable right now.

Which snapshot are they shipping? I'm sure the GCC team will love to have more bug reports, but not on an old snapshot whose bugs have been fixed.

GCC 3.0 is not ready for prime time. I don't know what RH is thinking. (AFAIK the GCC maintainers are not behind this)

(Note to zealots: If your platform is not a first tier or second tier platform, that doesn't mean they don't care, it just means that they will be relying on YOU to do the testing. See this, this, and all the intervining discussion. don't restart the flame war here)

Wait a second.

"The compiler is gcc 2.96"???

You mean it will have 2.96 also installed, right?

2.96 is being worked on heavily. It is not stable by any means, and the release is likely to be months away. (see the release criteria for an idea of the work left to do).

Yes, GCC 3.0 will be cool. A new standard compliant C++ library. A Java compiler (both to native and bytecode). A standard C++ ABI that will be adhered to (so you can link and dinamically link code written by any >=3.0 version). It WILL compile the Linux kernel correctly (Otherwise it won't be released, see the criteria). But none of this stuff is there, or is usable right now.

Which snapshot are they shipping? I'm sure the GCC team will love to have more bug reports, but not on an old snapshot whose bugs have been fixed.

GCC 3.0 is not ready for prime time. I don't know what RH is thinking. (AFAIK the GCC maintainers are not behind this)

(Note to zealots: If your platform is not a first tier or second tier platform, that doesn't mean they don't care, it just means that they will be relying on YOU to do the testing. See this, this, and all the intervining discussion. don't restart the flame war here)

grub is the boot manager designed for GNU/Hurd, but i'm using it on two linux-only systems and it works very well. it supports fancy menus, network booting, and a command line that feels a lot like a boot monitor. the best part is, it runs without a config file. the boot loader understands ext2, reiser, fat32 and more, nativly. hell it even does command history and autocomplete. you can give it a config file of course, but the point is you can just tell it:


grub> kernel (hd0,0)/usr/src/linux/arch/i386/boot/bzImage
grub> boot


i don't remember the exact URL, but i think it's something like this. i should point out that the version in debian potato is sorta baked. build the latest one from source if possible.

My homepage gets maybe 10 hits per day and has nothing offensive, so the possibility of people suing me because of it seems remote. On the other hand, the TI-89 section of my webpage gets 200 hits per day. I was recently thinking about this and the fact that it had no Terms of Service or Privacy Policy. Thus, I did a little research and wrote a temporary one. I sort of "borrowed" a bit of the disclaimer from various sites and shifted the wording. This shouldn't matter much, however, since some of the wording is likely standard in many site's policies. For the Privacy Policy, I went to Micro$oft BCentral's page, which had a wizard that automatically creates a privacy policy. Thus, my disclaimer and privacy policy were born. I think that they will be temporary, however, as you can just bet that M$ set up some hole inside of its policy generator in order to let it sue anyone (although TRUSTe was a sponsor of the generator); plus, the modifications might not be worded correctly and could have created loopholes. Anyway, for the long term, TRUSTe has a lot of information about what you need in a privacy policy and it will certify your site for you. Plus, I think that the disclaimer at GNU might be able to be adapted for a disclaimer or a terms of service. "Borrowing" a policy from another site might not be entirely legal but it is ok to borrow GNU's license. I think that creating your own policies is a good idea but you shouldn't have to hire professionals if you just have a site as a hobby and writing your own might create holes in it if you miss certain things. Also, as for avoiding lawsuits, you can put a clause on your site forcing people to pay for your lawyers in any lawsuit that occurs due because of their improper use of your site as dictated by your policy. Then if they lose, which they likely will in a lawsuit of this type, they can pay for your lawyers.

• "GNU and others never released office suites, operating systems during those times"
  
• "Redefined what's moral and free"
  
• "to make a living i'd have to become a consultant"
  
• "one group more deserving than another"
  
• "GNU pushes GPL, not public domain"
  
• "They've decided that no one should profit from the programs they write"
  
• "they believe pirating movies, music and software is perfectly moral and just"
  

• "GNU and others never released office suites, operating systems during those times"
  
• "Redefined what's moral and free"
  
• "to make a living i'd have to become a consultant"
  
• "one group more deserving than another"
  
• "GNU pushes GPL, not public domain"
  
• "They've decided that no one should profit from the programs they write"
  
• "they believe pirating movies, music and software is perfectly moral and just"
  

Right to Read

I'm not trying to belittle you or anything, but I've seen several of your postings and I just think you're overly optimistic.
----------

Sean

I wish I had more time to learn how to program, and then actually program something. Many of you will be familiar with GNU Stow, and maybe even some of you had tried it. Well, I have. It's pretty nasty. While it works, it is cumbersome. But, I strongly think they've got the right idea.

For those of you not familiar with GNU Stow, it allows you to install a program in an arbitrary subdirectory(say, /usr/local/stow/Quake2-version), and then it makes symbolic links, recursively, from the installation directory to the system directories. ie: /usr/local/stow/Quake2-version/bin/quake2 is linked to /usr/bin/quake2.

I really think that's an incredibly good thing. For many reasons, and let me elaborate.

If you're at an unfamiliar system, or you're using a rescue disk, you might not know of, or have access to a package manager. You can't add nor delete packages, and you can't query packages. You don't know what files a package contains, and you don't know to which package a file belongs. I feel it's imperative that you can accomplish all of those tasks with standard *NIX utilities(ie: ls, mv, cp, ln, rm, cat, etc., etc.). To see what files are contained in the aforementioned Quake II package, I'd just need to do a 'ls -R /usr/local/stow/Quake2-version'. To see what what package owned /usr/bin/quake2, I'd just need to do 'ls -l /usr/bin/quake2'.

Of course, a good symbolic-link-based package manager should be a bit more complete. Now, RPM(I don't know about APT) uses a database to store its information. I gotta say, that's pretty stupid(no offense, RPM guys - I'm sure you have good reasons). At least, it's not very robust, from a system recovery/stability standpoint. So we want to get rid of a database. After all, we want to be able to manage packages with standard *NIX utilities, if we're really stuck in a bind. So, I guess each package would have some files, in its installation root(ie: /usr/local/stow/Quake2-version/), describing some things. Files named things like Requirements, Provisions, PackageInfo, PackageConfig.

Requirements - Would have sections on both file-dependancies(ie: /bin/ls) if the package required individual files, and package-dependancies(ie: fileutils-4.0).
Provisions - Would have sections on libraries and possibly a seciton on packages which the installed package replaces(ie: Postfix replaces sendmail).
PackageInfo - Would have a description of the package, and some notes on how the particular package may differ from the standard source distribution. Also some user-friendliness things like the type of software(ie: System -> Libraries) and such.
PackageConfig - This would contain the pre- and post-install scripts(yes, we really want to know what a package does!), and maybe anything that was done during installation based on any input the user gave.

These are just ideas, and I don't have the skills or time to implement them, so don't take it to heart too much ;) To be honest, I don't think any new package management system will succeed unless it has compatibility layers for RPM and APT. Both on the shared-library leve, and on the command-line level.

'Round the firewall,
Out the modem,
Through the router,
Down the wire,

I had this situation to solve with an NT server: My customer has an IDE zip for backup purposes. The GUI tools from Iomega were neat and all, but then he asks for automatic backup. "Ok, I'll add it to scheduled tasks" Right? Wrong! It needs YOU to nod at it each time you are to backup. So, by separate another field servoid and I sought for a command line utility that could backup and compress on the fly. He found PZIP 2.04g for DOS. And worse, he installed it and left a scheduled task running.
Guess where I found what I was searching for?. Yes, in GNU. Tar combined with gzip (hadn't checked out whether there was bzip compiled for DOS family). I removed it tranquilly, worked around the complaints NT throws when you ask for a tar cz bla_bla_bla.tar.z and there it was! No need for anyone to know a process was running nor to nod everytime it ran. There was, though, something I didn't like about tar working in NT (runs finely in W98): shortened long filenames. Even so, I don't think working around this would be too hard.
Find something similar, non GNU. Oh, no matter interfaces, just results.
-------------------------------------

You seem to be saying that you would have no objections at all to a law that illegalized the act of opening and reading a book whose paper you own.

Attitudes like this scare me. Really. The usual antidote is to point out Stallman's article The Right to Read as an illustration of where we're heading (and, in many ways, where we already are).

do something that is not illegal to protest (stop buying DVDs might be a start).

Believe me, willfully breaking laws is a last resort. I haven't bought a DVD player or drive yet (the only ones I can afford are region-crippled), and I'm seriously considering moving to a country where so-called "protest" actions such as promoting and distributing DeCSS would be perfectly legal.