Ubuntu first time

Christopher Browne cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Tue Jan 10 18:02:04 UTC 2012


On Tue, Jan 10, 2012 at 12:22 PM, Lennart Sorensen
<lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org> wrote:
> On Tue, Jan 10, 2012 at 11:51:15AM -0500, Alejandro Imass wrote:
>> I think this is a very  myopic statement and shows that the Linux
>> crowd needs to get out more, especially so in the Debian crowd.
>>
>> Let me just point out *some* differences between FBSD and Linux. And
>> again, I'm not saying that Linux is bad, but since you have made it a
>> habit to throw careless FUD everywhere it is necessary to point just
>> some benefits of FBSD:
>>
>> 1) For starters, Linux's overly-optimistic vm is really crappy for
>> high-load systems and no matter how you tweak it you will never get
>> the high-load stability of a FBSD kernel. At least not to date. A
>> simple example, just push linux to near exhaustion of swap and:
>> *boom*, you will need to eventually reboot as it never recovers
>> completely. The over optimistic vm is a well known problem in the
>> Linux Kernel, and _any one_ can try this at home with ab or httperf
>> with a 2.6.x. Linux kernel running a memory hungry multi-threaded
>> Apache application.
>
> Linux's overly optimistic VM can be made not optimistic at all.

Kind of in keeping with tonight's talk topic...

There are "truths" whose value has depreciated.

Linux has had some habits of being overoptimistic about memory
allocation, which does, indeed, behave badly as described.

But, of course, you're not *forced* to be so overoptimistic.
<http://www.postgresql.org/docs/8.2/static/kernel-resources.html#AEN19397>

>> 2) Another problem with Linux is the mixing of base system and
>> applications. In *BSD there is a clear-cut separation between the base
>> system and the application world, making it not only extremely secure,
>> but very stable in upgrades. You can upgrade apps and system
>> practically independent from each other. This could easily be done by
>> any Linux distro, but none to date have.
>
> Sometimes you do add features to the kernel and then the system libraries
> have to be updated before you can use it.  As long as your library
> interface is well designed, this doesn't force you to update any
> applications, they just won't have any way to use the new feature until
> they are updated.

Well, I'd count this as a place where BSDs and Linux make somewhat
different choices as to where the separation takes place.

The "BSD way" is for the 'system' to be inclusive of kernel + system libraries.

The "Linux way" doesn't really have a notion of a 'system'; the kernel
is quite separate from everything else.

A few years ago, I considered that to be rather unfortunate, but the
strict separation has actually gotten used for real things, and people
doing embedded systems, which clearly includes mobile platforms such
as Android, have gotten some milage out of the strict separation.

>> 3) FBSD Jails: There is nothing like this in the Linux world to date,
>> and it's a shame because it would be so easy as is nothing more than a
>> sophisticated chroot environment. Jails amongst other things (like
>> pseudo-virtualization without overhead) allows you to further separate
>> base system from running services with so-called "service jails"
>
> Those are a neat idea.  Not that I have ever had a need for anything like
> it, but they are neat.  I think many people use virtual machines instead,
> which is certainly perhasp overkill in comparison.

It's not true that "there is nothing like this in the Linux world to
date"; there appear to be several implementations of Jails on Linux.
They mightn't be as featureful as the FreeBSD implementation, but to
say "there is nothing like this" is simply untrue.

http://olivier.sessink.nl/jailkit/
http://sourceforge.net/projects/linuxjail/
http://sourceforge.net/projects/jail/

I haven't enough familiarity to know which of these are still usable;
some may suffer from code rot.

VMs seem to be more usable than jails; the fact that the whole "bundle
of system" gets embedded into a single ball of mud (e.g. - a VM image)
seems to be an enormously useful thing that doesn't seem to have a
Jail analogy.

But I suppose that if things had occurred somewhat differently, and
jails had become the favoured virtualization mechanism, we'd probably
have seen tooling emerge to make that very easy.

But I'm not surprised that VMs have dominated.  They offer a solution
to the "I've got a Whole System I need to emulate, and I don't have
the time to figure out what are the tiny bits that I *actually* need.
So I'll just throw the whole ball of mud into a VM image.  After all,
disk space is cheaper than analyst time" problem.

>> 4) The ports/package system. One thing that is superior IMO with the
>> FBSD posrts system is the way they are able to use packages directly
>> from source and use a very clever patching mechanism, which is a
>> *light* modification to the original package.This makes it relatively
>> easy to use the newest versions of the source paakcges. Debian, on the
>> other hand (and may other a Linux distro)  , tend to modify packages
>> extensively to make them *their way* and this is not only inefficient
>> and resource intensive, but brings forth may problems and goes against
>> common-sense and cost-effective maintainability.
>
> I hate the ports system.  It is what I think is wrong with Gentoo too.
> Why the heck should every person be grabbing things from source when
> the same binary could have been generated once already.  It is inefficient
> waste of resources.  Compiling from source should be a last resort,
> not the norm.
>
> Debian tries to avoid modifying packages when possible, but meeting the
> FHS is a requirement and sometimes requries modifying the package if
> upstream's makefiles are that badly done.  Sometimes there are bugs to
> fix and while waiting for upstream would be nice, sometimes that can
> take a long time.  They do try to get the patches accepted upstream
> though.

The notion that Ports involves materially less modification to the
original packages than is involved with Debian or RPM packaging seems
likely to be a mirage.

And in practice, people use pkgadd rather a lot on *BSD, which heads
more down the "dpkg" route...

>> These are only scratching the surface. The point here is not saying
>> that FBSD is better than Linux because they each serve a purpose and
>> should be respected for that. Linux may be great for some applications
>> but that also holds true for *BSD and other Open Source OSs; things
>> like MenuetOS, Open Solaris, etc, which most Linux enthusiasts ignore
>> altogether, living in their own little Linux world and fighting over
>> KDE vs. Gnome and Debian vs. Ubuntu vs. Fedora, Free Software vs. Open
>> Source, etc.
>
> Once upon a time there was a system to allow Linux to run BSD binaries.
> Back then BSD was relevant and hence that was useful.  Now it is the
> other way around.
>
>> I use and love Linux on a daily basis, but also FBSD and MacOSX and
>> they are all great systems each with it's pros and cons, virtues and
>> flaws. And yes, it took me many years to abandon zealotry and discover
>> a broader and richer world in Free Software _and_ Open Source.
>
> I did see recently that one of the BSDs now supports 64cpu machines.
> I wonder if they have heard of USB 3 yet.  I know Linux handles 4096
> CPUs these days and has for a few years.

Oh, come on.

Sometimes Linux supports some hardware sooner than FreeBSD, and
sometimes hardware is supported first by NetBSD or FreeBSD.

As for machines with extraordinary numbers of CPUs, those tend to be
custom built things that are dramatically overpriced the day that
they're built, as they have to have weird custom memory and CPU buses
that deviate from what's typical and cheap.

Hardly anyone remembers Sequent :-).
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list