Linux.com

Sounds like you want it like windows, but drop legacy support for 32 and 16bit modes. I'm sure if MS could do that, then their product stability and performance would improve greatly. I don't know any developers that want to have backwards-compatibility, but it is a must.

I like the idea of dropping X and going with frame buffers, BUT you lose a LOT there. X is more than rendering to screen, it's a very useful network protocol, and with graphical thin clients taking off, it is more important than ever.

Rather than wasting time on a new OS, I'd just get all hardware vendors to ship linux drivers, and that'd take care of most of the problems.

Linux is also in a growing phase - new apps are always coming out. Once it settles down, you'll see linux become what you want.

#

I worked on a unix that used this, it's fairly useless. Is the read for backup, grep, or something 'useful'?

#

I worked on a unix that used this,

I don't know of any unix system that doesn't support atime.

#

Sorry, but I did not understand why module code should be slower than kernel code. Both run in kernel space, and both have the same access rights (at least with the current design). That's why modules pose a potential security threat. The only difference is that modules have to be loaded initially. Once the module is loaded, the code is effectively kernel code.

#

Each call to a module function has a very slight penalty. See lkml archives for references.

#

Modules do NOT pose an additional security threat, since rootkits can implant the module-loading routines in kernels which have module loading disabled.
If you don't believe me, check out the linux-kernel archives. There Alan Cox prominently states that he has seen rootkits which do the above.

#

Journaling filesystems have automatic rollback, which means they recover instantly from a crash.

Yeah, that'd be nice, wouldn't it? And much of the time it works; you can forget about 'init 0' and just hit the power switch. Well, that is my experience using ReiserFS, which is atomic so it may as well be an auditing FileSystem (and it has the performance hits associated therewith). My experience with ext3, which is just a metadata hack tacked onto the ext2 filesystem, is completely different. Turn the computer off, turn it back on, the thing tries to replay the journal, apparently succeeds, then if you're lucky will eventually get to a prompt, at which point a full fsck is required. However, if your / is ext3, this will be a single-user prompt. If you're unlucky, there will be unrecoverable data, and the system won't boot if it's something critical on<nobr> <wbr></nobr>/. I've had four power-cycles of a running system with the ext3 filesystem on some partition somewhere (and three of those were unplanned, one was a test); it managed to recover flawlessly on one, and recover after a fsck on one.

Your article suggests that a journalling filesystem is somehow a bullet-proof escape from dirty shutdowns. This just ain't so.

FOOTNOTE: BTW if you're thinking that maybe the disk with the ext3 partition on was broken in some way, that's not the case. I've done it on three different disks, two of which are still in use on my system with no problems and one of which is currently in someone else's firewall, again working just peachy.

#

Mandrake 9.1 - Laptop - Have child of four - Power button is a pretty pushy thingy - Daily Hard Reboots - ReiserFS often corrupt beyond recovery (always an eventuality) - Ext3 has never failed - Ever - Over 100 brutal poweroffs - My book... Ext3 wins.

Paul Seamons

#

My experiences have been the complete opposite. I've never had a problem with ext3 recovery, but I've had several filesystems full of unrecoverable data with reiserfs.

#

Hmmmm....looks like I've been luckier than some with Reiser, and unluckier than some with ext3. Probably just got to do with what the system is up to when it goes down, which is largely a disk format-agnostic quantity.

OK, so we can extend my point: on neither ext3 nor Reiser is the filesystem suitably stable through an unexpected power-cycle, though it can offer some degree of protection. Therefore the article should not offer such a blase' description of how great journalling is, and anyone with a little BOFH experience wouldn't have written it thus.

FOOTNOTE: FWIW I originally read your nick as talk_talk and thought you might be a New Romantic fan<nobr> <wbr></nobr>:-)

#

I have found XFS to much better then both reiser and ext3 the performance is stellar as well.

I have had many power outs prior to getting a UPS never lost anything on XFS ext3 was another story, reiser died completely.

#

I agree, I had the power go out on me and quickly come back on. Then on reboot, in the middle of booting it died for a few hours. Ouch! I was worried about what I had lost but the only thing that had happened was the icons on the task bar had been erased. It was a simple, click on the menu and drag them to the bar again to replace them. Thank you xfs!

#

It's my understanding that to use a journalling filesystem properly, you have to turn off the disk's own internal caching (via hparm or something like that). This will make performance suck, suck, suck!

#

On a 15,000RPM Ultra-SCSI disk, you probably wouldn't notice a difference<nobr> <wbr></nobr>:-)

#

Not my experience. I've got all my disks/partitions in ext3 with journaling. I started this after my home machine was set-up that way, and we had a lightning storm. The machine was up and down like a yo-yo about 5 times in one evening, never a hitch.

Since then, I migrated several other machines with 10+ partitions all to ext3, and there has never been a hitch in the many many power-cycle recoveries we've had.

One should be warned though - journalling doesn't protect against HARDWARE failures, only software issues in power cycles.

Dunno if this helps anyone else. I've had the same experiences with AdvFS (from Dec, now Compaq, now HP) and Sun's journalled file system. At one site we actually were given instructions to execute sync twice before shutdown on Sun machines - and shutdown was flipping the power switch !

#

Um, I was not aware that Reiserfs was capable of having problems. I've been using it for about 2 years now on every harddrive on every computer I have and it's been rock solid and it's performance has been most excellent (benchmarks agree, Reiserfs has been shown to be faster than ext3 and XFS, especially with smaller files). I use Reiserfs everywhere , On my Laptop, my many many PC towers, my Mac G4, my Sun Ultra2, my many external USB 2.0 harddrives. I've had so many random power downs/power failures on so many different systems, my USB 2.0 external harddrives suffer constant abuse, bumps, drops, poweroffs, random unplugging from cords being strewn across the room, and Reiserfs has always recovered, usually in only a few seconds. I honestly can't believe that people have had problems with reiserfs, I've had problems with every other filesystem I've used, especially on external harddrives (NEVER format an external harddrive with NTFS, ever, avoid ext2 and HFS, but NEVER use NTFS) I've lost so many Gigabytes of data (tho I usually had backups...somewhere) and so much time to filesystem corruption in the past, Reiserfs has truly been a godsend.

#

Oh! gosh, never saw that amount of crap in a newsforge article.

About modules in Linux:

"user modules" for the kernel? Wrong, modules in the kernel are kernel modules.

"Code in the kernel executes significantly faster than modules"? Wrong, wrong, wrong! Modules in linux are executed also in kernel mode and reside in kernel space. They do execute at exactly the same "speed". Perhaps you loose a little in initialisation, but that's all.

About file systems:
JFS a work in progress? It's as stable as ext3 or XFS.

User interface:
What is the relationship between "user interface" and the way filesystems store and manage directories? That's is another problem, not "user interface". BTW, chech some facts with ReiserFS4

File storage sorting:
Wrong again, filesystems don't do/impose files's sorting (but ReiserFS). That's a problem of the user interface, not the underlying filesystem. BTW, chech some facts with ReiserFS too.

Compression/uncompression: there exists also. What's the big deal here?

etc. etc...

Just a question. Do you check or ask about what you write? Two options, a) you have no idea about operating systems, or b) the article needs to be rewritten/reworded.

#

Modules aren't free. They take a little more memory, and when calling a kernel service (e.g. kmalloc), there's another level of indirection involved, so it's not quite as fast. But otherwise you're correct: "significantly slower"? Nope.

DSC

#

Like, say, designing a new, bautiful microkernel design ? 64-bit, flat addres space ? Object store instead of filesystem ? next-generation security (like, say, capability-based one) ? Yup, cool ideas. But implementing and designing everything from scratch doesn't look so good. And there are always problems with brand-new-rewritten-from-scratch things. Microkernels didn't prove themselves because of their inefficiency - make configurable closed-source solutions, but in open-source world are near to useless. 64-bit flat addres space is cool on one machine. But what about setting up a flat address space for entire Internet ? Object store is also cool, but as Hans Reiser pointed out in his vision of filesystems, any constraints (eg. object orientation) reduce user's ability to find thing of his interest. Next generation, distributed security mechanism ? Yup, but it certainly won't solve all problems, I mean, unless someone invents some magic machine/software which will prove software' corectness.

So, all ideas in above article are pretty cool. But idea od rewriting everything from scratch isn't worth even thinking about. All those ideas should be introduced, implemented, evaluated in small steps as there's no silver bullet solving all problems. Remember, small steps.

#

"Microkernels didn't prove themselves because of their inefficiency"

that's not correct - look at the l4 microkernel. They ran Linux 2.2 on the top and the performance loss was below 5-10%!

Old microkernel designs as Mach etc were inefficient but I think there is indeed a way to make them nearly as efficient as monolithic kernels while gaining enormous gains (debugging, simplicity and elegance).

http://os.inf.tu-dresden.de/L4/LinuxOnL4/

fs

#

Many years ago linux was ported to the alpha, a 64 bit system. Linux has been running on pure 64 bit hardware for a long time.

#

I'd make the whole bunch of utils
have understandable names, make the option lists
understandable, and they'd have non-seriously-overlapping functionality.

I'd divide the functionality up between them better.
I'd make the socket look more like a file in the lower layers.
I'd re-write the shell languages.
I'd make wine work seemlessly.

W...............

#

Poorly thought out, poorly researched, with little or no thought to feasibility, difficulty, or efficiency of implementation.

#

1000% true, this article should be taken down before it's misinformation spreads too far.

#

Is it possible that this was a bit of futurism and not a thorough examination of the status quo?

#

Thought it was good. You have a bunch of folks pissing and moaning about the technical points and trying to defend their work or linux religion.

There are some technical problems with your article (mostly in current technology assessment) but most are benign and I think your wish list would be a decent starting place. It's a requirements wish list not a complete review of the current state of OSes. Calm down people.

#

He got many important things wrong.
It's a technical article.
Therefore, it's crap. You can't improve on Linux if you don't know what Linux already does.

#

I begger to differ.. the author seems to be in a general state of cofusion. He does seem the distinction between user and kernel space has not rained in on him. He proposes to solve performance issues without having done any kind of performance analasys: KDE/GNOME is perceived as slow, so let's replace the underlying windowing system. Before I would dive into such a task I would want to be sure the replacemement is going to make GNOME/KDE faster.
He proposes solutions for problems that do not exist, I for the life of me can't figure out what problem is solved by removing the "shell prompt" altogether: console driver redundant, the same for getty and a few<nobr> <wbr></nobr>/bin/*sh: saves a whopping 1.1M on my box..

Your assertion that it the article is a requirements wish list is bluntly false: is a wish list plus sollutions and implementention. It is mostly the latter for which the author is critised.

#

Some people maybe don't realize that writers sometimes put thoughts on paper that are merely idle speculation. Interesting to mull over, but not necessarily technically detailed. The reader is expected to supply their own expertise where it exceeds the author's. That is how progress is made. Someone has a need, and people meet that need and receive compensation. If we all poked holes in our clients/customers technical knowledge instead of meeting the clients needs, how successfully would we be?

Think of it as science fiction, where you don't expect 100% compliance with reality as we know it.

#

Think of it as science fiction

The parts about Linux are certainly fiction, but none of it is science.

#

This approach allows for virtual folders, which could have files from the user's computer, from the Internet, or from other computers across the globe. To make access faster, containers would be automatically indexed in real time.

And then what happens if the network connection fails (ISP gateway slows to a crawl, etc) while using this nicely indexed virtual filesystem? Wait for each time the system tries to connect to a file to time out then delete it from the index. Your computer would probably freeze. Ever have a system with an autofs mounted nfs directory mounted and have the nfs server die? The results are not pretty. If every item is an object with properties other than just file attributes, and those properties have to be read or held in memory how to do you compensate for all the extra cpu cycles and memory to deal with these objects? Sometings look realy great on paper but when you actually sit down and try to implement them, reality sets in and you end up going with what works best.

#

Ever have a system with an autofs mounted nfs directory mounted and have the nfs server die?

"Alright everyone, do not press any keys on your computer and it will not freeze. Once I get the server up and going your screens will unlock again. Whatever you do, do not reboot."

#

Umm... go ahead and rewrite it. Nobody's stopping you.

#

Bingo. I thought that's what Free Software was all about.

#

...and to make it truly portable, you can do the rewrite completely in java.

Yeeaaaaah, jaaavaaa.....that's the ticket!

#

As poor as this article is, I'm still going to comment on it.

I would hate to have to run X regardless of what I was doing. It's a total waste of processor cycles, especially if I am running background, console-based processes (such as servers often do). The author does not seem to realise that Linux is predominantly used on servers. It is not Micro$oft Windoze!!!

#

I have to agree with you on the GUI as required bit. Why is it that everytime someone thinks an OS needs to be redesigned from the ground up one of the first things they want to do is get rid of the CLI as the basis for the OS?

You don't like the CLI? Fine don't run the CLI...

One of the reasons MS OS's tend to be unstable is because of the GUI being so tightly coupled into the kernel. While I can't say older Mac OS's are the same way, I know for certain that one of the few things that crashes on a at all for me are video drivers under Linux. I hate the idea of having to be restarting my OS cause the video driver couldn't reinitialize itself properly and took my OS down.

#

i like Linux the way it is now!!!

i can either run inittab set to runlevel 3 (CLI) or runlevel 5 (GUI)

don't expect everyone to use Linux the way YOU want it to be run...

#

umm me too, i dont want to run in GUI..I want the GUI to be separated.. So that i can rip it when i dont need it..
Next generation may preffer voice commanding..<nobr> <wbr></nobr>:")
If I can command my wash machine with voice why
I should need GUI..:")
The object stores and so on are good thing for the end user, but hey they are not a work for the kernel or FS, kernel&FS may only give the FRAMEWORK for make this happen easly<nobr> <wbr></nobr>...
There is thing called KIS - keep it simple that should be main goal.. or little extended KISS - keep it simple not stupid<nobr> <wbr></nobr>:")

#

One of the main flaws that stood out to me is: Integrating the gui into an OS kernel, fui that stinks... Me personally, I believe that:

a) integrating a gui into an OS' kernel is a fatal programming flaw. (who would do that? oh yeah M$ with their silly GDI integrated into their hijacked OS2 kernel)

b) for most server applications, a gui is an unessecary drain on the computer's resources, so the gui doesn't belong in the server farm.

c) the fact that the gui is loaded as a separate service in Linux, gives me the ability to fix things, when the gui freezes.

d) The cli makes life easier for me, gosh how difficult is it to learn a few commands, or even run man to understand how a command works.

#

I'm with you all the way, but this:

>d) The cli makes life easier for me, gosh how
>difficult is it to learn a few commands, or even
>run man to understand how a command works.

is not the attitude we need to get Linux going. For most people it IS hard to learn a couple of commands. It's not like we're in a knowledge- or learning-based society. So adapt to society, give them what they want, but don't throw away what we can use.

By the way, the plethora of command line tools gives us a plethora of commands, too. You can't work on a CLI in Linux if you don't study it thoroughly.

#

"It's not like we're in a knowledge- or learning-based society."

That comment is utterly wrong. What separates us from other animals is our ability to learn, adapt, and understand. We _are_ in a knowledge/learning based society, but people have become lazy after everything's been handed to them (in terms of computers, the completely integrated GUI of Windows, with more hand-holding than MacOS, and dumbing down the rest of the interface. Not intuitive, but forced, and pushed everywhere, hence the 'I know Windows, why should I use anything else?' mentality of most Windows users).

#

> If we were to re-write Linux, taking clues from various operating systems,

> what would we make sure it did?

That it will be as good as it is now.

> Our next-generation operating system (NGOS)

> would be [...] aimed at 64-bit hardware

Why should you aim an OS at specific hardware?

Linux could (I think more or less) easily be ported to

various 64 Bit platforms. And I don't think there was a

performance loss or so.

You would do the same thing wrong the guys at Microsoft did

when using a 16bit Operating System as a base for a 32bit

Operating System 'Layer' (speaking about win9x).

> It would support a large

> number of applications and hardware devices, accepting device drivers written

> for other operating system

How should that be possible? You would need to re-write every OS'es device drivers

structure. You can't force every other OS to be compatible to you.

> and run applications written for other operating

Same as above. See wine, e.g. You have to 're-build' the whole OS in very

extreme cases (Linux emulation on FreeBSD is far less complex than wine).

> Kernel: Most operating systems have a monolithic

> kernel whereby all the kernel code is in a single binary.

Wrong: as you state below, Linux has a modularized architecture.

> Even though Linux has a monolithic kernel it has still been

> successfully ported to more platforms than any other operating systems.

Do you know NetBSD? www.netbsd.org

Look at the list of platforms at the right hand side...

> Code in the kernel executes significantly faster than modules.

wtf? That's just bullshit.

> The NGOS would be written for 64-bit processors because by the time the

> operating system would ready for production use 64-bit processors will be

> the mainstream environment.

I think 128-bit processors is more likely.

> The Intel x86 platform supports up to 64GB.

The Intel x86 platform supports up to 2^32 Bytes of Memory.

With paging techniques, this can be extended. But not on _every_ x86 platform.

> The Linux filesystem ext2 is limited to 1TB of space and lacks journaling features.

That's why ext3 was invented.

> The NGOS should be designed in such a way that it doesn't face memory or filesystem

> limitations for at least a few hundred years

LOL -- check http://www.intel.com/research/silicon/mooreslaw.h<nobr>t<wbr></nobr> m

> Linux today stores files with names and extensions

DOS is the only OS I know that really cares for file extensions.

> NGOS should dispense with files and folders and look at everything as an object, be

> it a file, a directory, a link, a Web site, an email, contact details (virtual business cards), an

> image, or a video.

These are all files (except for the link, that may be a hardlink).

And you have even more 'objects' on UNIX: A socket, a device, a pipe, etc.

> Objects would be stored in containers that users can search and browse.

Today we call it 'Directory Hierarchy'

> Compressed objects would be uncompressed on the fly when they are finally accessed.

Yeah that's quit easily possible today. With KDE's kio slaves, for example.

> Most of them have a single GUI integrated with the core operating system.

Most of them use the X Windowing system - if they have a GUI at all.

There are more UNIX flavours than other OSes around.

> This modular design gives a lot of flexibility but also creates performance issues.

Hu? The main performance issue is the Window-Manager, that tends to be a over-colorful

bloated Desktop thingie... like the both you mentioned.

> Users often find the performance of Linux plus X plus KDE or Gnome is slower

> than many other operating system.

So they compare a Desktop with an Operating System? That's like comparing Apples to pears.

> Linux has frame buffer support for a limited number of graphic cards but there are

> very few applications that can work on frame buffers.

wth? The applications only need to use an interface such as DirectFB or X... no

direct Hardware access/knowledge is needed.

> Users who still like a command prompt could execute a command shell such as bash and DOS on top

> of the GUI.

DOS is no command shell. DOS is an operating system.

And bash can't run 'on top of the GUI', it need's a terminal to do so...

besides this, 80% of the software I use runs in these 'terminals' (probably you've

heard of the term).

> It may not be practical to re-write Linux completely from scratch, but anyone considering

> writing their own operating system may want to bear these ideas in mind.

In which way was this article related to linux? I just don't see the point calling

this NGOS a linux successor.

> He is the the founder of FreeOS.com

Again: WTF?? _Free_ OS. _com_

You know what<nobr> <wbr></nobr>.com stands for?

You know what Free is all about?

#

> > limitations for at least a few hundred years

> LOL -- check http://www.intel.com/research/silicon/mooreslaw.h<nobr>t<wbr></nobr> m

You're absolutely right, it's impossible to plan hundreds of years ahead. A couple of years ago, I bought a 20 gig hard drive, expecting it to last for many years. Today I have 160 gigs of hd space, and I sometimes have to delete stuff to fit new programs/movies/whatever.

Even though, we should take Moore's law with a grain of salt. It's a pretty new idea (or "law" if you will), and in fact, we're struggling hard to keep up with it.

-- anyways --

I think we should forget about the OS, and start thinking about the hardware instead:

- We should make *real* plug and play cards with built-in, OS independant, universal drivers!

- We should also make the hardware more reliable and upgradeable. I hate the fact that people are "required" to upgrade their hardware every year in order to keep up with the games' requirements.

- Developers should go back to the roots and start programming more efficiently! Drop Java and other high-level programming languages for CPU-critical applications. We've exceeded three gigahertz(!) of CPU power on the x86 platforms, which is more than enough according to today's standards! If the programmers would learn the joy of assembler programming!

Well that's my thoughts.

The OS's we have today are fine. I'm using Linux and NetBSD, and I have no complaints about them what-so-ever. They're rock solid, fast, developer-friendly. Improving these is a waste of time, at least for now.

#

>- We should make *real* plug and play cards with
>built-in, OS independant, universal drivers!

Hmmm, Ever heard of SCSI? ATA/IDE? you don't need a new driver for each HD or CD rom, do you? What about USB? USB made storage devices a snap. Just plug them in and they just work. period.

>- We should also make the hardware more reliable
>and upgradeable. I hate the fact that people are
>"required" to upgrade their hardware every year
>in order to keep up with the games'
>requirements.

Another dream. Again, see Moores Law. With advancements in technology comes obsolete hardware. There is nothing keeping you from playing frogger on an old 80086 Processor with 640 kb ram!

#

> Hmmm, Ever heard of SCSI?

Sure, but you need a driver for your SCSI controller, don't you? And your network adapter? Your video card? Audio chipset? Scanner?

Imagine a "driver-free" operating system, where each piece of hardware has a little EPROM containing a script. This script can be translated into working code by the kernel, and automatically inserted as a module. We would never have to worry about drivers or hardware compability ever again.

>Another dream. Again, see Moores Law.

Ofcourse, according to today's standards, that is a dream. But the author of the parent story dreams about file systems capable of lasting hundreds of years, so why can't I dream a little too?<nobr> <wbr></nobr>:-)

#

Imagine a "driver-free" operating system, where each piece of hardware has a little EPROM containing a script. This script can be translated into working code by the kernel, and automatically inserted as a module. We would never have to worry about drivers or hardware compability ever again.

This exists; it's called EFI. There was a recent kernel thread about it, and Linus thinks it's a dumb idea. I'm inclined to agree. Adding another bytecode layer just makes things complex; and the "shape" of the driver is unlikely to be exactly what the kernel wants anyhow. Kernel drivers *need* to change from time to time to add things like write barriers. If the drivers are in ROM on the device, that can't be done.

What we really need is devices with relatively simple and well-documented hardware interfaces. Then anyone can write an OS that talks to them, and the OS can evolve to be more efficient over time.

#

>This exists; it's called EFI.

Ok, sorry, I was't aware of that. I haven't looked into it yet, but I will. Anywho, I still think it's a good idea, somehow.

> Kernel drivers *need* to change from time
> to time to add things like write barriers.

Yes, and they may. I didn't mean that the card should have hard-coded binary-only drivers installed. They should be in an open, parseable format, and the kernel should have access to them at all times. If a new card has been installed, fetch driver "guidelines" from EPROM, compile new module, and refresh.

This way we would have:

A good description of how the card works by reading the scripts

Guidelines to building our own driver (automagically)

No limitations to operating systems

We wouldn't have to download the lastest driver either, because a working one is already available on the card.

> If the drivers are in ROM on the device,
> that can't be done.

I said EPROM to imply that the driver should be upgradeable. I'm no fan of none-upgradeable stuff either.

Damn, am I the only one who likes this idea?<nobr> <wbr></nobr>:)

#

- Developers should go back to the roots and start programming more efficiently! Drop Java and other high-level programming languages for CPU-critical applications. We've exceeded three gigahertz(!) of CPU power on the x86 platforms, which is more than enough according to today's standards! If the programmers would learn the joy of assembler programming!



In case you haven't been informed, allow me to let you in on a little secret: CPU Power is phenomenally less expensive than development time, and it's only getting cheaper.



That being said, there are some things that benefit from assembly.



However, I do have one question. Do you write your backup scripts in assembly?

#

> However, I do have one question. Do you write your backup scripts in assembly?

Nope, and nor do I have to. First of all, since when are the backup scripts CPU critical? Second, I write games, not backup scripts. If I wrote a part for a game which I noticed that ran slowly, I would ofcourse optimize it in assembly, instead of increasing the requirements. I never said that I write everything in assembly.

#

So that's why people are spending three time as much time writing programs in VB or Java, that would have been spent writing the same program in something like C++ (no, I didn't say assembly)?

#

Just on a note about compression - even more transparent, use a compressed-loopback device

#

Actually, the x86 platform support neither 2^32 bytes of memory or 64 GB, or it supports both.

Pentium II and up (possibly PPro too) supports 64GB, 386 and up supports 2^32 bytes, the 286 supports 16MB and 8086 supports 1MB of memory.

All of these CPU's are part of "the x86 platform", and as such, you cannot say "the platform supports this" or "doesn't support that". It depends on which processor we are talking about.

#

I have never heard such non-sense in all my life. This has got to be a MCSE or a VB programmer that wrote this.

#

I agree! MS would be hard pressed to come up with more FUD and misinformation than this article. What a totally worthless waste of time, this article is.

It's obvious that the author doesn't have the slightest clue as to what Linux is. As such, he's either a clueless newbie Linux user or a hardcore MS FUDster.

Either way, this article should be retracted from News Forge. How sad.

#

The scary part is that the author's bio states that he's been using Linux since 1996.

#

> Linux is a pure 32-bit operating system written from scratch for 32-bit processors.

Except that, while Linux did start out as a 32-bit OS, it has been a 64-bit OS on all supported platforms for years. It's long since passed its 64-bit growing pains. To be calling it a "pure 32-bit os" is to be completely uninformed as to the current state of things. Current being relative, as that holds true for years now.

I'm really not seeing anything of value here.

#

I believe he is saying that it's pure 32bit as in not 16bit. He mentioned that it was 64bit now, but that that 64bit is programmed on top of the 32bit code. He was suggesting an OS that was purely 64bit with no underlying 32bit code, except for a backwards compatibility layor.

Just to clear things up for you.

#

There's a certain amount of design-orinted thought in Linux, but face it: Linux evolves. Evolution works best when designs are allowed to succeed and fail on their own merits, within the evolving, ecological world of Open Source.

Therefore, I'd suggest you work on these ideas of yours bit-by-bit, one at a time, gradually.

#

Aren't microkernels supposed to be much more slow? As far as I have heard, there is a speed decrease and the majority of the benefits promised from a microkernel never emerge.


I hope this isn't a vi/emacs type thing. I don't want to start a festival of flames.



--Mx

#

That is not true. I have used a MicroKernel OS on a 14MHz MC68EC20 for years and it was one of the most responsive OS I ever used. I am talking about AmigaOS on an Amiga1200. All the people who grew up on x86 barely can imagine what I am talking about.

Go and get http://ftp.uni-paderborn.de/pub/aminet/LOCAL.Z
grep for "device" in that file.

to see what a micro-kernel with a nice modular device concept can achieve over the years.
It is possible to mount any storage volume or directory through a virtual root-device that makes all archives transparent. No need for linking the application against such libs. All you get is an additional volume.
This way all applications can access archives. Also, you can do a

# mount TCP:

copy TCP:newsforge.net/80/index.html ~docs/stuff.html
(very nice for batch-scripting sometimes)
and much much more. Or access raw-memory by mountig MEM: or mount AUDIO: and copy wavs 'directly to the speakers'.

FTP was integrated into the desktop the same way. All you need is a device driver for FTP. Sounds funny ? It is fun !<nobr> <wbr></nobr>:-)

This is in no way comparable to the crappy VFS and similare approaches in Linux. Sure, all this functionality but not as elegant. By far not.
I am eager to see HURD. Can't await it being really vamped up.

#

Nope. Projects like MS' NT kernel, which incorrectly claimed to be a microkernel (as it's not by any stretch of the imagination), gave people that popular opinion. Another failed attempt was the MACH kernel, which was a microkernel, which was extremely slow. Oddly enough, it was the MACH microkernel buzz that Microsoft was attempting to feed off of. It wasn't until MACH was officially declared dead-n-slow by the court of public opinion that MACH really started to fix a lot of it's problems. Nonetheless, OS's like QNX are good examples of very fast microkernel designs.

Microkernels are a proven technology and they can be wicked fast. Just the same, you can thank Microsoft, by in large, for giving people such a bad taste in their mouth for "Microkernel".

Here's a link of interest:
http://www-2.cs.cmu.edu/afs/cs/project/mach/publi<nobr>c<wbr></nobr> /www/mach.html

#

Bzzzzt, try again. NetBSD still holds that crown. Linux is a pretty solid #2, though, and it certainly has coverage of all the relevant platforms.

#

> NetBSD still holds that crown.

Nope. NetBSD supports m68010, ns32k and vax.
Linux supports cris, ia64, h8-300, s390, s390x, v850 and pa64.

Yes, there's a linux-vax project which mostly works, but it's not integrated yet.

It's a tricky comparison of course, there's certainly machines that boot NetBSD that won't boot Linux and cpu support isn't chipset support, but I think Linux has NetBSD outported there too.

#

What? NetBSD supports about 50 more platforms than what you listed.

#

Those are supported by Linux too, mostly. Do not be fooled by the list on NetBSD.org! They list members of the ARM family, while linux has them under the name "ARM", ditto for m68k (amiga, atari, mac68k, and the others). Merely comparing the list of supported families with the supported CPUs is not really fair, I'd say.

#

This is an old and silly argument.

(a) "LINUX", per se, is a kernel, not an OS. If you want to compare to an OS, you need a specific LINUX-based OS. Perhaps Red Hat? Comparing LINUX, per se, to a whole OS (such as NetBSD) is apples-and-oranges. (Or apple-seeds to whole-apples.) Also significantly, is that just one LINUX kernel source tree? Or do you need to hunt down patch-sets and maybe manually resolve conflicts between old patches and newer "core" work? (The original article was speaking about GUIs and desktops, etc., so the article was *clearly* talking about *far* more than just a kernel when speaking of "LINUX" as an operating system. He didn't say what distribution he was speaking of, that I saw. From the author's views on GUIs, it may be that he would not consider NetBSD an "OS" because it doesn't ship with either GNOME or KDE (they are kept in packages)---some NetBSD platforms don't even have X!)

(b) As noted, counting ports of an OS is a tricky issue. And, too, there's the question of how well a platform is supported. Does it support X? Is it current? If both claim "Alpha" suport but one only runs on a few Alpha systems while the other supports many, is it fair to give each a "+1" mark for "Alpha support"?

(c) I think that "number of systems supported" is of little value. It is a benchmark. All else being equal, "more systems" is an improvement, but by itself doesn't tell you much. In the current discussion, this benchmark is uncalibrated so comparing different systems is *completely* meaningless. Abstractly, a single(!) portable source tree is appealing to me. Most of the time, I am only concerned about: Does it run on *my* hardware. Sometime, I may be concerned with *how*quickly* it can be ported to as yet *unsupported* hardware. But pointing to the number of successful ports really isn't all that interesting, IMHO.

#

kernel = OS

The rest are userland programs.
NetBSD has their own kernel as well.

The kernel is the operating system. The rest of the "stuff" makes it usable.

-Mx

#

Not to be argumentative...but... you really have zero actual knowledge about Linux do you?

1) Kernel - LINUX is not a strictly monolithic kernel, it really is the best hybrid design without going totally Micro. If you knew much about OS design, you would know that microkernels have been proven to be not worth it because of the extra overhead that the messaging between the layers causes...AND microkernels have nothing to do with making a kernel easier to port to other platforms.

2) 64-bit. - you are way mistaken if you think Linux is just NOW being ported to 64-bits. Linux has been fully 64-BIT for YEARS!! Alpha-64, UltraSparc-64, PARISC-64, PowerPC-64, MIPS-64, OS390-64<nobr> <wbr></nobr>... Linux has been completly 64-bit clearn and ported on these platforms for YEARS.

3) Files storage sorting: All operating systems today allow you to sort file data by date, size, name, and extension.... JESUS...COME ON... do a "man find" and you can figure out how to do ALL THAT and more...<nobr> <wbr></nobr>:)

4) "would do away with the shell prompt altogether." a) WHY? b) funny Microsoft is working very hard right now to make their command line environment as usable as NIX, and they plan on releasing versions of Windows Server without a GUI AT ALL.

Basically, this article reads like a PEE_CEE Gamer who just heard about Linux and has never run anything other than the pirated versions of Windows he gets from his pals at school.

#

The article seems to be from some lame kiddie who just got in to skool. The guy claims to be Senior-VP of some company, do people in India actually interview before hiring. This guy wins when it comes to talking _crap_, 64 bit monolithic kernel, get a life dude, this ain't an alice in wonderland fairy tale. My condolences to your boss!

#

senior vice president of Netcore Solutions

Another execudroid who thinks that if he can mouth the proper buzzwords, then people will think he knows what he's talking about...

 

... NOT!!

#

It is called the GNU/HURD.

#

And due to the difficulties of succesfully implementing a microkernel this Hurd kernel is still unfinished since its inception.

Don't get me wrong, I think it would be cool to use a GNU/Hurd distro when it materializes and is usable...

I just don't see it happening anytime soon. Seems Linux hit the spot with going modular.

OT: The author of the article must be totally wacko if he wants to dispense of the life saver called CLI. Hands off!!! We won't allow incomptence to destroy the usefull niceties in the OS world...

#

Debian/Hurd is USABLE; you can do most tasks with it by now -- it's just that no one in their right mind would use it when linux is available and can do so much more, more stably. Or BSD if you swing that way.

#

What a sad compliment. Hurd was started back around 1986, and 17 years later, you can do most tasks with it by now

#

Do it!

more code less words!

You have could to write your NGOS, but this time you have the Linux source code for take ideas or take code (with respect to the license). That was imposible with propietary software.

Maybe you have to learn in the Linux history why is not a microkernel and is a "monolitic" kernel.
Because the Linux kernel is a pragmatical kernel, not a "teorical" kernel. And it's WORK.

Good luck with NGOS...maybe you find some of this concepts in Apple's Darwin.

#

I thought NetBSD has this title?? Someone didn't do their research?

#

This Linux NGOS sounds a lot like BeOS.


 

#

With the ever increasing disk size (what is it today? 250 GB?) why do you need compression/offline storage of little used files?

Backup yes.

Offline storage no.

Just another 2 cents (and expensive at that!)

DSC

#

Think of offline storage as


        real time incremental backup

#

- make it possible for a user to modify both the priority and amount of memory the OS assigns to the processes it runs (I think I recall being shown something like that on a RISCOS PC a long time ago)

- if multiple NGOS-running PCs are connected, make it possible for a PC that has a high load to 'transplant' some of it's working processes to a NGOS-running PC with a lighter work load (I think I heard of an idea like that being implemented in TAOS, but I believe they stopped that project, which is a shame, really)

#

done on linux from a long time ago<nobr> <wbr></nobr>...

from http://openmosix.sourceforge.net/ :
Once you have installed openMosix, the nodes in the cluster start talking to one another and the cluster adapts itself to the workload. Processes originating from any one node, if that node is too busy compared to others, can migrate to any other node. openMosix continuously attempts to optimize the resource allocation.

#

You guys are like angry drivers going down the freeway. Somebody makes a mistake and you want to run him off the road.

I mean, sure I laughed at some of the things said by the author and by the posters, but geez, have some respect for humanity. I'm sure he has his reasons for being clueless....let's help him out, not chastize him.

I don't know, maybe I feel this way because I graduated from MIT but grew up with a brother who had a learning disorder. I would be proud of him if he wrote the article posted here. So what I am saying is, "Be proud of the author for getting published, he might be 12 years old or have a learning disorder." I'm kidding!! I'm kidding!!

#

I rarely do this, but...the article isn't worth a comment...your post, however, gets a<nobr> <wbr></nobr>:::snicker:::

#

I'm sure he has his reasons for being clueless...

I'm sure you don't know what they are, Mister MIT.

#

We already have a microkernel, it's called HURD. It's been in development for 20 years, and it's not even in a usable state yet.

I'd much rather have a monolithic kernel that exists as opposed to a microkernel that doesn't exist.

#

Conversely, QNX has been in use longer than Linux.

#

Having skimmed through a handful of comments, I've come to the conclusion that had this group been more than mere wormlings in the womb during Linux's early development, the famed OS would never have come to being.

    This is an essay, perhaps a call to arms, not a development roadmap. A wish list, one could say. Rather than taking the opportunity to contribute, propose a new and radical idea, you spoil the notion with baseless accusations and petty nitpicking.

    Is it that you have no ideas to contribute? No familiarity with your own imagination? It is painfully obvious why the rest of the world sometimes views Open Source as the playground for blithering idiots.

    Progress is cultured from ideas and dreams; hopes and wishes. Is Prakash Advani a visionary? Will he lead us into the next software revolution? While I'm sure he wouldn't mind, the odds are against it. Then again, from the sampling of Open Source brain trusts here, it would seem that his competition is rather light.

    Go back to your high school LUGs and AOL chat rooms. When you are ready to participate like adults, return and we'll give you the courtesy you couldn't give to Advani: we'll hear you out.

#

I'm sorry to say it this bluntly, and I am not the first one to say it, but talking about "wouldn't it be great" doesn't get anybody anywhere. As they say, Shut Up and Code!

#

Bullsh*t.

Tannebaum criticized Linus for his monolithic kernel design early in the evolution of Linux. Linus didn't go home crying to his mama. He stood up to Tannebaum and defended his position.

Wimps simply aren't going to create anything of significance. They will quit when things get difficult for any reason.

Anyone providing suggestions for future OS design goals need to be able to defend those suggestions in a highly adversarial environment. They simply need to be able to back up their wishful thinking.

Unless the ideas in question have no thought whatsoever behind them, putting those ideas to the sword will have no effect. They will simply stand up under scrutiny.

#

Even if you do consider the above to be nothing more than a wish list, it's still considered a good idea to start wishing for things that a, don't already exist and b, for things that make sense. If we ignore the items that conflict with both a and b, we're left with nothing but a clueless attempt to trash Linux and it's kernel.

Take it for what it is...clueless and worthless.

#

Keep the *lovely* command line i use it more than the GUI....
Servers are better w/o GUI Too keep it
but hey this ain't Linus Telling us about linux doing this & forgeting all code (translation: This Ain't linus Telling us we get windoze.....)

#

The best thing about a gui is that you can run lots of command line windows in it.<nobr> <wbr></nobr>:-)

#

(I'm defining an OS as most non-*NIX users would)

My NGOS would be focused on supporting (and creating) standard formats for content. Applications could be used either through some virtual machine or code compiled at run-time. I'm sure it could be optimized to have speed comparable to today. It would have a peer-to-peer network and dynamicaly assign resource locaters independent of ip addresses. Applications could be run in windows or in a tabbed interface like a web browser, but would be dependent on core libraries rather than GUI toolkits. There would be some sort of intermediate language to unify various scripts and media, like HTML only more powerful and efficient. There would be a significant period of time between complete releases so users don't have to update their libraries piecemeal.

This could be implemented on top of linux, and perhaps other OS's also.

#

... It would look a lot like NetBSD.

#

would it suck like NetBSD too? http://bulk.fefe.de/scalability/

#

Do note that that's a specialized benchmark. It appears to be a product of serious thought and effort about how to find hotspots/weaklinks in system performance. Certainly people working on the respective systems should think about where they did well, and where they didn't do well.

But note that the author of the benchmark said that he had to run -current versions of all of the operating systems he tested---except for NetBSD. Some he had to run in -current for stability, and some for performance. But he originally ran NetBSD in a proper release. That speaks volumes to me about NetBSD's quality *not* sucking. (More recently, he's added a discussion of improvements from NetBSD -current. It still isn't on par with the rawest bleeding-edge of the others, last I checked, but...the key point is that he originally didn't think that it was necessary to use bleeding-edge NetBSD. If you like to run real releases rather than bleeding-edge code for your critical servers, you might do a double-take. At least if you think that a benchmark proves a point.)

Yes, NetBSD comes out second worst in the benchmarks. But note that he still said that it was "snappy". Why? Perhaps because even with careful thought, a benchmark isn't the whole story.

I'd take the benchmark as an indicator of things to check if I were putting up a high volume server. "What does this benchmark suggest will be a problem? Is it *really* a problem when I'm running my server?"

I'm sure that some will simply take the bottom-line of the benchmark, though. (shrug)

#

You might want to look into the <A HREF="http://www.gnu.org/software/hurd/hurd-paper.html" TITLE="gnu.org">architecture</a gnu.org> of the <A HREF="http://www.gnu.org/software/hurd/hurd-talk.html" TITLE="gnu.org">Hurd</a gnu.org>.

#

Linux uses pointers and integers and doesn't care tremendously much whether they are 32 bits wide or 64. It doesn't make the least sense to refer to Linux as any bit width - it has run on 64 bit systems for about 8 years now, as well as 32-bit ones. There are a few places where word width is visible, mostly where parameters could have overflowed a 32-bit variable and thus we provide a 64-bit interface as well as the 32-bit one.

You want a Microkernel? Please run Debian HURD. Also please invest in making microkernels easier to debug, there are issues regarding having a lot of asynchronous components that make them difficult to debug, and that's why it has taken a long time to make the HURD work, and IMO points out a flaw in the concept of the distributed kernel - if it takes 5 times longer to make it work, it's not more elegant at all.

I think before you build a wish-list like this, you should get deeper into the kernel. Had you done so, you would never have spouted that 64-bit nonsense.

And you seem to be confused about how GUIs, shells, and operating systems communicate. The GUI does talk directly to the operating system, as does any user-mode program. They all link into libc and issue system calls. The kernel doesn't really make a distinction between a GUI program and any other program. But I think you might be referring to the various components that could be used for a character-mode console. These include the ANSI terminal emulation that runs on VGA, the serial ports, the capability to do character-mode I/O from the kernel console, and the standardized use of file descriptors 0, 1, and 2. The shell's really just an application, you could make it work in the window system without these facilities. You didn't, however, come close to explaining how you'd replace them.

Bruce

#

If you read between the lines, I think the original post was pointing out most of the problems that Windoze suffers from, then applying the wish-list in a *nix-based context.

Go ahead and read it again... it makes more sense now doesn't it<nobr> <wbr></nobr>;-)

#

I don't think the original poster really understood it, but there are some things you might do differently if you were designing a 64-bit OS from scratch.

In the forseeable future, approximately nobody is going to have 2**64 (exabytes?) of physical memory, and no application is going to want to use that much memory. Therefore you can treat address space as abundant, and do things like a single-address-space OS, where addresses are not reused between processes.

Alternatively you could design an OS for an application that does have petabytes of disk. You might make other different fundamental assumptions to Linux.

Itanium has several interesting VM modes that are not used by either Windows or Linux (afaik) and that are quite different to what you could do on a 32-bit machine. It would be an interesting research project to try them out. Of course it would be largely irrelevant to the rest of the guys ideas, which are focussed on the low-end desktop, and which can be adequately supported by 32-bit for years to come.

The rest of his story is pretty wack. This is the kind of thing that gives Indians a bad name.

#

a single-address-space OS, where addresses are not reused between processes.

It's easier to make systems that are "multiple-address-space", because otherwise, every time that you tried to read or write to an address, the OS would have to validate your permissions, which would be very, very, slow.

Itanium has several interesting VM modes that are not used by either Windows or Linux (afaik) and that are quite different to what you could do on a 32-bit machine.

They were taken from the VAX, and are there to enable HP engineers port OpenVMS from the Alpha (which emulates those VM modes in microcode), which DEC engineers ported from the VAX.

#

If Linux was rewritten like that right now, it would be so mind-boggingly slow, no-one would use it. Especially when there are leaner more efficient OSes that may not be as architecturally pretty, but they get the job done at the expense of a few compromises.

#

I Must admit one thing that for a long time now has caused me some concern is this insistance some people seem to have on doing away with X .

Why oh why with a system like X in place and an GUI ontop of it if the GUI goes *i*s up then at least you can get out to an TEXT based system and find out what the heck is going on (unlike windblows) there are times when the old text based system is very usefull light on system resources undemanding fast efficent need i say more I say leave X AND the TEXT based system be

worry more about making shure the apps ect can and do out perform anything written for windblows

Cheers Pete.

#

Just what we need- another person who thinks that because he knows 64 is more than 32 he knows more than the kernel developers about how the os should be written! Buzzwords, factual errors, and outright absurdities abound! This, my friends, is the future of operating systems!

Hint to newsforge: accepting outside contributors' articles does not absolve you from the duties of being editors. If you post an article where the author doesn't understand more than half the words he's used, it makes your site look pretty trashy, and it's your fault. You simply can't let every nutcase on the planet do an op-ed.

Oh, and BTW, the new CNet-ripoff site style is disgusting. Not only is it so obviously a ripoff that they could take you to court over it, but the static page width is a pain.

#

BSD/Darwin runs on a microkernel architecture, and it's blazingly fast.

And GNU/HURD is finally getting to a semi-usable state after languishing for some 20 something years.

#

And before I get some really messed up replies about Darwin, check out their <A HREF="http://developer.apple.com/darwin/projects/darwin/" TITLE="apple.com"> developer page</a apple.com>, and you can see that it's based upon both FreeBSD and the Mach 3.0 kernel.

#

The security provide by OpenBSD is more a myth than a fact. More than thirty years ago, people were already able to build operating systems that provided more security than OpenBSD today.

If you look at UNIX as the pinacle of security, yes, then you can say that OpenBSD is one of the better systems out there.

However, if you broaden your view and look around and study other operating systems and their design, you'll find that there is not much in today's *NIX systems to get excited about. Security wise that is.

The Linux 2.6 LSM approach has some drawbacks that were not mentioned in this article.

#

And if you want people to believe you, then please list some of those operating systems. We'd all be very interested in looking at their source code and comparing security architectures...

#

He's probably referring to CP/M<nobr> <wbr></nobr>;)

#

30+ years ago people didn't have the kinds of security issues we have today.

So, uh, what is the pinnacle of security? PIX? FW-1? Trusted BSD?

#

I'm a small network admin and reading through your article it seems like you and me are using to different OS.

The Linux I know works great with ia64, and is flexible beyond belief. To be honest, I don't think your getting the use out of Linux that you should.

#

microkernel:
HURD is based on the Mach. But Mach is not a very smart microkernel. It still has around 100 systemcalls and there are performance problems due to slow message exchange between processes. Maybe the microkernels based on the L4-concept provide better solutions. Just one example is the Fiasco-project (http://os.inf.tu-dresden.de/fiasco). This microkernel
has got only 7 systemcalls. 7! Thats what i would call "micro". And about performance: Our OS group has ported Linux on Fiasco running the Linux-kernel as an server in user space with an slowdown of less than 4%. Performance is not longer an argument against microkernels. But the main target of building microkernels is automatic verification. For Fiasco this means the VFiasco-project (http://os.inf.tu-dresden.de/vfiasco).

object filesystems:
Can we really take advantage of talking about objects and containers instead of files? We can! But that dont effect the way the filesystem works. Its more about the API and some protocols moving towards OOP.

#

Well the Micro-Kernel idea is great at least, the most stable operating system in the world uses a MicroKernel (namley QNX!!), ignore people who say microkernels don't work well, because if they didn't then people wouldn't trust QNX to tilt the french trains, which of course they do!

Right the filesystem, ok a true UNIX already looks at files in the same sort of way: In other words it looks at everything as a file and stores its information in INODES, this is a proven system, obviously we would all like a filesystem like a SQL database, where you could query it, which would do wounders for information searching. People who say this sort of filesystem wouldn't work are dead wrong, because the there are ways around performance problems, i.e. memory and special caching, look at it this way if I do a find / it takes a long time to search through all the info I have on my machine, but if I use locate it takes no time at all, sure locate is an index of your fs, and needs to be updated but, there are ways to code that sort of thing, and as a programmer I can say it is not difficult, the only problem would be to make it work well with networks etc.

User interface: Well this is something that I think is fine, X is great for what it was intended to do, serve terminals, but yes I admit we need something new, but never say drop your filesystem, because over any connection it takes less time to send a command line to your pc than it does to send a GUI, desktops and terminals can use GUI's but we also have things called servers! I would rather use a terminal and ssh a server and recieve a command line (which is nice, even over 9600) as opposed to a whole GUI which will waste memory on both machines.

And finally to all you other people complaining that the artical is crap, it is a theoretical artical, it was not meant to be technical only to provide someones ideas. Well done to the Author!

#

Why would you base it on an OS thats based on UNIX thats what? 20+ years old now & unix was a hack up of an existing os at the time as well written on really old school hardware. ok its still going strong so its got some good points. dont get me wrong I admin a pair of DEC AlphaServers running Tru64 unix, unix is pretty choice.

ok so your going to re think an OS from the ground up with what we now know... but its still written based on hardware thats based on hardware from years ago.. because it has to run OS's based on that old hardware thinking..so round and round you go with that idea.

so if you really want to get it right and get rid of all the mistakes and stuff that sucks.. you want to rethink the hole hardware platform design & CPU etc, from the ground up and then write an OS with all the good stuff.

A bit like DEC VAX and the VMS OS.. from what I have read and heard, VMS was well done... and also probably along the lines of IBM AS/400's and its OS/400 operating system I guess?

my 2c woth anyhow!

#

QNX's reliability is partially due to its microkernel design, but is also a factor of its design as a true realtime system. Just because it is suitable for tasks that require extreme-reliability, doesn't mean that its design is suited to usage as a desktop or server system.

#

Some good thoughts. A lot of what you say is off the mark, some of it plain stupid, but nevermind keep dreaming, wishing and inventing. People who think beyond the present are what drives this whole thing forward. All great minds are ridiculed in their time.

#

Many stupid minds are also ridiculed.<nobr> <wbr></nobr>;)

#

But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright Brothers. But they also laughed at Bozo the Clown.

-- Carl Sagam

#

All those things have been tried by various operating system designers. Most of them have been awful failures: while many features sound good on paper (e.g., object-based file systems), they don't work well in practice. That's not a problem with their implementation, it's a problem with their semantics. The fact is that most of those features are far better supported outside the kernel.

In fact, what you propose is where Windows is moving. The folks at Microsoft have the same silly infaturation with useless features as you seem to have. So, if that's what you want, why not just use Windows?

The UNIX philosophy is about keeping things simple. Linux may already have strayed from that, but nowhere near as far as you propose.

#

That was funny. Get rid of the shell altogether, but if you want a shell, run it on top of the GUI. That's brainless.

There's no reason why you can't have both like we do now. The GUI doesn't need the shell, the shell doesn't need the GUI. Many, many, MANY, MANY MANY things are far easier to do with a shell than a GUI. Remote administration is a MUST for any NGOS, and shells are the best way of all for many remote adminsitration tasks.

#

I dual boot WinXP and Linux (only for some specific statistical software I use). And I have a habbit of watching TV while I work. Guess what... The X Server is a zillion times faster in allowing me to do that. The layers involved are easy. From TV card to xserver right on the screen. Try doing that fast enough in windows. Hardware, directX, then display service, then your screen. Guess which one is faster. We on slower computers still think Window$ is a monster and does not help us achieve what we want efficiently. It lets me watch TV, yes, but efficiency goes down the drain. Don't change my X, I love it the way it is. Improve it in some aspects yes, but don't try to rewrite a good piece of software.

#

As many people have no doubt pointed out, the title "If I Could Rewrite Linux" implies a rewrite of the Linux kernel only. The author talks about a lot more, but that's no big deal. However, isn't one of the cooler things about Linux the fact that it's a UNIX-type system, and tries its best to comply with POSIX standards? Your NGOS would pretty much break most, if not all, ties with UNIX. And then I'd have to switch to *BSD.<nobr> <wbr></nobr>;o)

#

Pie in the sky bull.

#

This article was horribly thoughout and written by someone who obviously knows nothing about operating systems. First off with the micro-kernel vs monolithic argument, this is a ridiculous argument. The biggest disadvantage to monolithic kernels is that if the authors produce could that is a huge mess(like M$ is known for doing by stuffing just anything where it does't belong).
And what's wrong with the current filesystem? The proposed object-based file system offers no advantages and just may be worse because it presents too many files at a time to the user. And it is ignorant to claim X has slow performance. This is due either poor setup or unsupported hardware. I have a nVidia card with nvidia drivers and X is lightning fast. Oh and, if the GUI communicated with the OS, that'd slow it down.
As with X's hardware acceleration now, the program communicates directly with the hardware.
And I better not have to repeat this again:
A GUI should NEVER NEVER NEVER EVER be integrated into the kernel! This is a fatal mistake that only a most imcompetent designer would make! This could easily bring down the entire system. And it is important for a OS to always offer a command line while it may offer a GUI. Choices and flexibility are what make Linux great!

#

That was a pretty entertaining article.

My favourite bit is the idea of designing an operating system that would last for at least a few hundred years. Bear in mind that even forty years ago GUIs and the internet were hazy science fiction.

#

This was one of the most funny comment of his for me, too.
It is especially whacky because by suggesting this he assumes that we can foresee what the need would be of future users let's say two hundred years to date!
Boy, this did not work even for cloths which are kind of less complicated to predict than computing or electronics in general.
One other idea that hit my eyes were compressing not used files. Well, this is not such a big item. Probably in a half hour I can write a script that does all this (compress if not accessed for six months, move it to backup after other six months, index it, etc...). But I do not need it. Neither do other people so this is why it is not implemented.
is

#

The idea of an OS for computers will be as much of a museum-piece in "a few hundred years" as a multiplication table carved in stone is now.

#

Everybody is entitled to their own opinion but I suspect I would hate your NGOS. Does it stand for Neutered Gross OS.

Instead of wishing for a NGOS I personally wish the average "expert" understood what they have and what we use today with Unix and other *nix like OS packages. Doing away with the shell all together? What exactly do you want to do with this new OS? Almost 30 years of knowledge and refinement have gone into what you want to do away with. It is the power of the "Unix way of doing things" that makes Unix and Linux relevant today. A layered OS that treats most everything as files along with a plethora of specialized utilities is what makes this 30 year old concept releveant to todays work.

#

The only thing I really wish is that we could get away from the association between physical location and logical location. *nix in general does better than DOS/Windows by allowing file systems to be mounted in a single directory tree, but it would be nice if we could move files physically (i.e. to a larger and slower drive) and leave them logically in the same place.

#

ever heard of symbolic links?

#

This whole thing is shit. Almost everything there has absolutely NOTHING to do with Linux. Its about the system which runs on Linux, which you change easily if you really want to. Don't be such an idiot by suggesting we need a new OS to do all that bullshit.

While you're add it, you should add in a mind-reading mechanism so I don't have to use any other input devices, and it should be impossible to break into! gee, why didn't Linux think of these things? durrr....

#

The whole idealogy of linux is to open and share.

This author of this article has done that (share his thought on what he would like his version of linux)

Shame on you for those who have ran him down so callously. It doesn't matter if technically he is wrong but he's not asking for rewards of any sort just his views. There's definitely no need to be RUDE to him

Once again, shame on you !

#

It doesn't matter if technically he is wrong

Yes, it does.

#

If I could rewrite Linux I would start by slapping on the back of the head all those C++, everything-is-an-object programmers who are daily making Linux slower and more bloated with their Object Ofuscated Code wanking.

It used to be you could get spiffy performance from an older, yet perfectly usable computer. Now, Linux won't even install on many of these boxes. Eventually the minimum machine specs for Linux will be the same as Windows.

#

While the article truly did suck on the great goat balls in the sky, I must say that there are a few things which would be nice to see coming into Linux. Might as well use this space to expound upon that, than argue about how technically accurate it is. One of many things is the hardware support, but as linux gains a larger market share, the vendors will eventually come around =). So, anywho, here's my list:
1) Better Frame Buffer (FB) support. Right now, FB generally sucks. From my experience --which is a bit dated, I will admit-- I have found that you either get neato FB support, or get 2D/3D acceleration support, not both. Either I get my FB kernel and can't play video games (glx no likey the FB), or I get the NVidia modules, and have an awesome X, but my console has no native support for graphics.
2) On the same lines, it would be nice if there were good kernel or user-space drivers for 3D video cards (and I mean of a DirectX Quality). Many people who predominately play games with their windows boxes are deterred because they don't have the selection or quality of their games in linux (I do know that WineX has made many inroads in this, but it's not enough as is).
3) More on linux-windows compatibility: Linux, as it stands, has attrocious winbin support. I believe that winbin support should be an option to compile into the kernel. It could be placed in the same location as the ELF binary selector. This, however, does not mean the<nobr> <wbr></nobr>.dll code should be integrated in the kernel... I just want OSS kernel-level winbin support. Wine is cool, but it's user-level. This is another integral part of getting people to run a linux environment, IMHO. It will allow a much easier time of grabbing users... all of the software that they have already bought will be usable in Linux, just as easially as windows. (To my knowledge, Win4Lin does do this, but it is closed-source.) Then again, the WinOS is a vast, bloated operating system... and thus it might be better to just keep it in the user-level.
4) This is a long shot, but it would be really cool to use all of the protected modes of the x86 archetecture. I know that this limits portability, but it would make different pieces of the overall archetecture of linux/*nix systems more granular, thus making it easier to segregate what can touch what. (i.e. keep kernel 0 and userland 3, but maybe add a 1 or 2 for user-level device drivers/hardware use libraries. I could see some significant uses for this in things such as multimedia libraries, where you want direct access to many portions of the system (such as video and sound cards), but don't want to fiddle with the very fine controlled stuff (such as threads/LWP or virtual memory management).

Btw, I do have plans to eventually become a contributer to the linux kernel, if I get the chance. If this does happen, then I plan on asking/implementing at least a few of the things noted above. Unfortunately, I have yet to even investigate the kernel and it's technology, and have no clue how to program an OS, so we'll see if that ever happens. (Still got a few years of college ahead of me<nobr> <wbr></nobr>;)

Zachary Jensen (Zakaelri AT drexel.edu)

#