* Date: Sun, 19 Aug 2007 03:57:58 +0100
>> don't forget the ACPI interpreter.
>
> YAProof that bogons follow Boze statistics...
or bugons, then.
Why big minds didn't do rdev-like binary patching of the kernel image
with binary ACPI data? Getting such data in (any) userspace would be the
only thi
On 20 Aug 2007, Helge Hafting stated:
> Shooting down bad ideas saves tremendous amounts of work,
> killing an idea at the discussion stage means the idea never
> got to the much more labor-intensive implementation stage.
>
> This don't mean that all new ideas are killed, only the bad ones.
Even t
On Mon, 2007-08-20 at 09:21 -0700, Randy Dunlap wrote:
> so enlighten us. What editor do you use/suggest/push?
Corbet !
-
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/majordom
On Mon, 20 Aug 2007 04:18:21 -0700 (PDT) Marc Perkel wrote:
> My rant on VI is to make a point. That point being
> that when you use an editor that totally sucks then
> it's going to cause you to write code that sucks. It
> going to lower your standards. It's going to create a
> culture where poor
Marc Perkel wrote:
What's the point? People are openly hostile to new
ideas here. I started out nice and laid out my ideas
and you have a bunch of morons who attack anything
new.
People here are not hostile to any new idea. They are
generally hostile to anyone who suggest some
"improvement" th
On Mon, Aug 20, 2007 at 04:18:21AM -0700, Marc Perkel wrote:
> Look at the reality of the situation. Linux is free
> and yey it can't compete with operating systems that
> are paid for. Maybe the reason is that when someone
> point out the something is broken all yopu get is
> justification and exc
On Sat, Aug 18, 2007 at 09:07:05PM -0700, Marc Perkel wrote:
> No Al, there isn't any shortage of arrogance here.
Yes you provide plenty yourself.
> Let me try to repeat what I'm talking about as simply
> as I can.
>
> First - I'm describing a kind of functionality and
> suggesting Linux should
Marc Perkel wrote:
No Al, there isn't any shortage of arrogance here.
Let me try to repeat what I'm talking about as simply
as I can.
First - I'm describing a kind of functionality and
suggesting Linux should have it. I know a lot of it
can be done because much of what I'm suggesting is
already
Kyle Moffett wrote:
One last comment:
50ms to update in-memory dentries would be FRIGGING TERRIBLE!!! Using
Perl, an interpreted language, the following script takes 3.39s to run
on one of my lower-end systems:
for (0 .. 1) {
mkdir "a-$_";
mkdir "b-$_";
rename "a-$_", "b-$_"
On Mon, 20 Aug 2007, Marc Perkel wrote:
>
[Snipped...]
>
> What's the point? People are openly hostile to new
> ideas here. I started out nice and laid out my ideas
> and you have a bunch of morons who attack anything
> new.
[Snopped...]
>
> Marc Perkel
> Junk Email Filter dot com
> http://www.
Hi Marc
What's the point? People are openly hostile to new
ideas here. I started out nice and laid out my ideas
and you have a bunch of morons who attack anything
new.
If you think using subjects like "Thinking out of the box" (implicitely
calling everybody else narrow-minded) and "vi causes
--- Brennan Ashton <[EMAIL PROTECTED]> wrote:
> While i highly support innovation, until i see a
> well layed out
> structure of what exactly you are looking for i have
> a hard time
> expressing any view that are meaningful, could you
> create some kind of
> wiki or summery email (if this is rea
While i highly support innovation, until i see a well layed out
structure of what exactly you are looking for i have a hard time
expressing any view that are meaningful, could you create some kind of
wiki or summery email (if this is really this important to you) most
of us are lazy and have better
[Lurker delurking here: I've seen Marc pull this sort of trick on
multiple mailing lists now and I've had enough. Coming up with
wild ideas, thinking they must be ideas nobody else has ever
considered, and never thinking them through for five minutes is
sort of Marc's hallmark, I'm afraid.]
On
No Al, there isn't any shortage of arrogance here.
Let me try to repeat what I'm talking about as simply
as I can.
First - I'm describing a kind of functionality and
suggesting Linux should have it. I know a lot of it
can be done because much of what I'm suggesting is
already working in Windows a
On Sat, Aug 18, 2007 at 07:03:06PM -0700, [EMAIL PROTECTED] wrote:
> >>I suspect you will find it somewhat hard to convince *anybody* on
> >>this list to put either a regex engine or a Perl interpreter into the
> >>kernel. I doubt you could even get a simple shell-style pattern
> >>matcher in. Fi
On Sat, 18 Aug 2007, Alan wrote:
On Wed, 2007-08-15 at 13:22 -0400, Kyle Moffett wrote:
On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
The idea is that people have permissions - not files. By people I
mean users, groups, managers, applications
etc. One might even specify that there are no p
On Wed, 2007-08-15 at 10:34 -0700, Marc Perkel wrote:
> Keep in mind that this is about thinking outside the
> box. Don't let new ideas scare you.
My cat thinks outside the box all the time. Cleaning it up is a real
pain.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Wed, 2007-08-15 at 13:22 -0400, Kyle Moffett wrote:
> On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
> > The idea is that people have permissions - not files. By people I
> > mean users, groups, managers, applications
> > etc. One might even specify that there are no permission
> > restri
On Sat, Aug 18, 2007 at 09:45:54AM -0700, Marc Perkel wrote:
> Linux isn't going to make progress when people try to
> figure out how to make something NOT work rather than
> to make something work. So if you are going to put
> effort into this then why not try to figure out how to
> get around t
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 17, 2007, at 15:01:48, Phillip Susi wrote:
> > [EMAIL PROTECTED] wrote:
> >> It will become even *more* of a "not that common"
> if the lock will
> >> block moves and ACL changes *across the
> filesystem* for
> >> potentially *minutes* at a
On Aug 17, 2007, at 15:01:48, Phillip Susi wrote:
[EMAIL PROTECTED] wrote:
It will become even *more* of a "not that common" if the lock will
block moves and ACL changes *across the filesystem* for
potentially *minutes* at a time.
It will not take anywhere NEAR minutes at a time to update t
[EMAIL PROTECTED] wrote:
I suspect Kyle is not quite correct - it's probably the case that you don't
have to consider just the in-memory dentries, but *all* the descendent objects
in the entire file system.
If you have a clever proof that on-disk can't *possibly* be affected, feel
free to presen
On Fri, 17 Aug 2007 11:19:21 EDT, Phillip Susi said:
> Kyle Moffett wrote:
>> Problem 1: "updating cached acls of descendent objects": How do you
>> find out what a 'descendent object' is? Answer: You can't without
>> recursing through the entire in-memory dentry tree.
I suspect Kyle is not q
Kyle Moffett wrote:
Problem 1: "updating cached acls of descendent objects": How do you
find out what a 'descendent object' is? Answer: You can't without
recursing through the entire in-memory dentry tree. Such recursion is
lock-intensive and has poor performance. Furthermore, you have to
On Thu, 16 Aug 2007 21:24:22 PDT, Marc Perkel said:
> And then everything that's stored as /1/2/3/4 is still
> the same but the sections resolve to different names.
At that point, you need to go re-think your full-pathname permission scheme,
because that severely broke it.
> I'm sure there are er
Several people have asked about how to mass move a
tree under my idea for a new kind of file system. I
have an idea. Suppose you have the file name as
follies.
/one/two/three/four/file1
Except the are a million files in /four/ named file1
to file100.
We want to move thes files to /seven/six/
On Aug 16, 2007, at 11:09:16, Phillip Susi wrote:
Kyle Moffett wrote:
Let me repeat myself here: Algorithmically you fundamentally
CANNOT implement inheritance-based ACLs without one of the
following (although if you have some other algorithm in mind, I'm
listening):
(A) Some kind of rec
Marc Perkel wrote:
> Yep - way outside the box - and thus the title of the
> thread.
>
> The idea is that people have permissions - not files.
> By people I mean users, groups, managers, applications
> etc. One might even specify that there are no
> permission restrictions at all. Part of the proc
[EMAIL PROTECTED] wrote:
That's how it works *now*.
That's *not* what happens with Marc's "Out of Box filesystem", because you need
to deal with the fact that the pathnames to everything under it just changed.
I think you cross jumped subthreads. I have gone off on a different
topic now real
On Thu, 16 Aug 2007 13:28:26 EDT, Phillip Susi said:
> [EMAIL PROTECTED] wrote:
> > What happens if I do a 'mv /home /home1'? Looks like more than a
> > "relatively
> > small" number. A cold-cache 'find' takes a few minutes to wade through it
> > all,
> > so any solutions you come up with shoul
[EMAIL PROTECTED] wrote:
What happens if I do a 'mv /home /home1'? Looks like more than a "relatively
small" number. A cold-cache 'find' takes a few minutes to wade through it all,
so any solutions you come up with should beware of locking issues...
Then the directory is moved one dentry
On Thu, 16 Aug 2007 11:09:16 EDT, Phillip Susi said:
> No recursion is needed because only one acl exists, so that is the only
> one you need to update. At least on disk. Any cached acls in memory of
> descendant objects would need updated, but the number of those should be
> relatively small
Kyle Moffett wrote:
Let me repeat myself here: Algorithmically you fundamentally CANNOT
implement inheritance-based ACLs without one of the following (although
if you have some other algorithm in mind, I'm listening):
(A) Some kind of recursive operation *every* time you change an
inheritabl
On Thu, 16 Aug 2007, Helge Hafting wrote:
> Marc Perkel wrote:
>> Kyle, What I'm suggesting is scrapping all existing
>> concepts and replacing them with something entirely
>> new. Posix, Unix, SELinux go away except for an
>> emulation layer for backwards compatibility. What I'm
>> suggesting is
Marc Perkel wrote:
Kyle, What I'm suggesting is scrapping all existing
concepts and replacing them with something entirely
new. Posix, Unix, SELinux go away except for an
emulation layer for backwards compatibility. What I'm
suggesting is to start over and do it right.
If you want to get any
Marc Perkel wrote:
I am describing a kind of functionality and not tied
to the method that implements that functionality.
Perhaps a straight hash of the name isn't the best way
to implement it. Just because someone tried to do
something like what I'm suggesting years ago and it
didn't work doesn
Mmm, slow-as-dirt hotel wireless. What fun...
On Aug 15, 2007, at 18:14:44, Phillip Susi wrote:
Kyle Moffett wrote:
I am well aware of that, I'm simply saying that sucks. Doing a
recursive chmod or setfacl on a large directory tree is slow as
all hell.
Doing it in the kernel won't make i
On Wed, 15 Aug 2007 15:48:15 PDT, Marc Perkel said:
> > Consider the rules:
> >
> > peter '*a*' can create
> > peter '*b*' cannot create
> >
> > Peter tries to create 'foo-ab-bar' - is he allowed
> > to or not?
> >
>
> First - I'm proposing a concept, not writing the
> implementation of the con
--- [EMAIL PROTECTED] wrote:
> On Wed, 15 Aug 2007 13:50:17 PDT, Marc Perkel said:
> > I don't see it as being any worse that what we
> have
> > now. To open a file you have to start at the
> bottom
> > and open each directory and evaluate the
> permissions
> > on the way to the file. In my syste
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> Al Viro added to the CC, since he's one of the
> experts on this stuff
> and will probably whack me with a LART for
> explaining it all wrong,
> or something. :-D
>
Thanks - I appreciate that.
Just to catch everyone up on what this thread is
ab
Kyle Moffett wrote:
I am well aware of that, I'm simply saying that sucks. Doing a
recursive chmod or setfacl on a large directory tree is slow as all hell.
Doing it in the kernel won't make it any faster.
Right... I'm talking about getting rid of it entirely.
You can't safely preserve POSI
On Wed, 15 Aug 2007 13:50:17 PDT, Marc Perkel said:
> I don't see it as being any worse that what we have
> now. To open a file you have to start at the bottom
> and open each directory and evaluate the permissions
> on the way to the file. In my system you have to look
> up the permission of the s
Al Viro added to the CC, since he's one of the experts on this stuff
and will probably whack me with a LART for explaining it all wrong,
or something. :-D
On Aug 15, 2007, at 16:38:36, Phillip Susi wrote:
Kyle Moffett wrote:
We've *always* had to do this; that's what "chmod -R" or "setfacl -
On Wed, Aug 15, 2007 at 01:44:50PM -0700, Marc Perkel wrote:
> Yes - that's a good example. Git is far more powerful
> and a different paradigm for CVS. Someone had to think
> outside the box and come up with a new way of looking
> at things. I'm trying to do something like that with
> this idea.
>
--- Phillip Susi <[EMAIL PROTECTED]> wrote:
> Marc Perkel wrote:
> >
> > Kyle - you are still missing the point. chmod goes
> > away. File permissions goes away. Directories as
> you
> > know them goes away.
>
> You are missing the point Marc... open()ing a file
> will have to perform
> a num
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> 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
> >> bey
Marc Perkel wrote:
Kyle - you are still missing the point. chmod goes
away. File permissions goes away. Directories as you
know them goes away.
You are missing the point Marc... open()ing a file will have to perform
a number of these pattern matches to decide if it is allowed or not...
this
Kyle Moffett wrote:
We've *always* had to do this; that's what "chmod -R" or "setfacl -R"
are for :-D. The major problem is that the locking and lookup overhead
gets really significant if you have to look at the entire directory tree
in order to determine the permissions for one single object.
--- Craig Ruff <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 15, 2007 at 10:30:19AM -0700, Marc
> Perkel wrote:
> > --- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> > > Except they do, and without directories the
> > > performance of your average filesystem is going
> to suck.
> >
> > Actually you would
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 15, 2007, at 14:05:23, Marc Perkel wrote:
> > In this new system setfacl, chmod, chown, and
> chgrp all go away
> > except inside of an emulation layer. File and
> directories no longer
> > have permissions. People have permission to naming
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 i
On 8/15/07, Marc Perkel <[EMAIL PROTECTED]> wrote:
> I want to throw out some concepts about a new way of
> thinking about file systems. But the first thing you
> have to do is to forget what you know about file
> systems now. This is a discussion about a new view of
> looking a file storage that i
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 exi
On Wed, Aug 15, 2007 at 10:09:31AM -0700, Marc Perkel wrote:
> Yep - way outside the box - and thus the title of the
> thread.
>
> The idea is that people have permissions - not files.
> By people I mean users, groups, managers, applications
> etc. One might even specify that there are no
> permis
HI
While I find your ideas intriguing, I'd like to offer a friendly
suggestion: You're never going to convince anyone on LKML unless you do
the following things:
* Describe your idea in detail, including algorithms, pseudo code,
pictures, or whatever. Vague hand-wavey stuff won't do it.
On Wed, Aug 15, 2007 at 10:30:19AM -0700, Marc Perkel wrote:
> --- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> > Except they do, and without directories the
> > performance of your average filesystem is going to suck.
>
> Actually you would get a speed improvement. You hash
> the full name and get t
On Aug 15, 2007, at 14:05:23, Marc Perkel wrote:
In this new system setfacl, chmod, chown, and chgrp all go away
except inside of an emulation layer. File and directories no longer
have permissions. People have permission to naming patterns. So if
you put a file into a tree or move a tree th
Kyle,
In this new system setfacl, chmod, chown, and chgrp
all go away except inside of an emulation layer. File
and directories no longer have permissions. People
have permission to naming patterns. So if you put a
file into a tree or move a tree then those who have
permissions to the tree have ac
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 15, 2007, at 13:19:16, Marc Perkel wrote:
> > One of the problems with the Unix/Linux world is
> that your minds
> > are locked into this one model. In order to do it
> right it requires
> > the mental discipline to break out of that.
>
>
On Aug 15, 2007, at 13:34:44, Phillip Susi wrote:
The problem that I have with this setup is that it specifies an ACL
on EACH file. Yes, you can set a default on the directory for
newly created files, but what if I want to add a user to the access
list for that whole directory? I have to i
--- Phillip Susi <[EMAIL PROTECTED]> wrote:
> Kyle Moffett wrote:
> > Going even further in this direction, the
> following POSIX ACL on the
> > directories will do what you want:
> >
> > ## Note: file owner and group are kmoffett
> > u::rw-
> > g::rw-
> > u:lsorens:rw-
> > u:mtharp:rw-
> > u:m
--- Michael Tharp <[EMAIL PROTECTED]> wrote:
> Marc Perkel wrote:
> > That not a problem - it's a feature. In such a
> > situation the person would get a general file
> creation
> > error.
>
> Feature or not, it's still vulnerable to probing by
> malicious users. If
> there are create permission
On Aug 15, 2007, at 13:19:16, Marc Perkel wrote:
One of the problems with the Unix/Linux world is that your minds
are locked into this one model. In order to do it right it requires
the mental discipline to break out of that.
The major thing that you are missing is that this "one model" has
Kyle Moffett wrote:
Going even further in this direction, the following POSIX ACL on the
directories will do what you want:
## Note: file owner and group are kmoffett
u::rw-
g::rw-
u:lsorens:rw-
u:mtharp:rw-
u:mperkel:rw-
g:randomcvsdudes:r-
default:u::rw-
default:g::rw-
default:u:lsorens
defau
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
> > The idea is that people have permissions - not
> files. By people I
> > mean users, groups, managers, applications
> > etc. One might even specify that there are no
> permission
> > restriction
Marc Perkel wrote:
> That not a problem - it's a feature. In such a
> situation the person would get a general file creation
> error.
Feature or not, it's still vulnerable to probing by malicious users. If
there are create permissions on the directory, the invisibility is not
perfect.
> Although
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
.
>
> > The important point here is that directories don't
> really exist.
>
> Except they do, and without directories the
> performance of your
> average filesystem is going to suck.
>
Actually you would get a speed improvement. You hash
the full
On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
The idea is that people have permissions - not files. By people I
mean users, groups, managers, applications
etc. One might even specify that there are no permission
restrictions at all. Part of the process would be that the kernel
load what
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 15, 2007, at 12:02:41, Marc Perkel wrote:
> > Kyle, thinking further outside the box, files
> would no longer have
> > owners or permissions. Nor would
> > directories. People, groups, managers, and other
> objects with have
> > permission
One note before you read the rest of this:
The kinds of things you are discussing here are usually called
"MAC" or "Mandatory Access Control", and they are always implemented
on top of an LSM *after* ordinary "DAC" or "Discretionary Access
Control" (IE: file permissions) are applied. If y
--- [EMAIL PROTECTED] wrote:
> On Wed, 15 Aug 2007 09:02:41 PDT, Marc Perkel said:
>
> > Kyle, thinking further outside the box, files
> would no
> > longer have owners or permissions. Nor would
> > directories. People, groups, managers, and other
> > objects with have permissions.
>
> You gott
--- alan <[EMAIL PROTECTED]> wrote:
> On Tue, 14 Aug 2007, Marc Perkel wrote:
>
> > For example. If you list a directory you only see
> the
> > files that you have some rights to and files where
> you
> > have no rights are invisible to you. If a file is
> read
> > only to you then you can't del
On Wed, 15 Aug 2007 09:02:41 PDT, Marc Perkel said:
> Kyle, thinking further outside the box, files would no
> longer have owners or permissions. Nor would
> directories. People, groups, managers, and other
> objects with have permissions.
You gotta think *way* out of the box to come up with a sy
On Aug 15, 2007, at 12:02:41, Marc Perkel wrote:
Kyle, thinking further outside the box, files would no longer have
owners or permissions. Nor would
directories. People, groups, managers, and other objects with have
permissions. One might tag a file with the object that created it
so you co
--- Michael Tharp <[EMAIL PROTECTED]> wrote:
> Kyle Moffett wrote:
> > Basically any newly-created item in such a
> directory will get the
> > permissions described by the "default:" entries in
> the ACL, and
> > subdirectories will get a copy of said "default:"
> entries.
>
> This would work we
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
>
> ## Note: file owner and group are kmoffett
> u::rw-
> g::rw-
> u:lsorens:rw-
> u:mtharp:rw-
> u:mperkel:rw-
> g:randomcvsdudes:r-
> default:u::rw-
> default:g::rw-
> default:u:lsorens
> default:u:mtharp:rw-
> default:u:mperkel:rw-
> default:g:rando
Kyle Moffett wrote:
> Basically any newly-created item in such a directory will get the
> permissions described by the "default:" entries in the ACL, and
> subdirectories will get a copy of said "default:" entries.
This would work well, although I would give write permissions to a group
so the ent
On Aug 15, 2007, at 09:30:21, Lennart Sorensen wrote:
On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote:
Personally, what I'd like to see is a better way of dealing with
propagation of ownership. Currently, in order to allow
"collaboration" directories where a directory tree is ow
On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote:
> This jumped out at me right away. In such a system, an attacker with
> write permissions on a "sticky" directory like /tmp could probe for
> others' files by attempting to create them and recording all cases where
> permission was den
alan wrote:
> Imagine the fun you will have trying to write a file name and being told
> you cannot write it for some unknown reason. Unbeknownst to you, there
> is a file there, but it is not owned by you, thus invisible.
This jumped out at me right away. In such a system, an attacker with
write
The ACLs that were added to Linux were a step in the
right direction but very incomplete. What should be is
a complex permission system that would allow fine
grained permissions and inherentance masks to control
what permission are granted when someone moves new
files into a directory. Instead of
On Tue, 14 Aug 2007, Marc Perkel wrote:
For example. If you list a directory you only see the
files that you have some rights to and files where you
have no rights are invisible to you. If a file is read
only to you then you can't delete it either. Having
write access to a directory really means
I want to throw out some concepts about a new way of
thinking about file systems. But the first thing you
have to do is to forget what you know about file
systems now. This is a discussion about a new view of
looking a file storage that is radically different and
it's more easily undersood if you f
84 matches
Mail list logo
