Slashdot Mirror

If you're going to name via dependencies then why would you only list one of the dependencies in its name rather than all of them?

It's a matter of correlation. If a system has the dependency that forms part of a platform's name, then it's far more likely than not that the system has, or that its administrator can practically install, common dependencies of other applications for the same platform. By this measure, perhaps GNU is most central to server applications and programming tools designed for Linux, and X Window System to desktop GUI apps. Hence the names "GNU/Linux" and "X11/Linux" to contrast with "Android/Linux".

And what constitutes a GNU/Linux system?

Free Software Foundation acknowledges use of Linux apart from the GNU OS while intentionally declining to give a precise definition. This has led David Johnson to write an article titled "By Any Other Name" making the reduction to absurdity argument you may have been anticipating, largely by replacing GNU with an adaptation of the FreeBSD userland. But my personal definition, based on correlation with installable dependencies, is GNU Coreutils plus two other major components of GNU, such as Bash, GCC, glibc, and Emacs. This means that Cygwin, MinGW with MSYS, and Microsoft WSL are GNU/Windows, and a full installation of DJGPP is GNU/MS-DOS or GNU/FreeDOS.

And further to your question does an application written for the GNU C runtime not run on bionic for example or do you need to include that as part of your naming convention?

Some applications are specialized to run on glibc, the implementation of the C language and POSIX standard library included with GNU. Others will run on any reasonable implementation of the C library that provides varying level of support for POSIX, such as Bionic. But many applications built for Bionic have a more central dependency they can cite, namely the Android userspace.

So, it is probably more correct to say Linux without the GNU unless we should call Windows "GNU Windows" since one might choose to run a Mingw app.

MinGW is just GCC with the C library of Microsoft Visual C++ 6. If someone were to install Cygwin, on the other hand, that might stand a better chance of being called GNU/Windows. (In fact, Cygwin stands for Cygnus GNU/Windows.) And you're not the only person to present this sort of reduction to absurdity argument. So I set out to define a "GNU/$kernel" userland for myself as GNU Coreutils plus two other major GNU components, such as Bash, Emacs, GCC, or shared glibc. GNU/Linux counts, Cygwin counts, and MSYS counts.

Would "X11/Linux" be a better term to distinguish Fedora, Debian, and the like from Android and uses of Linux on router appliances?

Another tutorial comes with my brewing program, QBrew: http://www.usermode.org/code.html.

Which conspiracy are you accusing me of participating in? That 9/11 was an inside job? That the military is covering up a spaceship that crashed at Roswell? That Kennedy was assassinated by the Federal Reserve? That Bush is really a reptilian space alien? That the rich and powerful sacrifice babies at Bohemian Grove during satanic rituals? That so-called chemtrails are a government plot to poison us? That Microsoft bought off everyone who every wrote a bad review of Linux?

Please tell me. Which paranoid delusion of yours am I a part of?

http://www.usermode.org/blog/conspiracism/debunkinglinks.html

It is official -- Netcraft confirms: FSF is dying

One more crippling bombshell hit the already beleaguered FSF community when IDC confirmed that the FSF's mindshare has dropped yet again, now down to less than a fraction of 1 percent of all computer users. Coming on the heels of a recent announcement from Linus Torvalds, which plainly states that the Linux kernel will NOT be moving to GPLv3, this news serves to reinforce what we've known all along. The FSF is collapsing in complete disarray, as fittingly exemplified by founder Richard Stallman's hairstyle and rambling GNU/Everything Communist anti-developers'-rights "I'm-right-and-you're-stupid" commentary.

You don't need to be a Kreskin to predict the FSF's future. The hand writing is on the wall: the FSF faces a bleak future. In fact there won't be any future at all for the FSF because the FSF is dying. Things are looking very bad for the FSF. As many of us are already aware, the FSF continues to lose mindshare. In a recent poll on Slashdot, 97% of computer users preferred Microsoft to the FSF in terms of both ideals and the quality of their flagship products.

The GNU operating system is the most endangered of all the FSF's projects, having lost 93% of its core developers. Unable to convince users to use GNU's own "Hurd" kernel, the FSF has made several desperate attempts to capture mindshare by riding Linux's coattails. The aforementioned sudden (although not unexpected) denouncement of the GPLv3 by Linus Torvalds only serves to underscore the point more clearly. There can no longer be any doubt, the FSF is dying.

Let's keep to the facts and look at the numbers.

FSF founder RMS states that there are almost 7000 remaining GNU users. How many of those use Emacs? Let's see. Consider the bell-shaped curve of an IQ distribution graph. At best, Emacs users universally score two standard deviations below the mean, which means that they make up approximately 2% of any given sample. Therefore, there are 140 Emacs users left in the world. A recent article showed that GCC usage is declining among truly free operating systems in favor of ICC or even SDCC. There's GNU and Emacs, what else does the FSF produce aside from hot air?

Due to the troubles of the GNU operating system, abysmal adoption rates and so on, the GNU folks gave up on improving their code and instead began to concentrate on marketing their beta-quality OS. Theirs is just another unfinished open source project with a poorly designed interface and a lot of ideological baggage. It's no wonder that more and more businesses are turning to Microsoft.

All major surveys show that the FSF has steadily declined in mindshare. The FSF is very sick and its long term survival prospects are very dim. If the FSF is to survive at all it will be among juvenile political dilettante dabblers. The FSF continues to decay. Nothing short of a miracle could save it at this point in time. People just don't want to hear their message anymore. For all practical purposes, the FSF is dead.

Fact: The FSF is dying

Thus many pendantic [sic] people like to call it "GNU/Linux".

Not "pedantic", rather, "obsessed ideologues". I might take their arguments more seriously if they didn't keep changing the name we're supposed use.

http://www.usermode.org/docs/gnulinux.html

> to release the source code to derivitive works
> based upon GPL software, i.e. the code you
> incorporated into your proprietary product. You
> don't have to GPL the entire product at all

Most products don't contain a multitude of independent binaries; they usually have one executable and perhaps a couple of shared libraries. Word processors, games, and database engines all are pretty much like that.

Now say a single module, in a shared library, uses some GPL code. That module is then required to be GPL, since it is by definition a derivative work. The main executable must then also become GPL because of the FSF's interpretation of linking as making a derivative work (which probably won't hold up in court, but that's another story). Then all the other shared libraries loaded by this executable become GPL through the same linking clause. At this point the entire product is GPL. Care to point out where I am mistaken?

> If you borrow a socket interface from a GPL
> product and put it into your application, does
> your entire application become a derivitive work
> of that socket interface? Of course not!

Yes it does. See paragraph 0 of the GPL, which defines a derivative work as "a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language." Perhaps you didn't read the GPL yourself then?

> Even the COPYING file in the Linux kernel (though LGPL)

The Linux kernel is a modified GPL. Did you read the COPYING file in your tree? It has a preface by Linus, which explicitly exempts userspace programs from the license.

Now, LGPL is a completely different beast from the GPL, exactly because it lacks the "viral" property. An LGPL library containing a socket interface would be perfectly legal to link into a proprietary application. glibc is a fine example of this.

There is some doubt whether the linking constitutes a derivative work under copyright law. If it does not, then the GPL loses its viral property and becomes equivalent to the LGPL. Unfortunately, nobody has bother to get the situation resolved. Until it is resolved, it is unlikely that any business (except the ones like RedHat, that just provide services) would touch GPL code.

> Remember, the GPL is simply a license that allows
> you to copy and redistribute copyrighted software.
> It grants rights, it does not take them away.

The same can be said about Microsoft's EULA: if you don't accept it, you don't have any right to use their software at all! Imagine that! The only difference is that Microsoft sells the licenses. I am sure Microsoft would be happy to give you the additional rights to copy and redistribute Windows. For the right price, of course. So you can keep your platitudes to yourself.

See this argument.

I looked it up (QT screenshot, QT/Aqua screenshot).

It looks impressive, compared to Neooffice/J.

But does that QT OOo actually build? on the Mac?

I looked it up (QT screenshot, QT/Aqua screenshot).

It looks impressive, compared to Neooffice/J.

But does that QT OOo actually build? on the Mac?

Do you use ProMash or qbrew? I'd like to use ProMash, but then I'd have to boot into Windows and I don't want to do that. Qbrew is nice but lacks many of the features that makes ProMash such a great tool. I'd like to help code it, but it's not written in perl. :)

Go grab my QBrew software. It includes several recipes that are reinheitsgebot, Open Source, and predate this guy's "world's first" by several years.

> The GPL doesn't say anything about "linking".

No, but it says much about derivative works. And FSF argues that linking makes your program a derivative work. Read this.

> People confuse the folklore with the actual licence.

No, they confuse the actual license with the intention of the license's authors. I think that is an important distinction.

I think that every GPL fanatic should read the article referenced in the parent post: so I'll repost it here. It's too bad that FSF's opinion is different. I would really like to see this resolved in court once and for all. Any takers? Just write a proprietary program and link it to a GPL library. And then wait for FSF to sue you.

Runtime linking may not be covered by that interpretation, as it's technically done by the enduser and there is no distribution of copyrighted work, as long as the end product is not considered a "derivative work" of the GPL'd library.

I have seen in this thread are handled by KDM exactly how people are dreaming they would be implemented.

I doubt that, since KDM isn't even a window manager.

You probably meant "kwin", but that can demonstrate bad window-focus-handling too.

For a test, run XMMS and kwin. First set XMMS to be on all workspaces (a little difficult, because it doesn't draw standard borders, but try pressing Alt-F3). Next, open and close an auxilliary XMMS window, such as the playlist, and see if you can get the workspace setting to persist...

You missed my QBrew software. Where else you going to go to get a native GUI homebrew calculator for Linux and BSD?

Hmmm, I had a trappist monk write me about my brewing program, so there has to be at least a few left still brewing.

May I suggest for your first homebrew, my homebrew recipe calculator. Included is a brewing primer for your newbies.