Linux vs OS X vs "Other alternitives"...

Based on:
Torvalds pans Apple with 'utter crap' putdown
http://www.smh.com.au/news/technolog...090393959.html

Linux vs OS X vs "Other alternatives"...

I assume they both do it
===================
CARDINAL SIN:
Linux and OS X both not only run drivers and the file system in the kernel
privilege space, MINUX and QNX typically don't do this. As a general rule,
the FS and Drivers and networking should run at 'privileged user' level and
not system privilege (aka 'su') level. The troika of FS, Drivers and
networking should not be (a substantial) part of kernel. Keep the kernel
under 50,000 lines of auditable code -- but 20,000 lines or less is
preferred.
===================

FILE SYSTEM SUPPORT:
Linux has almost universal file system support, it runs and boots on about
anything -- not so much so for OS X
OS X uses a special FS version for backward compatibility with older Mac
Apps; Linux can't read this FS!
Linux should be able to read the slightly variant QNX RTOS FS, but I don't
think it can do this either.

TASK SWITCHING:
Linux uses more lightweight processes than OS X -- but most hardened server
users can't tell the difference

X11R7:
Linux 100%, OS X: there but obscure. Mac Apps cannot be run remotely by X11
as far as I can tell

UPGRADING:
Hard manual labour with some Linux configs, ASUS Eee PC and other versions:
almost fixed.
Apple: OS X probably still has the best overall upgrade system.
Global view: The overall problem is 60% solved. Huge work to be done still.

POWER MANAGMENT:
OS X has a very PC like implementation, but I assume power management is not
in the kernel.
Linux seems to have had power management added to the kernel space -- bad
idea.
It is OK to run power management at system level privilege, but the kernel
should itself only be slightly modified to make optimal use of sleeping and
self shutdown.

Hiding UNIX interface:
Only some versions of Linux do this well: Linspire (maybe), ASUS Eee PC
(yes) ... vast work needs to be done.
OS X does do an excellent job of hiding Unix's interfaces -- to the point of
transparency.
Overall: 30% work accomplished, 70% yet to be done (not all universally on
Linux side).

== Moral and conclusion ==
Linux although not crap, needs great improvements to keep it leading edge.
OS X probably needs an internal cleaning and upgrades to keep it current
with Linux.
Both have hyperobese kernel structures, and a redesign is needed to maintain
performance gains.

"Max Power" <> writes:

>Based on:
>Torvalds pans Apple with 'utter crap' putdown
>http://www.smh.com.au/news/technolog...090393959.html

Zero information there. Linus is upset about something re the filesystem on
OSX but the article does not say what.


>Linux vs OS X vs "Other alternatives"...

>I assume they both do it

Both do what?

>===================
>CARDINAL SIN:
>Linux and OS X both not only run drivers and the file system in the kernel
>privilege space, MINUX and QNX typically don't do this. As a general rule,
>the FS and Drivers and networking should run at 'privileged user' level and
>not system privilege (aka 'su') level. The troika of FS, Drivers and
>networking should not be (a substantial) part of kernel. Keep the kernel
>under 50,000 lines of auditable code -- but 20,000 lines or less is
>preferred.
>===================

This is a "sin" why? If you worship at the holy microkernel church, perhaps
it is a sin. Otherwise it is philosophy that may or may not work better for
your application.


>FILE SYSTEM SUPPORT:
>Linux has almost universal file system support, it runs and boots on about
>anything -- not so much so for OS X
>OS X uses a special FS version for backward compatibility with older Mac
>Apps; Linux can't read this FS!
>Linux should be able to read the slightly variant QNX RTOS FS, but I don't
>think it can do this either.

>TASK SWITCHING:
>Linux uses more lightweight processes than OS X -- but most hardened server
>users can't tell the difference

>X11R7:
>Linux 100%, OS X: there but obscure. Mac Apps cannot be run remotely by X11
>as far as I can tell

>UPGRADING:
>Hard manual labour with some Linux configs, ASUS Eee PC and other versions:
>almost fixed.
>Apple: OS X probably still has the best overall upgrade system.
>Global view: The overall problem is 60% solved. Huge work to be done still.

>POWER MANAGMENT:
>OS X has a very PC like implementation, but I assume power management is not
>in the kernel.
>Linux seems to have had power management added to the kernel space -- bad
>idea.
>It is OK to run power management at system level privilege, but the kernel
>should itself only be slightly modified to make optimal use of sleeping and
>self shutdown.

Again another sermon.


>Hiding UNIX interface:
>Only some versions of Linux do this well: Linspire (maybe), ASUS Eee PC
>(yes) ... vast work needs to be done.

Why do you want to "hide unix interface" whatever that means?

>OS X does do an excellent job of hiding Unix's interfaces -- to the point of
>transparency.

No idea what his means.

>Overall: 30% work accomplished, 70% yet to be done (not all universally on
>Linux side).

No idea what "work" this is.


>== Moral and conclusion ==
>Linux although not crap, needs great improvements to keep it leading edge.
>OS X probably needs an internal cleaning and upgrades to keep it current
>with Linux.
>Both have hyperobese kernel structures, and a redesign is needed to maintain
>performance gains.

Your evidence that the kernel structure impacts performance adversely is
what?

Max Power wrote:
> Based on:
> Torvalds pans Apple with 'utter crap' putdown
> http://www.smh.com.au/news/technolog...090393959.html
>
>
> Linux vs OS X vs "Other alternatives"...
>
> I assume they both do it
> ===================
> CARDINAL SIN:
> Linux and OS X both not only run drivers and the file system in the
> kernel privilege space, MINUX and QNX typically don't do this. As a
> general rule, the FS and Drivers and networking should run at
> 'privileged user' level and not system privilege (aka 'su') level. The
> troika of FS, Drivers and networking should not be (a substantial) part
> of kernel. Keep the kernel under 50,000 lines of auditable code -- but
> 20,000 lines or less is preferred.
> ===================
>
> FILE SYSTEM SUPPORT:
> Linux has almost universal file system support, it runs and boots on
> about anything -- not so much so for OS X
> OS X uses a special FS version for backward compatibility with older Mac
> Apps; Linux can't read this FS!
> Linux should be able to read the slightly variant QNX RTOS FS, but I
> don't think it can do this either.
>
> TASK SWITCHING:
> Linux uses more lightweight processes than OS X -- but most hardened
> server users can't tell the difference
>
> X11R7:
> Linux 100%, OS X: there but obscure. Mac Apps cannot be run remotely by
> X11 as far as I can tell
>
> UPGRADING:
> Hard manual labour with some Linux configs, ASUS Eee PC and other
> versions: almost fixed.
> Apple: OS X probably still has the best overall upgrade system.
> Global view: The overall problem is 60% solved. Huge work to be done still.
>
> POWER MANAGMENT:
> OS X has a very PC like implementation, but I assume power management is
> not in the kernel.
> Linux seems to have had power management added to the kernel space --
> bad idea.
> It is OK to run power management at system level privilege, but the
> kernel should itself only be slightly modified to make optimal use of
> sleeping and self shutdown.
>
> Hiding UNIX interface:
> Only some versions of Linux do this well: Linspire (maybe), ASUS Eee PC
> (yes) ... vast work needs to be done.
> OS X does do an excellent job of hiding Unix's interfaces -- to the
> point of transparency.
> Overall: 30% work accomplished, 70% yet to be done (not all universally
> on Linux side).
>
> == Moral and conclusion ==
> Linux although not crap, needs great improvements to keep it leading edge.
> OS X probably needs an internal cleaning and upgrades to keep it current
> with Linux.
> Both have hyperobese kernel structures, and a redesign is needed to
> maintain performance gains.
>
You forgot the most telling two points. OSX is very pretty. But if you
want it to do anything more than comes with Tiger/Leopard, you need to
spend shitloads of money for the applications.

Linux as the only alternitive to OS9 -- for the older RISC PCs ... I did not
know that this was the case.

I never meant to cover this case, but needless to say Linux with some
microkernal like fixes would probably run even better on older Macs (RISC,
non 68x).

Still there is no reason why OS X and Linux can't be at design / performance
parity.


////////////////////////////////
>> Based on: Torvalds pans Apple with 'utter crap' putdown
>>
> http://www.smh.com.au/news/technolog...090393959.html
>> view: The overall problem is 60% solved. Huge work to be done still.
==============
>> == Moral and conclusion ==
>> Linux although not crap, needs great improvements to keep it leading
>> edge.
>> OS X probably needs an internal cleaning and upgrades to keep it current
>> with Linux. Both have hyperobese kernel structures, and a redesign is
>> needed to
> >maintain performance gains.

///////////////////////////////

> I was recently give a couple of perfectly good G3's
> that were missing the HD's. I put in some spare drives.
>
> The only MAC OS I have is OS9 and it would not load onto the G3's...
> and I am hardly going to go out and purchase OS-X to load onto a couple of
> older freebies.
>
> Loaded Linux on them and they work just fine... two perfectly good
> machines now 100% free of charge.
>
> Is Linux the best OS out there?
>
> In many cases, the answer is: It's the *only* OS out there!
>
> FWIW: I used Ubuntu which is not my first choice when using Linux on a PC
> ... but ...it works just fine.

I don't strictly believe in Microkernals.
However, Microkernal design ideas and concepts have earned their keep many
times over.
Yet, I believe a new balance between adaptability and readability will need
to be reached sometime in future.

Linux (like OS X) is at its design limit when it comes to core OS (kernel)
code.
Having hundreds of thousands of lines of kernel code is just setting up
conditions for KERNAL PANIC and Triple Faults.
Putting the drivers into the 'user' privilege space -- and reducing the
kernel size by 50% -- would make Linux even more robust than it already is.

The Linux 'File Systems' to the extent that they are in the kernel needs to
gradually be moved out of the kernel space.
I don't mind ~3 file systems in the kernel area (FAT16, FAT32; NTFS(3.1)?
and maybe ReiserFS + Swap FS).
Other Unix like FS's should have fully support as usual -- just not in the
kernel.
I don't think that this will affect Linux's interoperability or performance
or adaptability in any way -- so long as the code moves are open to public
inspection.
The user should not notice any change at installation or at any other point
of operation.

There is no reason why a future Linux can't be used on a spacecraft
(remember the Voyager Programme) -- and run continuously for 10 or 20 years
without a reboot. Minix and QNX (and to a lesser degree VxWorks) can do this
now. That does not mean that Linux has to be a classical microkernel.

>>===================
>>CARDINAL SIN:
>>Linux and OS X both not only run drivers and the file system in the kernel
>>privilege space, MINUX and QNX typically don't do this. As a general rule,
>>the FS and Drivers and networking should run at 'privileged user' level
>>and
>>not system privilege (aka 'su') level. The troika of FS, Drivers and
>>networking should not be (a substantial) part of kernel. Keep the kernel
>>under 50,000 lines of auditable code -- but 20,000 lines or less is
>>preferred.
>>===================
>
> This is a "sin" why? If you worship at the holy microkernel church,
> perhaps
> it is a sin. Otherwise it is philosophy that may or may not work better
> for
> your application.

I don't strictly believe in Microkernals.

However, Microkernal design ideas and concepts have earned their keep many
times over.

Yet, I believe a new balance between adaptability and relyability will need
to be reached sometime in future.

Linux (like OS X) is at its design limit when it comes to core OS (kernel)
code.

Having hundreds of thousands of lines of kernel code is just setting up
conditions for KERNAL PANIC and Triple Faults.

Putting the drivers into the 'user' privilege space -- and reducing the
kernel size by 50% -- would make Linux even more robust than it already is.

The Linux 'File Systems' to the extent that they are in the kernel needs to
gradually be moved out of the kernel space.

I don't mind ~3 file systems in the kernel area (FAT16, FAT32; NTFS(3.1)?
and maybe ReiserFS + Swap FS).

Other Unix like FS's should have fully support as usual -- just not in the
kernel.

I don't think that this will affect Linux's interoperability or performance
or adaptability in any way -- so long as the code moves are open to public
inspection.

The user should not notice any change at installation or at any other point
of operation.

There is no reason why a future Linux can't be used on a spacecraft
(remember the Voyager Programme) -- and run continuously for 10 or 20 years
without a reboot. Minix and QNX (and to a lesser degree VxWorks) can do this
now. That does not mean that Linux has to be a classical microkernel.

>>===================
>>CARDINAL SIN:
>>Linux and OS X both not only run drivers and the file system in the kernel
>>privilege space, MINUX and QNX typically don't do this. As a general rule,
>>the FS and Drivers and networking should run at 'privileged user' level
>>and not system privilege (aka 'su') level. The troika of FS, Drivers and
>>networking should not be (a substantial) part of kernel. Keep the kernel
>>under 50,000 lines of auditable code -- but 20,000 lines or less is
>>preferred.
>>===================
>
> This is a "sin" why? If you worship at the holy microkernel church,
> perhaps it is a sin. Otherwise it is philosophy that may or may not work
> better
> for your application.

Max Power hallucinated:

> I don't strictly believe in Microkernals.
>
> However, Microkernal design ideas and concepts have earned their keep many
> times over.

They do? Where?

> Yet, I believe a new balance between adaptability and relyability will
> need to be reached sometime in future.
>
> Linux (like OS X) is at its design limit when it comes to core OS (kernel)
> code.

Interesting. The kernel crew will probably disagree

> Having hundreds of thousands of lines of kernel code is just setting up
> conditions for KERNAL PANIC and Triple Faults.

*That* has to be the reason I have not seen a kernel panic in several years.
The last one was 6 or 7 years ago, when a disk started to fail.
BTW, triple faults are something entirely different

> Putting the drivers into the 'user' privilege space -- and reducing the
> kernel size by 50% -- would make Linux even more robust than it already
> is.

Ah yes.

> The Linux 'File Systems' to the extent that they are in the kernel needs
> to gradually be moved out of the kernel space.

Why?

> I don't mind ~3 file systems in the kernel area (FAT16, FAT32; NTFS(3.1)?
> and maybe ReiserFS + Swap FS).

That is prolly nice of you. May I ask who made you "OSS culling committee
chairman"?

> Other Unix like FS's should have fully support as usual -- just not in the
> kernel.

Naturally not. After all, they would work best there. Can't have that

> I don't think that this will affect Linux's interoperability or
> performance or adaptability in any way -- so long as the code moves are
> open to public inspection.

Naturally. After all, these recent attempts at hiding code must be stopped
at all cost

> The user should not notice any change at installation or at any other
> point of operation.


No. Best would be to completely halt any chnage to linux for a time, like 10
years. One could make agreements with MS to introduce new versions at the
same time MS innovates a new Windows version


< snip more utter lunacy >

Idiot

Stay with your "micro kernel" Vista and just hide well enough that nobody is
viewing such a display of complete stupidity
--
Klingon function calls do not have 'parameters' -
they have 'arguments' - and they ALWAYS WIN THEM.

Max Power wrote:

> Linux as the only alternitive to OS9 -- for the older RISC PCs ... I did
> not know that this was the case.
>
> I never meant to cover this case, but needless to say Linux with some
> microkernal like fixes would probably run even better on older Macs (RISC,
> non 68x).

You mean, they would better waste processor power?

> Still there is no reason why OS X and Linux can't be at design /
> performance parity.

MAy I ask what reason there would be to make linux *that* *much* slower?

< snip bottom quote from an imbecile >
--
Microsoft? Is that some kind of a toilet paper?

In article <>,
The Natural Philosopher <> wrote:

> You forgot the most telling two points. OSX is very pretty. But if you
> want it to do anything more than comes with Tiger/Leopard, you need to
> spend shitloads of money for the applications.
Lots of free and open source APPs run on OS X, even Neo Office.

In article <>,
"philo" <> wrote:

> I was recently give a couple of perfectly good G3's
> that were missing the HD's.
> I put in some spare drives.
>
> The only MAC OS I have is OS9 and it would not load onto the G3's...
> and I am hardly going to go out and purchase OS-X to load onto a couple of
> older freebies.

All G3s will run/boot OS 9.
Sounds like you had a model specific installer,
which comes with new Macs.
The retail OS 9 installer, which I have, installs on all G3s, most G4s.
and previous PPC Macs.

OS 9 runs (boots) on PPC Macs from 1994 up to my (2003) G4/1.25 MDD, on
which I run the latest OS X.5 Leopard.
In Classic mode under OS X, OS 9 runs on all OS X supported PPC Macs,
before the Intel Macs.