Ubuntu first time

Tue Jan 10 18:50:00 UTC 2012

On Tue, Jan 10, 2012 at 1:02 PM, Christopher Browne <cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> 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.

[...]

> 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>
>

True but not applicable to *all* scenarios, PRECISELY my point on that
Linux is great for many things, but just because it is, people should
not go out minimizing other great Open Source OSs, _especially_ when
ignoring your own weaknesses. The point is you don't go near the fire
if your tail is made of straw.

[...]

> 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.
>

Awesome way to put it.

> 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.
>

Again, there are places where Linux excels, and Debian as well. For
example I would Debian Linux on most pseudo-embeded systems (e.g. Pico
ITX and alike), but probably not so much so for smaller hw.

[...]

> 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/
>

True for the advanced chroot part, but these implementations would
also require that the kernel is jail-aware. So I think my statement
still holds true because I haven't come across a distro that
implemented jails and kernel being jail-aware for true
pseudo-virtualization (yeah it sound strange, but I think you know
what I mean).

> 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.
>

Yes and no, again, it depends. Slicing the server into service jails
is an application of jails that has nothing to do with virtualization
in that sense. It's more about more granular control, security,
performance and maintainability.

To give you an example, on _my_ FBSD servers Apache runs on a Jail and
reverse proxies to the application apaches sitting on other jails. In
other words, our Web2Project system along with other php52 apps run in
a production jail that is fined tuned to php52, while our php53 stuff
runs in a specific php53 jail. I also have jail flavors (I use
EzJail), so for example I can create a Perl/Catalyst 5.8 environment
with Perl 5.10 in about 5 minutes, and run it side by side with a
Catalyst 5.9 with Perl 5.12. They all see the internet through a main
Apache reverse proxy running on another jail. Even the MTA sits in
it's own jail, so the base system has never even compiled a single
package, making it extremely secure.

Now, I would *love* to do that with Linux, and diversify my Internet
servers but I can't. Today it's simply not possible.

> 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.
>

Yeah, EzJail

> 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.
>

Could be, but YMMV in our case we take great care to use our hardware
as efficiently as possible because we simply can't afford hundreds of
servers. With just some quad cores I am able to pack much more on a
single server that I would with Linux, and _without_ experiencing
problems with updates. I think everyone here should rememeber the
php52 to 53 fiasco. It happened to me but never again, so my use of
Jails is not so much VM as I pointed out above.

[...]

> 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.
>

A valid matter of opinion, yet _IMO_ the posrt/patches system is more
elegant and you can see much less mods in the resulting software. Just
take Apache 2, PostgreSQL or MySQL on Debian for example. Same goes
for example for RedHat's "services".

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

Yes, but they are based on ports with the default make options.

[...]

>> 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.
>

Note that _is not_ my commentary above. I completely agree with your
point of view bellow:

> 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 :-).
> --

Great un-passionate discussion. Thank you!

Cheers,

-- 
Alejandro
--
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