Whether you call it a module, or an application, both are a gob of bits loaded into RAM, dynamically linked to GPL code, then utilize said GPL code to provide services.
Processes aren't linked into the kernel at all like modules are, the only things they're linked against are userland libraries and you still have to respect each libraries license regardless of what license the kernel is under. Each process's only real interaction with the kernel is via syscalls and even those are usualy proxied via some library like glibc. And on top of that the Linux kernel has a specific exception for userland apps in it's license so that it can't be interpreted like you just did.
The funny thing about this whole thing is the dunderheads who stirred up this shit have unwittingly violated the GPL themselves by trying to modify the license without obtaining permission from all the authors involved. Why Linus held back on that point in his posting kind of escapes me.
Because the patch wouldn't violate the GPL at all, the GPL covers distribution but not use and the patch was purely runtime check, gregkh even admitted this in the post where he apologized and withdrew the patch.
IIRC the only version with the "don't run this in a VM" clause was Home Basic, all of the higher versions can run in a VM perfectly legally. And it's purely a licensing restriction, Vista Home Basic will still install in the VM just as well as the other versions.
In Debian there's 2 packages, totem-gstreamer and totem-xine. Whichever you install determines which backend totem uses for it's codecs, I would assume that FC does something similar and that's why one conflicts with the other.
This isn't a hit to Debian, it's something that's needed to be done for years. I'm glad Debian has the balls to start the project going. And hopefully other distributions will realize this and start helping out and then cdrtools will be as relevant as XFree86 is today.
The point is that there's nothing in the Debian Free Software Guidelines that prevents the use of the CDDL. Debian does *not* require GPL-compatibility. Usually.
They don't require GPL-compatibility ever, they require DFSG-compatibility and licenses other than the GPL fall under that category, even some that aren't GPL compatible like the MPL and CDDL.
The debian folks are being far too nice about this. I don't for the life of me understand why this guy has been tollerated for so long. He is a major reason why CD burning is more of a pain than it should be in Linux. While CDRtools may be free the DVD writing tools from the same author are not.
While I agree with the first part, Joerg is a huge PITA and doesn't listen to anyone that doesn't already agree with thim. The last part is wrong, from what I read he's recently put the DVD burning code into the CDDL'd cdrecord code so you don't need is cdrecord-prodvd crap anymore.
Distribution. The GPL is a distribution license not a usage license, locally you can do whatever you want with the code as long as you don't distribute it. Distributions won't legally be allowed to distribute software under the GPLv3 that links against GPLv2 software, but if the software is just bundled together ("mere aggregation") on the same disc I believe it's fine. Just like the CDDL and GPLv2 are incompatible but Debian already ships some software under the CDDL, it just has to only link with software under compatible licenses.
Is there another way to do what ctrl-f and ctrl-g do in vim?
According to ":help ^G" the command ":f" will also print the filename. There doesn't seem to be any alternative to ^F though, although PgDn works here, but if your CTRL key is mismapped you probably have an equal chance of having PgDn mismapped as well.
Not that I dislike Claudia's character at all, but I'm 99% sure that Claudia will only be on the show for the first half of the season. She's mainly there because Amanda is out on maternity leave.
Also, Farscape was probably the best Sci-Fi show ever. The problem was that it turned out to be almost one big story, so you have to watch it straight through from the beginning to understand what's going on.
All of the KDE help files, for instance, are distributed under the GFDL. Debian hasn't cut them yet, but does this mean that it won't be including them as soon as someone realises?
Yes, I would assume that they'll go into non-free in an upcoming major release.
I'm impressed by the project's dedication to being so specific about licences, but sometimes I wonder how much of that will eventually come back to haunt it.
The opposite is more important. Having Debian not get into a bad position because they're violating licenses is worth making you have to install some packages from non-free.
That's fine. In my opinion, it's a bit control-freaky, but that's their thing, and they're welcome to it. They're allowed.
It's called integration and QA. Debian developers put a lot of time into making their packages work well with the rest of their system and a lot of times this requires changes to the upstream source. For instance, the Debian XF4.3 package in sid currently has almost 200 patches applied to it. It's a good thing, it's what makes Debian feel like a complete system and not just a mish-mash of random packages.
I wouldn't want to install Debian, only to find out that the version of "Firefox" is installed isn't the same as the version I could get from Mozilla.
Depends on your outlook. Security patches for instance. Debian has a strict policy in not allowing new major versions of packages into stable, so if a security hole is found in FF the FF maintainer will fix it in the FF version in stable and upload that version instead of the new version from Mozilla with the fix and who knows whatever other changes.
Where's the problem here, honestly? Call it "Mozilla Firefox - Debian Community Edition" or "Debian Web Browser - Based on Mozilla Technology"
Brand recognition. If Debian all of a sudden doesn't include FF when other distributions do, people will skip Debian because they won't know that "Debian Web Browser" is really FF. And I doubt they'd be able to use your two examples because the terms FireFox and Mozilla are probably not usable once you change the source.
Really? Tell me how FreeBSD would be vulnerable to a bad implementation of linux's passwd, for example.
Obviously not all of the software is shared, but nearly all of the network server software is and that's where it's the most important because that's where you have the most exposure.
Of course, you wouldn't want to weed out all of the duplicates from different distributions putting out seperate advisories, now would you? And AFAIK FreeBSD doesn't put out advisories for things in ports, do they?
Wow and look at that, according to Secunia Debian hasn't had a security advisory since 2003!
So? What about Oracle support? Or Fiber channel adapters? Is Secure Path supported?
You've been looking at the wrong benchmarks. Linux only recently beated FreeBSD on benchmarks, by very few points, stable kernel vs development FreeBSD version.
Which benchmarks are you talking about?
Of course you don't see the point. Now try to run mandriva-specific stuff on 3 more distributions and you'll see why it's good to have a centered, working environment instead of 500 distros that consist on the linux kernel + 300 apps thrown in. As you said, software for FreeBSD works on FreeBSD. But you can't say the same on linux. What with every distro having its own directories, lib versions, and so on, it's kind of impossible to pack one software piece for the X different versions of the same kernel . Enlightened now ?
There's nothing to be enlightenend about, you run Mandriva packages because you want to run what they've packaged and support. You wouldn't install a NetBSD package on FreeBSD and then complain because it didn't work, right? And if for some reason you really don't want to run the Mandriva package you can compile it yourself, there's nothing stopping you from doing that.
Your broad knowledge seems to know only web and mailservers. Sorry to disappoint you, there is lots of software for other server applications around. And I'd rather run them on any BSD than on Linux.
But why? The performance difference isn't large either way. Security is equal if you know what you're doing. The only thing you get by choosing FreeBSD is a shitty package management system and no official support.
I'm giving you a single example out of many I could think of right now.. who had preemption first, who is copying it now ?
FreeBSD 5.0 was released in 2003, I see Linux kernel premption work going on in 2001 with a quick google search. And AFAIK FreeBSD 5.x still has many places where the GIANT lock is used which kills preemption.
ah, another. Who had the port systems, who tried to copy it to linux ? *cof*gentoo*cof*
Just because someone copied it, doesn't mean it's good. Portage, and Gentoo in general IMO, is crap and the ports tree in FreeBSD is only slightly better.
And with your BSD-init script how do you restart a single service? Sure, a lot will reread their config if you send them a HUP signal but that's not true for all and sometimes a full restart is necessary if you've changed something major like the interfaces a daemon should listen on. With BSD init you can't, you have to kill the daemon and restart it manually, usually requiring you fish through the init script to find the appropriate parameters or just reboot. With Sys-V you just run '/etc/init.d/daemon restart' and you're done.
And there's far from a zillion scripts, on my laptop here my/etc/init.d directory has under a hundred scripts. While that seems like a lot it's far from enough to slow the system startup/shutdown (when I'm not using swsusp2, which is rare) and grep searches them all for me very fast. If you're opening them all and looking for what you're trying to find, yes that's a lot of files and it'll be slow, but blame yourself for not knowing the tools.
Simple answer : dependency hell. That's the reason why I switched from rpm based distributions to gentoo. For me, it does not exists anymore.
Generally it doesn't exist for anyone anymore, RH has had up2date for years, FC comes with yum, apt works fine with RPMs as long as you have a repo to install from. Personally I use Debian because the package quality is much higher than any other distro I tried, not that I've had a reason to try any in the last few years.
Every package is done to work flawlessly.
Flawlessly? I must have missed the announcement that Gentoo put out when they released bug-free development.
For dependancy checking when removing packages it can be done at a system level. Not after each removal (maybe a gentoo user can illuminate me) but with a simple command that removes all needless packages.
Think about it in the other direction. Because there's no dependency checking you can do something stupid like remove GTK and break all of your Gnome apps and Gentoo will just stare blankly back at you without even a warning. Sure you can just reinstall GTK, but what if you remove something system-level important like glibc or part of python that portage needs?
Yes, but you will find yourself troubled by many packages. You would loose many advantages to use your current distribution. Futhermore, you won't be able to compile everything. And if you did so, then why use your distro?
Why would anyone be troubled by compiling something one any distro but Gentoo? Every distribution is compiled somewhere, for RPM based distros all you need is the src.rpm and you can recompile the package with ease. For Debian you can 'apt-get source' to get the source package and rebuild that or you can use apt-build to rebuild as much as you want with 1 command.
I'm sure that portage is more or as simple as your binary installation service. (There are graphical UI).
Except that portage is slow and lacks many package management features that binary package users are used to having, basic things like dependency checking on package removal.
Even better, big packages like Mozilla and OpenOffice have binairies ready for use.
And doesn't that defeat the purpose? The big packages are the ones that have the best chance of having a noticable speed difference with the proper configuration/compilation switches. Who cares if coreutils is compiled for my machine, ls runs the same pretty much, no matter what.
apt/dpkg is neat, but I like the ease AND utility of pkgsrc
I've never used pkgsrc so I don't have any idea why it would be better, care to explain?
How easy is it to port the entire apt/dpkg packages tree to a new operating system?
If you mean the packages themselves, not much if the infrastructure is setup. Meaning apt, dpkg, debconf, etc is installed on the host system. There are already people working on Debian GNU/KFreeBSD.
Debian packages are pretty much tied to Debian, it's a downside of the system being so integrated and well done.
I've got sarge on an Ultra2 right now with no problems. Once in a while a package is broken, but that's what apt-listbugs is for, that way you can avoid breakage and just wait a few days while the bug is fixed.
In the last thread I read the amount of architectures couldn't be proven to be a real point of delay. The only thing it had a noticable affect on was d-i development, most packages work just fine on all architectures and with the current buildd system they're autobuilt so no additional work is needed by the maintainer.
Gentoo can get releases out quickly because they do virtually no QA.
98% of 15,000 is 14700.00, if 300 packages don't even compile it probably doesn't make sense to release it. Of course what packages don't compile needs to be evaluated, but in general I think 98% is achievable.
Slashdot Mirror
I've been browsing with Galeon for years which doesn't identify itself as FF or IE and I get by just fine.
That's why it's just called CIFS...
Processes aren't linked into the kernel at all like modules are, the only things they're linked against are userland libraries and you still have to respect each libraries license regardless of what license the kernel is under. Each process's only real interaction with the kernel is via syscalls and even those are usualy proxied via some library like glibc. And on top of that the Linux kernel has a specific exception for userland apps in it's license so that it can't be interpreted like you just did.
The funny thing about this whole thing is the dunderheads who stirred up this shit have unwittingly violated the GPL themselves by trying to modify the license without obtaining permission from all the authors involved. Why Linus held back on that point in his posting kind of escapes me.
Because the patch wouldn't violate the GPL at all, the GPL covers distribution but not use and the patch was purely runtime check, gregkh even admitted this in the post where he apologized and withdrew the patch.
Depends on whether you define crappy as:
A) Having less features
or
B) Causing my machine to die in mysterious ways occasionally
IIRC the only version with the "don't run this in a VM" clause was Home Basic, all of the higher versions can run in a VM perfectly legally. And it's purely a licensing restriction, Vista Home Basic will still install in the VM just as well as the other versions.
In Debian there's 2 packages, totem-gstreamer and totem-xine. Whichever you install determines which backend totem uses for it's codecs, I would assume that FC does something similar and that's why one conflicts with the other.
This isn't a hit to Debian, it's something that's needed to be done for years. I'm glad Debian has the balls to start the project going. And hopefully other distributions will realize this and start helping out and then cdrtools will be as relevant as XFree86 is today.
According to ":help ^G" the command ":f" will also print the filename. There doesn't seem to be any alternative to ^F though, although PgDn works here, but if your CTRL key is mismapped you probably have an equal chance of having PgDn mismapped as well.
Not that I dislike Claudia's character at all, but I'm 99% sure that Claudia will only be on the show for the first half of the season. She's mainly there because Amanda is out on maternity leave.
Also, Farscape was probably the best Sci-Fi show ever. The problem was that it turned out to be almost one big story, so you have to watch it straight through from the beginning to understand what's going on.
Yes, I would assume that they'll go into non-free in an upcoming major release.
I'm impressed by the project's dedication to being so specific about licences, but sometimes I wonder how much of that will eventually come back to haunt it.
The opposite is more important. Having Debian not get into a bad position because they're violating licenses is worth making you have to install some packages from non-free.
It's called integration and QA. Debian developers put a lot of time into making their packages work well with the rest of their system and a lot of times this requires changes to the upstream source. For instance, the Debian XF4.3 package in sid currently has almost 200 patches applied to it. It's a good thing, it's what makes Debian feel like a complete system and not just a mish-mash of random packages.
I wouldn't want to install Debian, only to find out that the version of "Firefox" is installed isn't the same as the version I could get from Mozilla.
Depends on your outlook. Security patches for instance. Debian has a strict policy in not allowing new major versions of packages into stable, so if a security hole is found in FF the FF maintainer will fix it in the FF version in stable and upload that version instead of the new version from Mozilla with the fix and who knows whatever other changes.
Where's the problem here, honestly? Call it "Mozilla Firefox - Debian Community Edition" or "Debian Web Browser - Based on Mozilla Technology"
Brand recognition. If Debian all of a sudden doesn't include FF when other distributions do, people will skip Debian because they won't know that "Debian Web Browser" is really FF. And I doubt they'd be able to use your two examples because the terms FireFox and Mozilla are probably not usable once you change the source.
Obviously not all of the software is shared, but nearly all of the network server software is and that's where it's the most important because that's where you have the most exposure.
keyword "FreeBSD" --> Found: 76 Secunia Security Advisories, displaying 1-25 keyword "Linux" --> Found: 3264 Secunia Security Advisories, displaying 1-25 ...
outchie...
Of course, you wouldn't want to weed out all of the duplicates from different distributions putting out seperate advisories, now would you? And AFAIK FreeBSD doesn't put out advisories for things in ports, do they?
Wow and look at that, according to Secunia Debian hasn't had a security advisory since 2003!
$ make search key=adaptec Port: aaccli-1.0 Path: /usr/ports/sysutils/aaccli
Info: Adaptec SCSI RAID administration tool
Maint: bms@FreeBSD.org
B-deps:
R-deps:
WWW: http://support.dell.com/ [dell.com]
Port: asr-utils-3.04
Path: /usr/ports/sysutils/asr-utils
Info: Adaptec ASR RAID Management Software
Maint: obrien@FreeBSD.org
B-deps: compat4x-i386-5.3 expat-1.95.8 fontconfig-2.2.3,1 freetype2-2.1.9 pkgconfig-0.15.0_1 xorg-libraries-6.8.2
R-deps: compat4x-i386-5.3 expat-1.95.8 fontconfig-2.2.3,1 freetype2-2.1.9 pkgconfig-0.15.0_1 xorg-libraries-6.8.2
WWW:
So? What about Oracle support? Or Fiber channel adapters? Is Secure Path supported?
You've been looking at the wrong benchmarks. Linux only recently beated FreeBSD on benchmarks, by very few points, stable kernel vs development FreeBSD version.
Which benchmarks are you talking about?
Of course you don't see the point. Now try to run mandriva-specific stuff on 3 more distributions and you'll see why it's good to have a centered, working environment instead of 500 distros that consist on the linux kernel + 300 apps thrown in. As you said, software for FreeBSD works on FreeBSD. But you can't say the same on linux. What with every distro having its own directories, lib versions, and so on, it's kind of impossible to pack one software piece for the X different versions of the same kernel . Enlightened now ?
There's nothing to be enlightenend about, you run Mandriva packages because you want to run what they've packaged and support. You wouldn't install a NetBSD package on FreeBSD and then complain because it didn't work, right? And if for some reason you really don't want to run the Mandriva package you can compile it yourself, there's nothing stopping you from doing that.
Your broad knowledge seems to know only web and mailservers. Sorry to disappoint you, there is lots of software for other server applications around. And I'd rather run them on any BSD than on Linux.
But why? The performance difference isn't large either way. Security is equal if you know what you're doing. The only thing you get by choosing FreeBSD is a shitty package management system and no official support.
I'm giving you a single example out of many I could think of right now.. who had preemption first, who is copying it now ?
FreeBSD 5.0 was released in 2003, I see Linux kernel premption work going on in 2001 with a quick google search. And AFAIK FreeBSD 5.x still has many places where the GIANT lock is used which kills preemption.
ah, another. Who had the port systems, who tried to copy it to linux ? *cof*gentoo*cof*
Just because someone copied it, doesn't mean it's good. Portage, and Gentoo in general IMO, is crap and the ports tree in FreeBSD is only slightly better.
And with your BSD-init script how do you restart a single service? Sure, a lot will reread their config if you send them a HUP signal but that's not true for all and sometimes a full restart is necessary if you've changed something major like the interfaces a daemon should listen on. With BSD init you can't, you have to kill the daemon and restart it manually, usually requiring you fish through the init script to find the appropriate parameters or just reboot. With Sys-V you just run '/etc/init.d/daemon restart' and you're done.
/etc/init.d directory has under a hundred scripts. While that seems like a lot it's far from enough to slow the system startup/shutdown (when I'm not using swsusp2, which is rare) and grep searches them all for me very fast. If you're opening them all and looking for what you're trying to find, yes that's a lot of files and it'll be slow, but blame yourself for not knowing the tools.
And there's far from a zillion scripts, on my laptop here my
Generally it doesn't exist for anyone anymore, RH has had up2date for years, FC comes with yum, apt works fine with RPMs as long as you have a repo to install from. Personally I use Debian because the package quality is much higher than any other distro I tried, not that I've had a reason to try any in the last few years.
Flawlessly? I must have missed the announcement that Gentoo put out when they released bug-free development.
Think about it in the other direction. Because there's no dependency checking you can do something stupid like remove GTK and break all of your Gnome apps and Gentoo will just stare blankly back at you without even a warning. Sure you can just reinstall GTK, but what if you remove something system-level important like glibc or part of python that portage needs?
Why would anyone be troubled by compiling something one any distro but Gentoo? Every distribution is compiled somewhere, for RPM based distros all you need is the src.rpm and you can recompile the package with ease. For Debian you can 'apt-get source' to get the source package and rebuild that or you can use apt-build to rebuild as much as you want with 1 command.
Except that portage is slow and lacks many package management features that binary package users are used to having, basic things like dependency checking on package removal.
And doesn't that defeat the purpose? The big packages are the ones that have the best chance of having a noticable speed difference with the proper configuration/compilation switches. Who cares if coreutils is compiled for my machine, ls runs the same pretty much, no matter what.
So pkgsrc is maintained seperate from NetBSD? And what kind of QA is done on pkgsrc packages?
I've never used pkgsrc so I don't have any idea why it would be better, care to explain?
How easy is it to port the entire apt/dpkg packages tree to a new operating system?
If you mean the packages themselves, not much if the infrastructure is setup. Meaning apt, dpkg, debconf, etc is installed on the host system. There are already people working on Debian GNU/KFreeBSD.
Debian packages are pretty much tied to Debian, it's a downside of the system being so integrated and well done.
I've got sarge on an Ultra2 right now with no problems. Once in a while a package is broken, but that's what apt-listbugs is for, that way you can avoid breakage and just wait a few days while the bug is fixed.
There are many levels of support and Gentoo's is nowhere near as complete as what Debian does.
In the last thread I read the amount of architectures couldn't be proven to be a real point of delay. The only thing it had a noticable affect on was d-i development, most packages work just fine on all architectures and with the current buildd system they're autobuilt so no additional work is needed by the maintainer.
Gentoo can get releases out quickly because they do virtually no QA.
98% of 15,000 is 14700.00, if 300 packages don't even compile it probably doesn't make sense to release it. Of course what packages don't compile needs to be evaluated, but in general I think 98% is achievable.
NetBSD doesn't maintain and do QA for 15,000+ packages for each arch either.