Re: Versioning file system
On Sat, Jun 16, 2007 at 11:17:58PM +0100, Alan Cox wrote: > > (Vax/VMS System Software Handbook) > > (TOPS-20 User's Manual) > > Also Files/11 And don't forget the really ground breaking work (for the time) done by the Xanadu folk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Versioning file system
On Sat, Jun 16, 2007 at 11:17:58PM +0100, Alan Cox wrote: (Vax/VMS System Software Handbook) (TOPS-20 User's Manual) Also Files/11 And don't forget the really ground breaking work (for the time) done by the Xanadu folk. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Versioning file system
DEC had versioning files systems 30 years ago. Any patents on their style must certainly have expired long ago. Look at RSX-11 and other seventies era operating systems. This is ancient stuff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Versioning file system
DEC had versioning files systems 30 years ago. Any patents on their style must certainly have expired long ago. Look at RSX-11 and other seventies era operating systems. This is ancient stuff. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote: > >The error also happens in 2.6.19, same as in 2.6.18. > >I extracted this from syslog: > >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): > >ufs_check_page: bad entry > > Is this happened also with this patch: > http://lkml.org/lkml/diff/2007/2/5/75/1 > ? > > -- > /Evgeniy I tried the patch but it would not apply to 2.6.20.7 and appeared to already exist in that release as patch was asking me about reversing the patch. So I just built a vanilla version: Linux otv2 2.6.20.7-i686 #1 SMP Tue Apr 17 02:33:19 BST 2007 i686 GNU/Linux and then tried the mount again: otv2:/dma/FloppyDisks-3.50# mount -t ufs -o ro,ufstype=nextstep,loop NeXT-Diagram1-fd0a.ufs /floppy otv2:/dma/FloppyDisks-3.50# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 8649576 5141412 3068788 63% / tmpfs 128128 0128128 0% /lib/init/rw udev 1024060 10180 1% /dev tmpfs 128128 0128128 0% /dev/shm /dma/FloppyDisks-3.50/NeXT-Diagram1-fd0a.ufs 1255 118471 95% /media/floppy0 otv2:/dma/FloppyDisks-3.50# ls /floppy ls: reading directory /floppy: Input/output error I find in syslog: Apr 19 17:34:29 localhost kernel: UFS-fs error (device loop0): ufs_check_page: bad entry in directory #2: directory entry across blocks - offset=140, rec_len=884, name_len=7 Apr 19 17:34:29 localhost kernel: UFS-fs error (device loop0): ufs_readdir: bad page in #2 I would be happy to supply you with an image of the NeXT /dev/fd0a floppy partition if you would like, or even a full image of the floppy made via the NeXT raw device /dev/rfd0b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote: The error also happens in 2.6.19, same as in 2.6.18. I extracted this from syslog: Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_check_page: bad entry Is this happened also with this patch: http://lkml.org/lkml/diff/2007/2/5/75/1 ? -- /Evgeniy I tried the patch but it would not apply to 2.6.20.7 and appeared to already exist in that release as patch was asking me about reversing the patch. So I just built a vanilla version: Linux otv2 2.6.20.7-i686 #1 SMP Tue Apr 17 02:33:19 BST 2007 i686 GNU/Linux and then tried the mount again: otv2:/dma/FloppyDisks-3.50# mount -t ufs -o ro,ufstype=nextstep,loop NeXT-Diagram1-fd0a.ufs /floppy otv2:/dma/FloppyDisks-3.50# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 8649576 5141412 3068788 63% / tmpfs 128128 0128128 0% /lib/init/rw udev 1024060 10180 1% /dev tmpfs 128128 0128128 0% /dev/shm /dma/FloppyDisks-3.50/NeXT-Diagram1-fd0a.ufs 1255 118471 95% /media/floppy0 otv2:/dma/FloppyDisks-3.50# ls /floppy ls: reading directory /floppy: Input/output error I find in syslog: Apr 19 17:34:29 localhost kernel: UFS-fs error (device loop0): ufs_check_page: bad entry in directory #2: directory entry across blocks - offset=140, rec_len=884, name_len=7 Apr 19 17:34:29 localhost kernel: UFS-fs error (device loop0): ufs_readdir: bad page in #2 I would be happy to supply you with an image of the NeXT /dev/fd0a floppy partition if you would like, or even a full image of the floppy made via the NeXT raw device /dev/rfd0b. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
On Mon, Apr 16, 2007 at 05:04:22PM +0100, Dale Amon wrote: > On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote: > > >The error also happens in 2.6.19, same as in 2.6.18. > > >I extracted this from syslog: > > >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): > > >ufs_check_page: bad entry > > > > Is this happened also with this patch: > > http://lkml.org/lkml/diff/2007/2/5/75/1 > > Thanks. I will try that out tonight GMT. Which kernel > is that against? Will it work against a 2.6.19 or should > I get a 2.6.20 and work with that? Hmmm... looks like that patch is already applied in a 2.6.20.7? I will try that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote: > >The error also happens in 2.6.19, same as in 2.6.18. > >I extracted this from syslog: > >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): > >ufs_check_page: bad entry > > Is this happened also with this patch: > http://lkml.org/lkml/diff/2007/2/5/75/1 Thanks. I will try that out tonight GMT. Which kernel is that against? Will it work against a 2.6.19 or should I get a 2.6.20 and work with that? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote: The error also happens in 2.6.19, same as in 2.6.18. I extracted this from syslog: Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_check_page: bad entry Is this happened also with this patch: http://lkml.org/lkml/diff/2007/2/5/75/1 Thanks. I will try that out tonight GMT. Which kernel is that against? Will it work against a 2.6.19 or should I get a 2.6.20 and work with that? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
On Mon, Apr 16, 2007 at 05:04:22PM +0100, Dale Amon wrote: On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote: The error also happens in 2.6.19, same as in 2.6.18. I extracted this from syslog: Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_check_page: bad entry Is this happened also with this patch: http://lkml.org/lkml/diff/2007/2/5/75/1 Thanks. I will try that out tonight GMT. Which kernel is that against? Will it work against a 2.6.19 or should I get a 2.6.20 and work with that? Hmmm... looks like that patch is already applied in a 2.6.20.7? I will try that. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
The error also happens in 2.6.19, same as in 2.6.18. I extracted this from syslog: Apr 17 00:14:08 kdev kernel: loop: loaded (max 8 devices) Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_check_page: bad entry in directory #2: directory entry across blocks - offset=356, rec_len=668, name_len=19 Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_readdir: bad page in #2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ufs nextstep in 2.6.18 (debian)
The error also happens in 2.6.19, same as in 2.6.18. I extracted this from syslog: Apr 17 00:14:08 kdev kernel: loop: loaded (max 8 devices) Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_check_page: bad entry in directory #2: directory entry across blocks - offset=356, rec_len=668, name_len=19 Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_readdir: bad page in #2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with ufs nextstep in 2.6.18 (debian)
I recently noticed that I can no longer read my images of NeXTstep floppies on certain machines. All are running an up to date etch distribution but the difference between where I can read or not read seems to be the linux version. On a 2.6.18 machine: # mount -t ufs -o ro,ufstype=nextstep,loop nextfloppy-fd0a.ufs /floppy # ls /floppy ls: reading directory /floppy: Input/output error On a 2.6.13 machine it still works fine: # mount -t ufs -o ro,ufstype=nextstep,loop nextfloppy-fd0a.ufs /floppy # ls /floppy/ private # ls /floppy/private Drivers Have there been any recent changes that would cause a breakage in this area? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with ufs nextstep in 2.6.18 (debian)
I recently noticed that I can no longer read my images of NeXTstep floppies on certain machines. All are running an up to date etch distribution but the difference between where I can read or not read seems to be the linux version. On a 2.6.18 machine: # mount -t ufs -o ro,ufstype=nextstep,loop nextfloppy-fd0a.ufs /floppy # ls /floppy ls: reading directory /floppy: Input/output error On a 2.6.13 machine it still works fine: # mount -t ufs -o ro,ufstype=nextstep,loop nextfloppy-fd0a.ufs /floppy # ls /floppy/ private # ls /floppy/private Drivers Have there been any recent changes that would cause a breakage in this area? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reiser4. BEST FILESYSTEM EVER.
Jan does have a point about bad blocks. A couple years ago I had a relatively new disk start to go bad on random blocks. I detected it fairly quickly but did have some data loss. All the compressed archives which were hit were near total losses; most other files were at least partially recoverable. It is not a matter of your operating system writing to bad blocks. It is a matter of what happens when the blocks on which your data sit go bad underneath you. This issue has also been discussed by people working with revision control system. If you are archiving data, how do you know you if your data is still good unless you actually need it? If you do not know it is bad, you may well get rid of good copies thinking you do not need the extras... it does happen. I would be quite hesitant to go with on disk compression unless damage was limited to only the bad bits or blocks and did not propagate through the rest of the file. Perhaps if everyone used hardware RAID and the RAID automatically detected a difference due to trashed data on one disk and flagged the admin with a warning... BTW: I'm a CMU Alum, so who are you working with Jan? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reiser4. BEST FILESYSTEM EVER.
Jan does have a point about bad blocks. A couple years ago I had a relatively new disk start to go bad on random blocks. I detected it fairly quickly but did have some data loss. All the compressed archives which were hit were near total losses; most other files were at least partially recoverable. It is not a matter of your operating system writing to bad blocks. It is a matter of what happens when the blocks on which your data sit go bad underneath you. This issue has also been discussed by people working with revision control system. If you are archiving data, how do you know you if your data is still good unless you actually need it? If you do not know it is bad, you may well get rid of good copies thinking you do not need the extras... it does happen. I would be quite hesitant to go with on disk compression unless damage was limited to only the bad bits or blocks and did not propagate through the rest of the file. Perhaps if everyone used hardware RAID and the RAID automatically detected a difference due to trashed data on one disk and flagged the admin with a warning... BTW: I'm a CMU Alum, so who are you working with Jan? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Idea: Encryption plugin architecture for file-systems
On Mon, Apr 23, 2001 at 09:54:34PM -0500, David L. Nicol wrote: > why not port one of the twenty or thirty preexisting tools > that let you mount a filesystem from an encrypted file instead > of making a generic layer? That way you could have inter-os > portability. The steganographic ones make really impressive > claims. I'm doing an 18GB raid file system. The standard loopback is working fine. What I am unsure of is the bobustness against lost blocks when running "on the metal" vs interposing another file system layer. I suspect the answer is that each block is individually encrypted, so that the worst case data loss is the same; that an ext2 on top of an encrypted partition would be no worse off than the same file system without the interposed layer. Both would find a bad block and do their best. But my knowledge of how the loopbacks are structured is not good enough for me to say this with confidence. That's why I'm asking here: in hopes that someone who really does know can say something about the worst case data loses. -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Idea: Encryption plugin architecture for file-systems
On Mon, Apr 23, 2001 at 09:54:34PM -0500, David L. Nicol wrote: why not port one of the twenty or thirty preexisting tools that let you mount a filesystem from an encrypted file instead of making a generic layer? That way you could have inter-os portability. The steganographic ones make really impressive claims. I'm doing an 18GB raid file system. The standard loopback is working fine. What I am unsure of is the bobustness against lost blocks when running on the metal vs interposing another file system layer. I suspect the answer is that each block is individually encrypted, so that the worst case data loss is the same; that an ext2 on top of an encrypted partition would be no worse off than the same file system without the interposed layer. Both would find a bad block and do their best. But my knowledge of how the loopbacks are structured is not good enough for me to say this with confidence. That's why I'm asking here: in hopes that someone who really does know can say something about the worst case data loses. -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Idea: Encryption plugin architecture for file-systems
Talk about syncronicity... I had just last week asked about the pro's and con's on this on the crypto list and have heard nothing at all back. So I'll drop the body of that message in here: -- I've got a crypto loopback running directly on a /dev/md0 partition and then the file system on top of that. I'm interested in what the feelings of others are on the trade offs of doing it this way. Is there something to be gained by adding a file system layer between the /dev/md0 and the loopback file as far as error recovery is concerned? Do I actually gain performance (as I am guessing currently that I do) by eliminating one layer? It's just a plaything right now, but I'd be interested in some feedback on the wisdom of it before I actually use this on something important. So just to reiterated: fs fsc. loopback c. loopback vsfs raid1raid1 disk disk disk disk where fs = ext2 until this evening when I replace it with reiserfs. -- And update by saying I've got reiserfs working on top of it with no problems. But I'm still just that wee bit nervous about the approach even though it works. What happens if I get one bad disk sector in a partition? What is the difference in data loss between encrypting on the bare partition versus having say, a reiserfs under you? (Obviously RAID doesn't save you. It will just merrily reproduce the bad sector on the mirror disk) -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Has the iptables security patch been vetted?
I'm sure you've run across this one: http://netfilter.samba.org/security-fix/ I'd like to know how official this patch is, ie how well checked out? I'd hardly want to cure one problem and create another. And I'm uncomfortable with it at first glance: I'd have to find figure out why it is returning immediate success at that point, or rather prove to myself that it is just skipping making the bad table entries. -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Your response is requested
On Tue, Apr 17, 2001 at 12:34:36PM -0700, J Sloan wrote: > [EMAIL PROTECTED] wrote: > > > Dear Friend: > > > > YOU CAN make over a half million dollars every 4 to 5 months from > > your home for a one time investment of only twenty five U.S. > > Dollars. > > This did not originate from toyota.com - The spammer simply > used that domain as the "from" hostname. We are careful > about mail server security here, there is no open relay. > Yeah, I saw it to with *MY* domain on it and near had a fit! -- ------ Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Your response is requested
On Tue, Apr 17, 2001 at 12:34:36PM -0700, J Sloan wrote: [EMAIL PROTECTED] wrote: Dear Friend: YOU CAN make over a half million dollars every 4 to 5 months from your home for a one time investment of only twenty five U.S. Dollars. This did not originate from toyota.com - The spammer simply used that domain as the from hostname. We are careful about mail server security here, there is no open relay. Yeah, I saw it to with *MY* domain on it and near had a fit! -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Idea: Encryption plugin architecture for file-systems
Talk about syncronicity... I had just last week asked about the pro's and con's on this on the crypto list and have heard nothing at all back. So I'll drop the body of that message in here: -- I've got a crypto loopback running directly on a /dev/md0 partition and then the file system on top of that. I'm interested in what the feelings of others are on the trade offs of doing it this way. Is there something to be gained by adding a file system layer between the /dev/md0 and the loopback file as far as error recovery is concerned? Do I actually gain performance (as I am guessing currently that I do) by eliminating one layer? It's just a plaything right now, but I'd be interested in some feedback on the wisdom of it before I actually use this on something important. So just to reiterated: fs fsc. loopback c. loopback vsfs raid1raid1 disk disk disk disk where fs = ext2 until this evening when I replace it with reiserfs. -- And update by saying I've got reiserfs working on top of it with no problems. But I'm still just that wee bit nervous about the approach even though it works. What happens if I get one bad disk sector in a partition? What is the difference in data loss between encrypting on the bare partition versus having say, a reiserfs under you? (Obviously RAID doesn't save you. It will just merrily reproduce the bad sector on the mirror disk) -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
General interest: lawyers talking about GPL and Linux
__ "Legal Implications of Open-Source Software" University of Illinois Law Review, Forthcoming BY: DAVID MCGOWAN University of Minnesota Law School Contact: DAVID MCGOWAN Email: Mailto:[EMAIL PROTECTED] Postal: University of Minnesota Law School 229 19th Avenue South Minneapolis, MN 55455 USA ABSTRACT: This article examines some legal and economic aspects of software produced under licenses that provide for distribution of source code and allow downstream users to copy, modify, and redistribute code. The article focuses in particular on the General Public License (GPL), which grants permission to engage in such activities on the condition that downstream users make their own works available on the same terms on which they received the code. Production under this model is informal compared to production in conventional firms. Persons who work on projects utilizing these licenses do not receive wages from those who initiate or maintain the projects. This model therefore poses questions about traditional assumptions of agent behavior that characterize the Theory of the Firm literature. This article first analyzes the agency question and contends that classifying software by license terms provides an incomplete understanding of this form of production. The social structures necessary to sustain production vary depending upon the complexity, and therefore cost, of different projects; the market position of different projects is relevant as well. Production of simple, low-cost projects may require little if any coordination and therefore little if any hierarchy. Production of complex projects, such as the GNU/Linux operating system, require coordination and are in fact characterized by hierarchy. The article discusses the social factors that have thus far supported these hierarchies. The article also analyzes the reciprocal licensing model of the GPL, and discusses various issues relevant to its enforceability under existing copyright and contract law. --- -- -- Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
General interest: lawyers talking about GPL and Linux
__ "Legal Implications of Open-Source Software" University of Illinois Law Review, Forthcoming BY: DAVID MCGOWAN University of Minnesota Law School Contact: DAVID MCGOWAN Email: Mailto:[EMAIL PROTECTED] Postal: University of Minnesota Law School 229 19th Avenue South Minneapolis, MN 55455 USA ABSTRACT: This article examines some legal and economic aspects of software produced under licenses that provide for distribution of source code and allow downstream users to copy, modify, and redistribute code. The article focuses in particular on the General Public License (GPL), which grants permission to engage in such activities on the condition that downstream users make their own works available on the same terms on which they received the code. Production under this model is informal compared to production in conventional firms. Persons who work on projects utilizing these licenses do not receive wages from those who initiate or maintain the projects. This model therefore poses questions about traditional assumptions of agent behavior that characterize the Theory of the Firm literature. This article first analyzes the agency question and contends that classifying software by license terms provides an incomplete understanding of this form of production. The social structures necessary to sustain production vary depending upon the complexity, and therefore cost, of different projects; the market position of different projects is relevant as well. Production of simple, low-cost projects may require little if any coordination and therefore little if any hierarchy. Production of complex projects, such as the GNU/Linux operating system, require coordination and are in fact characterized by hierarchy. The article discusses the social factors that have thus far supported these hierarchies. The article also analyzes the reciprocal licensing model of the GPL, and discusses various issues relevant to its enforceability under existing copyright and contract law. --- -- -- Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Crypto patches for losetup
I'm trying to update some patches of Harald's to work with the official 2.4.0 international patches. He had a very nice unofficial patch set that doesn't use a table, it just sees what is in /proc/crypto. I fixed a few bugs and it worked marvelously with unofficial test9 patches all the way up to t12. However the official patches have changed the data structure underlying the "files", ie /proc/crypto/cipher/twofish-ecb no longer has int t_id; it has int t_flags instead. And it isn't just a name change, it does something entirely different. Since Harald's code depended on predefined id's in the international patches, that broke it pretty thoroughly. I'm looking at them to see if I can excise that dependance entirely. I think I can, but I'd like someone who I could chat with about some of the underlying reasons for certain things being there. Harald is busy with other things and can't take time off to refresh himself on the contents of the patch-int's enough to help. I'm working on some mods now but I can see a couple ways to go and I'd rather pick the right one first time. Please contact me directly, [EMAIL PROTECTED]; since the LK-digest went away I've been finding I often (mostly?) miss things in the flood of thousands of itty bitty messages :-) -- -- Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Crypto patches for losetup
I'm trying to update some patches of Harald's to work with the official 2.4.0 international patches. He had a very nice unofficial patch set that doesn't use a table, it just sees what is in /proc/crypto. I fixed a few bugs and it worked marvelously with unofficial test9 patches all the way up to t12. However the official patches have changed the data structure underlying the "files", ie /proc/crypto/cipher/twofish-ecb no longer has int t_id; it has int t_flags instead. And it isn't just a name change, it does something entirely different. Since Harald's code depended on predefined id's in the international patches, that broke it pretty thoroughly. I'm looking at them to see if I can excise that dependance entirely. I think I can, but I'd like someone who I could chat with about some of the underlying reasons for certain things being there. Harald is busy with other things and can't take time off to refresh himself on the contents of the patch-int's enough to help. I'm working on some mods now but I can see a couple ways to go and I'd rather pick the right one first time. Please contact me directly, [EMAIL PROTECTED]; since the LK-digest went away I've been finding I often (mostly?) miss things in the flood of thousands of itty bitty messages :-) -- -- Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Secure Linux
On Tue, Jan 30, 2001 at 11:55:17AM -0800, David D.W. Downey wrote: > > > Hey Dale, got a URL for this? Now *I* am intrigued! > > > David D.W. Downey > RHCE > http://www.nsa.gov/selinux/ -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Secure Linux
On Tue, Jan 30, 2001 at 11:55:17AM -0800, David D.W. Downey wrote: Hey Dale, got a URL for this? Now *I* am intrigued! David D.W. Downey RHCE http://www.nsa.gov/selinux/ -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Secure Linux
Has anyone else signed up on the NSA's secure Linux discussion list? The idea of NSA backing the development of a secure GPL'd linux is one I find intriguing. However I have only seen one posting. Is there anyone "real" involved with it? -- -- Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Secure Linux
Has anyone else signed up on the NSA's secure Linux discussion list? The idea of NSA backing the development of a secure GPL'd linux is one I find intriguing. However I have only seen one posting. Is there anyone "real" involved with it? -- -- Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
