On Tuesday 04 October 2005 19:47, Marc Perkel wrote: > I think it's time for some innovative thinking and for people to > step outside the Linux box and look around at other operating > systems for some good ideas. I'll run through a few ideas here. > > Reiser 4 - The idea of building a file system on top of a database > is the right way to go. Reiser is onto something here and this is a > technology that needs to be built upon. It's current condition is a > little on the week side - no ACLs for example - but the underlying > concept is ound. A filesystem built on top of a database? Isn't that introducing complexity into something that should be as simple as possible so that the number of possible errors is reduced? But then, I do not have experience with filesystem design and implementation, so I cannot make a suggestion on this front. > Novell Netware type permissions. ACLs are a step in the right > direction but Linux isn't any where near where Novell was back in > 1990. Linux lets you - for example - to delete files that you have > no read or write access rights to. As someone else pointed out, this is because unlinking is related to your access permissions on the parent directory and not the file. > Netware on the other hand > prevents you from deleting files that you can't write to and if you > have no right it is as if the file isn't there. You can't even see > it in the directory. This is just adding a layer of security through hiding data. I personally don't like this idea for a number of reasons, not the least of which is that it is the access permissions of the directory that control whether or not you can see a file. This and the previous comment about unlinking of files is, IIRC, actually part of the POSIX standard. > Netware also has inherited permissions like > Windows and Samba has and this is doing it right. This would only be a bonus with ACL's. It makes no real sense to propogate a directories permissions down to the files in a directory since an directory you can list the contents of has at least 1 execute bit set. > File systems and > individual directories should be able to be flagged as > casesensitive/insensitive. This would be a rarely used feature and would break many tools. Having an extra bit would also require modifying the kernel and I doubt anyone wants to tackle such a job, as it would also break all extant filesystems. > Permissions need to be fine grained and > easy to use. Netware is a good example to emulate. I do agree with this, but have to point out that this is already allowed for under POSIX and a number of filesystems support this. It's called "POSIX ACL's" in the kernel configuration system. Since I don't use them on my home system (I see no need since it's just me and whatever hacker has managed to penetrate the system (to date: 0)) I do use ACL's (POSIX and otherwise) on all the systems I maintain for my various clients (providing the OS supports them) > The bootup sequence of Linux is pathetic. What an ungodly mess. The > FSTAB file needs to go and a smarter system needs to be developed. > I know this isn't entirely a kernel issue but it is somewhat > related. I'll have to disagree about FSTAB - this is something that is at the peak of it's usefulness and changing or removing it would require the people that maintain the core utilities to rewrite mount(8) almost entirely. However, when it comes to the boot sequence as controlled by init(8) I have to agree. I'm personally working on an entirely new set of init-scripts for my system and have thought about seeing if anyone has ever released an init(8) that is more functional than the basic GNU/FSF version. If there was an init(8) that could run the scripts in parallel I'd be using it as soon as I had a set of scripts lined up that were designed to be run in parallel. > I think development needs to be done to make the kernel cleaner and > smarter rather than just bigger and faster. It's time to look at > what users need and try to make Linux somewhat more windows like in > being able to smartly recover from problems. Perhaps better error > messages that your traditional kernel panic or hex dump screen of > death. lol. Nope. The kernel panic could be refined to contain even more information and be even more user-friendly but it is definately light-years ahead of a Windows BSOD. Now if you're talking about the errors as seen by users of applications that's not a kernel issue and is the purview of the application developers. > The big challenge for Linux is to be able to put it in the hands of > people who don't want to dedicate their entire life to > understanding all the little quirks that we have become used to. > The slogan should be "this just works" and is intuitive. Yep. I do agree with that. However, until the rest of the big companies catch up to the ones that already support Linux this will never happen. Several of my non-business maintenance clients have inquired abotu Linux and I've had to tell them to just stick with Windows because they rely on a rather large number of Windows only programs (that do _not_ run under Wine) and/or are not technically enough inclined to be able to handle the learning curve involved in moving to a non-MS operating system. The fact that I have gotten those inquiries means that the news about how stable Linux is is getting to the "mainstream" population. Only problem is that MS and the home-PC boom has landed the PC and the internet in the hands of too many people who are barely computer literate enough to use a mouse. (I'm speaking from experience. A large number of my private clients fit this description to a T. Although they are good as a continuing source of income :) And with Windows being as "User Friendly" as it is, and with at least 75% of the major software firms still not supporting Linux, there is no way Linux can make any real inroads into the desktop market. OTOH several of my clients have inquired about Linux because of it's security - it doesn't take a genius to see that the same reason Firefox made such a big dent in MS's hold on the browser market could work for Linux as well. And I have had more than one client ask if there was an alternative to Windows than ran well - I've always answered the same way: "Yes, but you would need to learn an all-new way of doing things." Every last one of them dropped it on hearing those words. > Anyhow - before I piss off too many people who are religiously > attached to Linux worshiping - I'll quit not. ;) heh. keep it up. you've managed to turn a pointless argument of micro versus mono into something productive. (even if you didn't mean to) DRH
Attachment:
0xA6992F96300F159086FF28208F8280BB8B00C32A.asc
Description: application/pgp-keys
Attachment:
pgpUtqreNrotZ.pgp
Description: PGP signature
- Follow-Ups:
- Re: what's next for the linux kernel?
- From: Luke Kenneth Casson Leighton <[email protected]>
- Re: what's next for the linux kernel?
- From: Marc Perkel <[email protected]>
- Re: what's next for the linux kernel?
- References:
- what's next for the linux kernel?
- From: Luke Kenneth Casson Leighton <[email protected]>
- Re: what's next for the linux kernel?
- From: Marc Perkel <[email protected]>
- what's next for the linux kernel?
- Prev by Date: Re: [PATCH] proc_mkdir() should be used to create procfs directories
- Next by Date: Re: what's next for the linux kernel?
- Previous by thread: Re: what's next for the linux kernel?
- Next by thread: Re: what's next for the linux kernel?
- Index(es):