If the include file contains macros, inlines, and stuff like that, then you're correct. But the traditional include file contains only function prototypes. The compiled object file will contain references to the functions, but will not contain any actual code from the library. References do not derivation make.
I would do that, except that the FSF doesn't believe in freedom. The freest you can get source code is the public domain, but the FSF does not want you to release code under the public domain, particularly their specially copyrighted stuff.
In fact, the FSF doesn't even want to achieve their goals. You see, if they got their stated wishes, and all copyright laws were rescinded, the whole concept of copyleft would instantly evaporate. You would no longer be required to distribute the sources to gcc on demand to those you gave the binaries to. You could link to libreadline without placing your application under the GPL.
It's sort of like an organization arguing against land ownership, who came up with a boilerplate deed called "propertyleft" that attempts to abolish the building of fences. But if they ever got their way, their deeds would be meaningless and people would be free to build fences all over the place, including on land that was previously owned by the Free Property Foundation.
"Use this, modify this, just don't hide this if you change this"
But I haven't changed it! I'm only linking to it dynamically at runtime! Yet you still insist that I license my application under your choice of license.
Code released under it is essentally ending up as work done for free for corporations.
And how exactly is that different from the GPL? Everything I place under the GPL is work done for free for corporations like Redhat, SuSE, IBM, SCO, etc. Redhat was being nice when they gave Linus some shares of stock. But they were under absolutely no obligation to do so.
If you're going to use [L]GPL'd code, follow the terms of the license, or don't use it.
But the GPL is indeed viral, because the license because when it comes to libraries, it makes no distinction between use and derivation.
In the case of non-library code, I only have to follow the GPL if I modify or distribute the code. It is not viral in this case. But a library is different, because the FSF considers any form of linkage to be derivation.
The GPL says I have to supply the source code to anyone I distribute a GPLd library to. But wait! I'm not distributing the library to anyone! I'm only distributing my application that links to it dynamically at runtime! If this were a case of static linkage, it would be a different story. It still would not be derivation, but it would be distribution.
The GPL is viral because its common interpretation, including the interpretation of the FSF, goes beyond copyright law and effects regulations on non-derivative works. If you still think linkage is derivation, let me quote from USC 17 Section 101:
A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''.
My application is not a recasting, transformation or adaptation of the GPL library. It contains no editorial revisions, annotations, elaborations or other modifications to the library.
Larry Rosen makes the point clearly in his article "Derivative Works"
ESR an egoist? Not at all, don't confuse egoism with egotism. All egoists are egotists, but not all egotists are egoists. And most certainly, not all gun-toting neopagan libertarians are Ayn Rand worshipping objectivists.
There are a few reasons why this isn't done by default. First, portupgrade is not a part of the base system. Second, due to a chronic lack of space, there is not -STABLE ports tree, so automatically updating your ports could result in a broken system. Three, one size never fits all.
Fourth, you need to understand the UNIX philosophy. In a nutshell it is "many small tools that do only one thing, but do them well." cvsup is a small tool that does one thing well. portupgrade is a small tool that does one thing well. Making either of them do the job of the other is not right.
It took me three minutes to write the aforementioned script. Maybe FreeBSD could have saved everyone three minutes by including a similar script as a weekly cron job. But that ignores the fact that different users will want to use different cvsup servers, and that the servers will want people accessing them at different times. Imagine what the various goverment security agencies around the world would think if they saw a massive bandwidth usage spike every Monday at 2300 GMT!
And of course, some people won't want to update everything. Some people won't want to update anything at all (don't fix it if it ain't broken). Then you have those people who can't use cvsup (like I can't at work because of a firewall)
Wait seventy five years or so. Then Linux 0.97 and FreeBSD 1.0 will be in the public domain.
The sole purpose of the BSD license is to keep the warranty disclaimer attached. This is necessary for the legal health of the developers and distributors. Otherwise it's the next best thing to public domain.
Do you know whether it will pose a major issue that the code is GPL'd in terms of FreeBSD adoption? I'd tend to doubt that the BSD guys would bless GPL code in terms of mainstream integration into the BSD kernel
The GPL would keep it from being a required component. But there's no reason it can't be an optional kernel module. The only requirement would be that the license not "taint" any other code in the kernel.
If cvsup is so trivial, why do I have to figure it out?
Sigh. Hopefully this will get past the lameness filter:
#!/bin/sh echo "Quick-N-Dirty script to update all your installed ports" echo "slurping down the new stuff..." cvsup/usr/share/examples/cvsup/ports-supfile echo "rebuilding the ports database..." portsdb -Uu echo "building all updated ports..." portupgrade --all echo "done!"
Let's see, how many commercial linux distros are there? If something's appended to the version number, it's a fork. Fortunately, if a new kernel feature proves useful or popular, Linus lets it in. Otherwise there would be a reign of confusion.
The BSD forks are of a different kind. NetBSD and FreeBSD forked off the same codebase (386BSD) simply because neither project was aware of the other until too late. OpenBSD forked off primarily because of personality conflicts. There's no compelling need (that I can see) for OpenBSD security auditing to be done in a fork distinct from NetBSD. Darwin isn't really a fork so much as it's the next generation NeXT updated with FreeBSD instead of the obsolete 4.3BSD.
DragonflyBSD may have been sparked by personality conflicts (fortunately they're keeping the dirty laundry in a locked hamper), but it's going to have substantial kernel and userland changes that need a fork just to be worked on.
The copyright notice is STILL required. Only the advertising requirement was dropped. Which means they no long have to loudly announce the fact that they used the code, but that they are still forbidden from hiding that fact.
Try out UFS2 with softupdates. Unpacking the full ports tree used to take ten minutes. Now it takes one.
Speed, space efficiency, crash safety. That's why ReiserFS is good today.
But what about tomorrow? What about all those gee-whiz featurettes that article was talking about? Will those gain me any real benefits? And will it ever be ported to anything besides the Linux? A filesystem that will only work with one kernel is as bad as a kernel that will only work with one CPU.
That's why I said to use to pretuned huffman tree. It doesn't stress the CPU, and you can use it on your first byte. It won't work for just any random XML stream, but you can tune it for the stuff you have control over. In fact, if you are considering a roll-your-own binary format, you already have control over both ends.
Maybe it's time someone wrote an intelligent pre-parser. Take a cursory look at the XML and pass it on to an appropriate parser based on encoding, DTD, size, etc. Or run the document through a pipeline, where every single request takes longer to process, but you can several in the pipe at the same time.
There's no reason there has to be a single heroic XML parser that does everything.
Re:How did a dying OS make it past Linuxtag securi
on
NetBSD At Linuxtag
·
· Score: 2, Insightful
The "bazaar" is a misunderstood and misapplied metaphor that ESR came up with once when he was drunk. It's not an anarchic free-for-all. Every time there's been an open commit policy for a project it crashed and burned.
If you want your code in the Linux kernel, it must go through Linus Torvalds. If you want code in any official GNU project, you must sign a copyright assignment statement and follow the strict rules.
When you can explain to the ext2 developers (and the UFS guys as well) how to get the benefits of ReiserFS' dancing tree algorithms, don't post to Slashdot, go directly to the developers.
I'm still waiting for someone to explain to me the benefits of this algorithm. I'm sure they're there, and some people will need them, but I still don't understand how it benefits me in the way I use the filesystem, as compared to other solutions providing similar benefits.
Until you can present a solution which allows UFS to cope QUICKLY with 50,000 files in a single directory, I'm in doubt.
Most people aren't going to have 50,000 files in a single directory, just like most people don't drive Ferraris. Until you can explain to me how a Ferrari is going to benefit my daily commute to work, I'll stick with my slow pokey Dodge. Ditto for reiserfs. If I was using Linux, I would by all means prefer reiserfs over ext2, but that's only because ext2 is totally inadequate for my needs.
And when the time comes that I need to QUICKLY access 50,000 files, I'll use a database instead of a filesystem.
You mean FreeBSD built ACL support into a slow filesystem in a way that didn't allow for future research and expansion of security models? I'm shocked.
Take a closer look at it. It allows all the future extended attributes you could ever need. Since they're named attributes, it's very flexible. But like reiserfs, EAs are stored in a separate file (shock). This is a wart. It's not the "correct" implementation in the same way that UNIX itself was not correct but Multics was, and the Linux monolithic kernel was not correct but the Hurd microkernel was. ReiserFS is trying to be the "correct" solution, but 95% of the effort put into reiserfs is only going to benefit 5% of the users.
I'll bet FreeBSD has some ACL maintenance commands
Since chmod/chown/chrgrp can't handle ACLs, or any other extended attribute, of course it does!
I've spent every minute of available free time for the past two months hacking on my project. I've finally uploaded libfu-3.2.7 final. My eyes don't focus, my girlfriend left me, and my cat stopped leaving dead mice in my slippers. So for the next two months I'm not touching any code.
a single, unified namespace for storing any kind of data
That's not what the Unix filesystem was meant to be. Whoever told you that. "everything is a file" does not mean "unified namespace".
And of course, as with everything, taking stuff to the extreme is extremist. You don't need to make the modification time a part of the file, because it ALREADY is part of the file. And why make a database field a file, when it already exists in the database, which itself is a file?
Hey, let's take this to the logical conclusion! Let's have hardlink between modification time metadata files. And the modification time for the modification time file could be a file as well!
Slashdot Mirror
If the include file contains macros, inlines, and stuff like that, then you're correct. But the traditional include file contains only function prototypes. The compiled object file will contain references to the functions, but will not contain any actual code from the library. References do not derivation make.
I would do that, except that the FSF doesn't believe in freedom. The freest you can get source code is the public domain, but the FSF does not want you to release code under the public domain, particularly their specially copyrighted stuff.
In fact, the FSF doesn't even want to achieve their goals. You see, if they got their stated wishes, and all copyright laws were rescinded, the whole concept of copyleft would instantly evaporate. You would no longer be required to distribute the sources to gcc on demand to those you gave the binaries to. You could link to libreadline without placing your application under the GPL.
It's sort of like an organization arguing against land ownership, who came up with a boilerplate deed called "propertyleft" that attempts to abolish the building of fences. But if they ever got their way, their deeds would be meaningless and people would be free to build fences all over the place, including on land that was previously owned by the Free Property Foundation.
"Use this, modify this, just don't hide this if you change this"
But I haven't changed it! I'm only linking to it dynamically at runtime! Yet you still insist that I license my application under your choice of license.
Code released under it is essentally ending up as work done for free for corporations.
And how exactly is that different from the GPL? Everything I place under the GPL is work done for free for corporations like Redhat, SuSE, IBM, SCO, etc. Redhat was being nice when they gave Linus some shares of stock. But they were under absolutely no obligation to do so.
But the GPL is indeed viral, because the license because when it comes to libraries, it makes no distinction between use and derivation.
In the case of non-library code, I only have to follow the GPL if I modify or distribute the code. It is not viral in this case. But a library is different, because the FSF considers any form of linkage to be derivation.
The GPL says I have to supply the source code to anyone I distribute a GPLd library to. But wait! I'm not distributing the library to anyone! I'm only distributing my application that links to it dynamically at runtime! If this were a case of static linkage, it would be a different story. It still would not be derivation, but it would be distribution.
The GPL is viral because its common interpretation, including the interpretation of the FSF, goes beyond copyright law and effects regulations on non-derivative works. If you still think linkage is derivation, let me quote from USC 17 Section 101:
My application is not a recasting, transformation or adaptation of the GPL library. It contains no editorial revisions, annotations, elaborations or other modifications to the library.
Larry Rosen makes the point clearly in his article "Derivative Works"
What makes this any different than a C/C++ include statement? Yet the FSF still considers the include statement to be an instance of derivation.
ESR an egoist? Not at all, don't confuse egoism with egotism. All egoists are egotists, but not all egotists are egoists. And most certainly, not all gun-toting neopagan libertarians are Ayn Rand worshipping objectivists.
If you take a good hard look at the initial release announcement, you'll see that nowhere is it referred to as "GNU/Linux".
There are a few reasons why this isn't done by default. First, portupgrade is not a part of the base system. Second, due to a chronic lack of space, there is not -STABLE ports tree, so automatically updating your ports could result in a broken system. Three, one size never fits all.
Fourth, you need to understand the UNIX philosophy. In a nutshell it is "many small tools that do only one thing, but do them well." cvsup is a small tool that does one thing well. portupgrade is a small tool that does one thing well. Making either of them do the job of the other is not right.
It took me three minutes to write the aforementioned script. Maybe FreeBSD could have saved everyone three minutes by including a similar script as a weekly cron job. But that ignores the fact that different users will want to use different cvsup servers, and that the servers will want people accessing them at different times. Imagine what the various goverment security agencies around the world would think if they saw a massive bandwidth usage spike every Monday at 2300 GMT!
And of course, some people won't want to update everything. Some people won't want to update anything at all (don't fix it if it ain't broken). Then you have those people who can't use cvsup (like I can't at work because of a firewall)
Wait seventy five years or so. Then Linux 0.97 and FreeBSD 1.0 will be in the public domain.
The sole purpose of the BSD license is to keep the warranty disclaimer attached. This is necessary for the legal health of the developers and distributors. Otherwise it's the next best thing to public domain.
Do you know whether it will pose a major issue that the code is GPL'd in terms of FreeBSD adoption? I'd tend to doubt that the BSD guys would bless GPL code in terms of mainstream integration into the BSD kernel
The GPL would keep it from being a required component. But there's no reason it can't be an optional kernel module. The only requirement would be that the license not "taint" any other code in the kernel.
If cvsup is so trivial, why do I have to figure it out?
/usr/share/examples/cvsup/ports-supfile
Sigh. Hopefully this will get past the lameness filter:
#!/bin/sh
echo "Quick-N-Dirty script to update all your installed ports"
echo "slurping down the new stuff..."
cvsup
echo "rebuilding the ports database..."
portsdb -Uu
echo "building all updated ports..."
portupgrade --all
echo "done!"
but how many linux distros have forked the kernel
Let's see, how many commercial linux distros are there? If something's appended to the version number, it's a fork. Fortunately, if a new kernel feature proves useful or popular, Linus lets it in. Otherwise there would be a reign of confusion.
The BSD forks are of a different kind. NetBSD and FreeBSD forked off the same codebase (386BSD) simply because neither project was aware of the other until too late. OpenBSD forked off primarily because of personality conflicts. There's no compelling need (that I can see) for OpenBSD security auditing to be done in a fork distinct from NetBSD. Darwin isn't really a fork so much as it's the next generation NeXT updated with FreeBSD instead of the obsolete 4.3BSD.
DragonflyBSD may have been sparked by personality conflicts (fortunately they're keeping the dirty laundry in a locked hamper), but it's going to have substantial kernel and userland changes that need a fork just to be worked on.
The copyright notice is STILL required. Only the advertising requirement was dropped. Which means they no long have to loudly announce the fact that they used the code, but that they are still forbidden from hiding that fact.
They took part of the TCP/IP stack. Big fat hairy deal. So did every other OS on the face of the planet, including Linux for a period of time.
Try out UFS2 with softupdates. Unpacking the full ports tree used to take ten minutes. Now it takes one.
Speed, space efficiency, crash safety. That's why ReiserFS is good today.
But what about tomorrow? What about all those gee-whiz featurettes that article was talking about? Will those gain me any real benefits? And will it ever be ported to anything besides the Linux? A filesystem that will only work with one kernel is as bad as a kernel that will only work with one CPU.
That's why I said to use to pretuned huffman tree. It doesn't stress the CPU, and you can use it on your first byte. It won't work for just any random XML stream, but you can tune it for the stuff you have control over. In fact, if you are considering a roll-your-own binary format, you already have control over both ends.
So compress the XML. Since it's text, and usually very regular text, it compresses nicely. A simple pretuned huffman filter will do wonders.
Maybe it's time someone wrote an intelligent pre-parser. Take a cursory look at the XML and pass it on to an appropriate parser based on encoding, DTD, size, etc. Or run the document through a pipeline, where every single request takes longer to process, but you can several in the pipe at the same time.
There's no reason there has to be a single heroic XML parser that does everything.
The "bazaar" is a misunderstood and misapplied metaphor that ESR came up with once when he was drunk. It's not an anarchic free-for-all. Every time there's been an open commit policy for a project it crashed and burned.
If you want your code in the Linux kernel, it must go through Linus Torvalds. If you want code in any official GNU project, you must sign a copyright assignment statement and follow the strict rules.
When you can explain to the ext2 developers (and the UFS guys as well) how to get the benefits of ReiserFS' dancing tree algorithms, don't post to Slashdot, go directly to the developers.
I'm still waiting for someone to explain to me the benefits of this algorithm. I'm sure they're there, and some people will need them, but I still don't understand how it benefits me in the way I use the filesystem, as compared to other solutions providing similar benefits.
Until you can present a solution which allows UFS to cope QUICKLY with 50,000 files in a single directory, I'm in doubt.
Most people aren't going to have 50,000 files in a single directory, just like most people don't drive Ferraris. Until you can explain to me how a Ferrari is going to benefit my daily commute to work, I'll stick with my slow pokey Dodge. Ditto for reiserfs. If I was using Linux, I would by all means prefer reiserfs over ext2, but that's only because ext2 is totally inadequate for my needs.
And when the time comes that I need to QUICKLY access 50,000 files, I'll use a database instead of a filesystem.
You mean FreeBSD built ACL support into a slow filesystem in a way that didn't allow for future research and expansion of security models? I'm shocked.
Take a closer look at it. It allows all the future extended attributes you could ever need. Since they're named attributes, it's very flexible. But like reiserfs, EAs are stored in a separate file (shock). This is a wart. It's not the "correct" implementation in the same way that UNIX itself was not correct but Multics was, and the Linux monolithic kernel was not correct but the Hurd microkernel was. ReiserFS is trying to be the "correct" solution, but 95% of the effort put into reiserfs is only going to benefit 5% of the users.
I'll bet FreeBSD has some ACL maintenance commands
Since chmod/chown/chrgrp can't handle ACLs, or any other extended attribute, of course it does!
Here's the real story:
I've spent every minute of available free time for the past two months hacking on my project. I've finally uploaded libfu-3.2.7 final. My eyes don't focus, my girlfriend left me, and my cat stopped leaving dead mice in my slippers. So for the next two months I'm not touching any code.
That's why you get punctuated equilibrium.
Eeeeh! You need a Yahoo!ID...
a single, unified namespace for storing any kind of data
That's not what the Unix filesystem was meant to be. Whoever told you that. "everything is a file" does not mean "unified namespace".
And of course, as with everything, taking stuff to the extreme is extremist. You don't need to make the modification time a part of the file, because it ALREADY is part of the file. And why make a database field a file, when it already exists in the database, which itself is a file?
Hey, let's take this to the logical conclusion! Let's have hardlink between modification time metadata files. And the modification time for the modification time file could be a file as well!
To be fair though:
/usr/local/bin/konqueror | wc -l
/usr/X11R6/lib/mozilla/mozilla-bin | wc -l
ldd
35
ldd
30
Not a big difference...