> Technical reasons for making the change;
>
> a. Compatibility with the majority of existing unix systems.
Incompatibility with the majority of Linux systems. Incompatibility
with the majority of Linux packages.
> b. See a. It can not be stressed enough. If FHS is ever to get OUT
> of
> I'll give you one solid reason, uniformity across unix platforms is a
> must have if unix, especially free unices, are going to succesfully
If we are in marketing mode let me point out we are not Unix in the first
place and that C:\> is the standard
> I don't see a connection between /var/spoo
> But I don't think the FHS should be specifying the actual location of
> the files at all. True, the FHS should not cause too much pain for the
Ok good we agree on this
> The only thing that really matters is what pathnames applications can
> count upon to work. Given that the rest of the wor
> 1. Interoperability with other systems.
10+ million Linux boxes use /var/spool/mail. Its also a spurious claim. All
existing tools assume linux uses /var/spool/mail. Other systems even sharing
via NFS dont get problems with this /var/spool usage
> 2. Disk space management.
We've proved between
> but I haven't heard any technical reasons besides, "Moving spool
> directories is hard". When I and others have pointed out that moving
> the spool directory isn't required; just a symlink, I have heard dead
> silence. So the lack of technical discussion, but just a stony-silence
> "No!" is rat
> I thought the purpose of this project (at least the FHS) is to create a
> standard
> of what the filesystem should look like, not necessarily what it currently
> looks
> like. Just because `Everyone is doing it' (tm) doesn't mean it's right.
> Personally, I want Linux to be clean and elegant in
> Just threadening with sueing is simply an action of FUD.
I haven't threatened to sue anyone. You must have been listening to
Matthais foaming at the mouth too much.
> Sorry for my harsh words. But it looks to me like some people are trying
> to keep kde people from making even better free soft
> Alan: This is a perfect example of FUD!
No
>SuSE has the biggest rate of growth of all Linux distributors in
>the US.
And SuSE and Red Hat and all of them put together are not worth a US lawsuit
yet. Price yourself a US lawsuit then judge again.
Make them 5 times bigger and ye
> If I use libc, I don't think I am creating a libc. Unless I am, I'm not
> deriving, I think. If I use libc, I simply use the services. Hence, libc
> is "a section of" the thing I am making, and does not derive from it.
Your program derives from libc by being linked with it. This is precisely
why
> > And lots of people haven't kicked stuff back. Why doesn't *BSD run on an
> > SGI Indy - its because the BSD license didnt force all the neat stuff
> > to be contributed back. And there are thousands of other examples like it.
>
> I fail to see how this is all that much different from the GPL
>
> > And by now Sun would no doubt be shipping a binary only KDE that forbid
> > you to redistribute it and contained fixes you couldnt get back off them
>
> Ehm, the world hasn't gone to hell because not everything is GPL. Take
> for instance companies using FreeBSD, such as Whistle and Best Inte
> It's really a shame KDE chose the GPL. Many BSD people will tell you the
> GPL is the most restrictive free software license there is. It's the only
> widely used free license that prohibits use with a library like Qt under any
> circumstances at all. No special exception for system libraries,
> However, the license for that derived work (I'll call it A) claims
> that the whole of A must be GPL'd. However, Qt is not part of A (the
> GPL says "section of"). Qt provides services to A, and A depends on
> those services: A very different thing.
Qt is part of the derived work. It is linked
> > The GPL'ed apps require that the work as a whole must be distributable
> > "under the terms of the GPL". Do you think that means that I have to
> > re-license the individual parts?
>
> Will Debian remove Motif linked XEmacs from their ftp server?
> According to several Debian developers Motif
> files and libraries being linked together. Does that mean that you
> think Debian should convert libc and so on from the LGPL to the GPL in
> order to comply with the license of the GPL'd applications in main?
Arnt if you stuck to using facts you might be able to have a sensible
discussion
The
> If I say, do what you want with my code, and you incorporate it in a GPL
> app, do you relicense my work? No, and you can't, because you're not the
Yes, you create a combined work bound by the GPL. And the GPL permits
components of a GPL'd item to be freer than GPL (by the GPL definition of
free
> In my opinion, Qt is not a section of KDE, it is not derived from the
> KDE and it must be considered independent and separate from the KDE.
> In other words: The KDE's usage of the GPL does not cause the GPL, and
> its terms, to apply to Qt.
Indeed Qt is not part of the problem
>
>
> It's clear that (e.g.) libc accompanies (e.g.) /bin/ls in Debian: They
> are both in main, and the package maintainer makes sure you get libc
> when you get /bin/ls. If you also think that libc is a "section of"
> (see section two) /bin/ls and so on, then the conclusion is clear:
> You're in con
18 matches
Mail list logo
