linux-kernel - Re: Thinking outside the box on file systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Aug 2007 16:11:44 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
Cc:	Marc Perkel <mperkel@...oo.com>,
	Michael Tharp <gxti@...tiallystapled.com>,
	alan <alan@...eserver.org>,
	LKML Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Thinking outside the box on file systems

On Aug 15, 2007, at 15:26:07, Lennart Sorensen wrote:
> On Wed, Aug 15, 2007 at 10:59:12AM -0700, Marc Perkel wrote:
>> When one thinks outside the box one has to think about evolving  
>> beyond what you are used to. When I moved
>> beyond DOS I have to give up the idea of 8.3 file names. The idea  
>> here is to come up with a model that can emulate the existing  
>> system for backwards compatibility.
>
> But moving beyond 8.3 didn't prevent you from still using 8.3 names  
> if you wanted too.  Longer file names are just an extension of  
> shorter ones.

As another example, take a look at "git", the SCM we use for the  
kernel, as contrasted with the older CVS.  You can import your  
complete CVS history into it without data loss, and then you can even  
continue to use it the exact same way you used to use CVS, with some  
slight differences in command-line syntax.  Once you are ready to  
move further, though, you can create multiple local branches to have  
your co-workers pull from to test changes.  You discover that merging  
branches is much easier in git than in CVS.  Your company starts to  
use a more distributed development model, they implement a policy  
telling developers to break up their changes into smaller pieces and  
write better change-logs.  Somebody suddenly discovers the ability to  
"sign" a particular release version with a private key, and you start  
doing that as part of your release management to ensure that the  
codebase marked with a client tag is the exact same one you actually  
shipped to that client.

On a fundamental level, GIT is a completely different paradigm from  
CVS.  Its internal operations are entirely differently organized, it  
uses different algorithms and different storage formats.  The end  
result of that is that it's literally orders of magnitude faster on  
large codebases.  But to the USER it can be used exactly the same;  
you could even write a little CVS-to-GIT wrapper which imported your  
CVS into a git repo and then let you operate on it using "gcvs"  
commands the same way you would have operated on real CVS repositories.

Just some food for thought

Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/