Serious danger of being impressed

On Tue, Jun 12, 2007 at 03:18:45AM +0900, Rick DeNatale wrote:

On 6/11/07, Chad P. [email protected] wrote:

Ubuntu is a Debian fork.

More true in theory than in practice. There was a lot more noise
about the fear that Ubuntu would be a fork back in 2005 when Debian
users were getting tired of waiting for Sarge and Ubuntu started to
appear on the horizon.

If you cannot install a Debian package in Ubuntu, or vice versa, without
running substantial risk of breaking the system, it sounds like a fork
to
me.

feeds whatever changes they make back to the sid stream.
In Ubuntu releases, there’s a lot more changed. A simple look at some
of
the software dependencies enforced by APT in Ubuntu, as contrasted with
those in vanilla Debian, will make that clear.

approach. Back when Ubuntu “Badger” was in the throes of being
released, Debian Woody was several years old, and Sarge looked to be
slipping almost faster than the release date was approaching,
something which Murdock alludes to in the post I quoted.

I really don’t think the waterfall vs. agile analogy holds even slightly
true. Both Ubuntu and Debian strive to produce “complete” distribution
releases with each release cycle. Debian maintains a constant state of
operational functionality during development of the finished release
(thus the “testing” branch), and Ubuntu (from what I’ve seen) provides a
more “there’s nothing to see until it’s done” state of development until
it approaches release-worthiness. Neither of these sounds anything like
either Waterfall or Agile development to me. In Waterfall development,
nothing’s functional until you’re done, and you’re not done until you’ve
achieved some overarching plan. In Agile development, you have
functional milestones, but you’re not really done until you’ve achieved
some overarching plan (though, of course, the plan changes while being
executed).

provides both newer code in the latest release for those who want it,
and more predictable support of older releases for those who need
stability.

It’s pretty clear that the unfortunate comparison of Debian to Waterfall
development was no accident. You have a definite Ubuntu bias.

It has less in common with Debian itself than
PC-BSD and DesktopBSD have in common with FreeBSD, and may even have less
in common with Debian than Dragonfly BSD has with FreeBSD.

I don’t know enough about those distributions to make the comparison,
but from my experience, Ubuntu doesn’t feel like a fork. Even if
Debian doesn’t take ALL of ubuntu’s packages as time goes on, I
predict that the bulk of the code will remain compatible.

Code: yes. Packaging: no. Since Linux distributions are defined by
their software management systems and installers more than by the source
code inside the various pieces of software, that pretty much makes
Ubuntu
a fork (though a still-recent one that attempts to derive some benefit
from similarities between the two distributions).

That all said, while I’m a happy Ubuntu user, I don’t use packaged
versions of some specific software, most notably Ruby. This isn’t
because of Ubuntu but because of Debian. In the case of Ruby one
major reason is because, as far as I know unless it’s changed
recently, Debian (and therefore Ubuntu) doesn’t really support gems.
Now this may have changed recently, but I’ve been happy installing
Ruby and Gems from source, and gems as gems.

Whether or not Ubuntu supports gems is not dependent upon whether or not
Debian does so. It’s dependent upon Ubuntu management decisions. The
Ruby packages have already diverged nontrivially from those in Debian
(though obviously not as much so as certain other packages).

On Jun 11, 2007, at 1:18 PM, Rick DeNatale wrote:

Murdoch pointed that out at the time:
using the traditional Debian model of "we’ll ship the next stable
something which Murdock alludes to in the post I quoted.
provides both newer code in the latest release for those who want it,
Debian doesn’t take ALL of ubuntu’s packages as time goes on, I

Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

Uh, Debian does run gem and gems just fine.
Shared hosting provider DreamHost is proof of that.
Their servers are Debian, and they do have gems. I’ve installed my
own local gems on an account there.

On 6/11/07, Benjamin K. [email protected] wrote:

parallel which once shared a common code base, and these multiple
“Ubuntu is a crappy Debian fork!”? I said nothing of the kind in my

Secondly, you say “The key component of forking is incompatibility…”
I can personally attest that Ubuntu and Debian are compatible in a number of
ways (but not all!). I’ve used Debian packages in Ubuntu before (and
vice-versa)

Ubuntu is a downstream version of Debian - it’s Debian, with changes,
re-synced every 6 months. How about, “Ubuntu is a Debian patch”. ?

Is this the place, or the thread, to discuss this?

Forgive my ignorance, I"m a ‘born again noob’, and I always will be.

John J. wrote:

Uh, Debian does run gem and gems just fine.
Shared hosting provider DreamHost is proof of that.
Their servers are Debian, and they do have gems. I’ve installed my own
local gems on an account there.

I think the point is that a gem can’t be installed as a .deb, so apt
can’t have any knowledge of them.

On 12/06/07, Chad P. [email protected] wrote:

On Mon, Jun 11, 2007 at 04:27:01PM +0900, Dick D. wrote:

Ok, thanks for the advert. Debian has its own problems, but this isn’t
the place to discuss them.

On 11/06/07, Chad P. [email protected] wrote:

Ubuntu is a Debian fork.

Uhh . . . what? I said it was a fork. I didn’t say it was crap. I’m
not sure where you’re coming from with the hostile tone.

I wasn’t trying to be hostile, but that was your second post about
Ubuntu and
Debian and the thread wasn’t about either.

So . . . why does your statement read as though you thought I said
“Ubuntu is a crappy Debian fork!”?

That would be your first post, saying :

“Ubuntu is far more suited to the average MS Windows transplant, I
suppose”

:slight_smile:

On Tue, Jun 12, 2007 at 11:35:20AM +0900, Bill G. wrote:

[ snip a bunch of quoted detritus from the “fork” discussion ]

Is this the place, or the thread, to discuss this?

Probably not.

Forgive my ignorance, I"m a ‘born again noob’, and I always will be.

Your point is well taken. If anyone needs forgiveness, it’s me and the
others involved in this tangent.

On Tue, Jun 12, 2007 at 03:47:32PM +0900, Dick D. wrote:

not sure where you’re coming from with the hostile tone.
“Ubuntu is far more suited to the average MS Windows transplant, I suppose”
At the time I typed that sentence, I meant that it provided a more
familiar face for the recent transplant, increasing comfort for people
not steeped in Linux wisdom. One might say that my statement only
implied that Ubuntu is more “user friendly” to recent MS Windows
converts
than vanilla Debian.

Isn’t “user friendly” supposed to be a good thing, all else being equal?

The Rubygems package is now in Debian/Ubuntu, but it is mildly
crippled. However if you run

gem update --system

then it magically turns into the normal ruby gem system.

APT still doesn’t know anything about gems, but it is less of a
problem than you’d think.

My approach with Ubuntu is to install from APT packages unless the APT
package is just a port of a gem.

On 11 Jun 2007, at 14:15, M. Edward (Ed) Borasky wrote:

Well, as long as we’re talking virtualization, has anyone managed
to get
a Xen system on one of the chips with the virtualization assist to run
OS X as a “guest?” Or does Xen not support the special hardware tweaks
in a Mac? Dual or triple booting is a pain.

I know of people running OS X as a guest inside VMWare so it should
be possible, but obviously Xen’s approach is sufficiently different
that I wouldn’t expect much (if anything) in the way of driver support.

Ellie

Eleanor McHugh
Games With Brains

raise ArgumentError unless @reality.responds_to? :reason

Eleanor McHugh wrote:

Ellie

Eleanor McHugh
Games With Brains

raise ArgumentError unless @reality.responds_to? :reason

It’s been a while since I looked, but IIRC there are two ways to run
Xen:

  1. You boot the Xen kernel, which is a modified Linux kernel. It does
    all the I/O and driver stuff. Guest machines require a modified kernel,
    which IIRC only exists for Linux.

  2. If you have the Intel or AMD virtualization-enabled chips, you boot
    the Xen kernel and it can then boot and OS with an unmodified kernel.
    This works for at least Windows and Linux, but I don’t know about MacOS.

In any event, the drivers in mode 2 are the guest OS drivers, so it
“should work”.

On 6/12/07, Bill G. [email protected] wrote:

On 6/11/07, Benjamin K. [email protected] wrote:

Is this the place, or the thread, to discuss this?
It depends. --note that I carefully have deleted your quote :wink:
I have no idea, but this community seems to be very tolerant and
interested in things orbiting around ruby.
On the rare occasions when people got upset with discussions and asked
politely to take a thread offlist that is just done.

Personally I think this topic is quite interesting, others of course
might not, please not that there is the not so slight possibility that
the choice of the distro intervenes with your ruby experience.

Forgive my ignorance, I"m a ‘born again noob’, and I always will be.
You mean like eternal youth :wink:

-Benjamin K.
Cheers
Robert

Erratum
echo “quote” | sed /quote/sig/

Sorry
R.

On 12 Jun 2007, at 15:37, M. Edward (Ed) Borasky wrote:

all the I/O and driver stuff. Guest machines require a modified
kernel,
which IIRC only exists for Linux.

  1. If you have the Intel or AMD virtualization-enabled chips, you boot
    the Xen kernel and it can then boot and OS with an unmodified kernel.
    This works for at least Windows and Linux, but I don’t know about
    MacOS.

In any event, the drivers in mode 2 are the guest OS drivers, so it
“should work”.

Mode 1 would definitely not work with Apple’s distribution, but given
that Darwin’s kernel is open source (and already much abused in
various other ways) it should be possible to build a Xen-friendly
version. However I’m not aware of anyone currently working on this.

Ironically Mode 2 could be more problematic as OS X would expect Mac-
like hardware, so if Xen provides virtual hardware in the same way as
VMWare that could restrict functionality. However if it fully
supports Intel’s Vanderpool technology and the host machine had
hardware supported by OS X natively then in theory it should just
work out of the box. If only I could justify the time to experiment…

Ellie

Eleanor McHugh
Games With Brains

raise ArgumentError unless @reality.responds_to? :reason

Indeed, relying on apt is not always good. It’s great for trying out
packages, but in the end, you will be better off in your
understanding of the tools you are using if you just install them
yourself. With Rails and Ruby you’re eventually going to have to do
installs yourself anyway, unless somebody else is doing it for you.
The same goes for OS X and MacPorts’ opt, it is nice and convenient,
but the paths are going to be non-standard and you’ll have to still
customize a lot of things to get things working, so you’ll still need
to know the how/what/where/why.

If you can write the code, you can definitely install the stuff. It’s
worth it for your Ruby points.