[ros-dev] HP webOS goes opensource

[Adam]

On Wed, 18 Jan 2012 14:22:59 +0100
Ameen Ross <a.ross at amdev.eu> wrote:

> Op 18-1-2012 13:27, Adam schreef:
> > Old, but relevant in today's world. Let's face it... the mainline
> > kernel is getting huge.
> Agree, but a good portion of that is actually drivers and many other 
> things that can easily be left out.

Although that would require recompiling the kernel just to
install/uninstall drivers. I do understand loadable modules are
supported but I'm not sure this applies to drivers. And if it does, I
doubt it would apply to all drivers.

> > "on the *developers'* terms" - this effectively means "on the terms
> > of who wrote the software" - not "on the user's terms" - so you'll
> > still get some bloated distros out there.
> If you're running a distro with a kernel too bloated to your tastes
> you can switch to a more light-weight distro. Not the case with
> Windows, although the question of whether or not that's a good thing
> is a whole debate of itself.
> 
> > Again, "*as the developer wants it to be*" - And yes, this goes for
> > Windows too. Microsoft probably wants it to be bloated, so it makes
> > it bloated.
> The difference here is that with Windows, Microsoft is the only 
> developer and with Linux, anyone doing an embedded appliance or a
> distro has that freedom.
> > Though I can agree with "So, unlike Windows, which can only be what
> > Microsoft dictates, ..." - but bear in mind that when it comes
> > to Windows then Microsoft is the developer anyway. It's on the
> > developers' terms.
> ...isn't that exactly the point?

And of course, let us not forget that many corporations (Microsoft,
IBM, etc) also contributed to Linux - in addition it is possible to
develop device drivers for Microsoft Windows too.

In any case I think this article "update" seems to have done a great
job at distracting both of us from the issue I was talking about:

From my original email:

"Given the way Linux is going at the moment (see
http://news.cnet.com/8301-13505_3-10358024-16.html  for example) I
think I do not think those expectations will be too high in the
near future. ;)"

It had nothing to do with "how the developers could customize things"
or comparisons with Microsoft Windows - I was making a prediction for
the future of the ReactOS kernel vs Linux kernel based on the above
source. I never mentioned the "update" because *it is irrelevant* to my
point, and appears to serve as a distraction.

If Linus Torvalds, the creator of the Linux kernel, admitted it is
getting bloaty, then perhaps this means something for the direction the
Linux kernel is going? I mean who cannot expect to see an increase of
code size as new features are added. Particularly those which many
won't be using.

I cannot see how this "update" at the end has any relevance to the
article.

> > I'd love to see the kernel uClinux uses... I reckon it's not the
> > mainline kernel, but a modified version of it. Again... it's up to
> > the *developer* as the quote above mentioned.
> I'm surprised you've never heard about it. Although it does confirm
> my suspision that you didn't thoroughly read the article ;)
> Lots of stuff runs uCLinux actually, mostly embedded d.

I have indeed heard about uCLinux - I was suggesting it probably
doesn't even use the mainline kernel, otherwise it would definitely be
bigger than 100KB then.

As for me not thoroughly reading the article...
I think I did read the whole article but happened to dismiss the update
because it has *nothing to do with the article* - saying things like
"oh but linux is highly modular and developers can customize it to make
it not so bloaty" does not do well and appears to be more of an attempt
to hide the issue.

If you had told me I hadn't read all of the comments, however, yes I
would agree.

> > Just go over to http://kernel.org/ - the source code for the Linux
> > *kernel* in *compressed* form is 74MB plus! And that is compressed
> > by the way. You'd need to have a very stripped down kernel to the
> > max. Which would have been fine if it was "highly modular" as it is
> > claimed.
> Your tone sounds as if you oppose the statement in the article that 
> Linux is highly modular.

I suppose bunching lots of bells and whistles in the kernel
(file systems, drivers, pseudo-devices, etc) and also sticking
"support" for loadable modules (and LSM) alone makes it "highly modular"
then? Well yes it *supports* modules, but I'd hardly call it "highly
modular" the way it's going.

> > Personally I'm happy seeing ReactOS the way it is going and I think
> > they're taking the right direction. The last thing ReactOS needs is
> > to listen to some kid going about some super fantastic UI (or other
> > Linux-specific feature) present in Linux and attempting to say it
> > should be in ReactOS as an "improvement" of some sort.
> Did anything I say imply my opinion is contrary to that? Unless you
> read it to mean something else than I intended, that's impossible.

I cannot remember saying that your opinion was contrary to that. Can
you point out where I said or implied this?

> The NT kernel just takes a different approach than the Linux kernel, 
> concequently the ReactOS project takes a different approach than the 
> Linux distros. Not any approach is "right" or "wrong", they're just 
> different approaches catering to different requirements.
> 
> It's sort of like the font rendering issue. Mac OS does pretty 
> rendering, but Microsoft chose rasterized/readable rendering. Neither
> is better than the other, just a different approach to the problem.

That may be true, but some approaches are better than others, for a
particular purpose. Windows and Linux have one thing in common: they
both have desktop and server markets. For both areas, they both do
things better than each other. Windows has a better permissions control
system than Linux "user group owner" permissions. Linux supports more
protocols so interoperability is there, and SSH makes it easy to manage
remotely via command line.

> 
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev