Very Computer

Quote:> I understand that this does have a number of advantages (more stable and
> 'standarised' systems), but -in the linux-world- the distributions
> are one of the main areas where there is a lot of competition.

Quote:> Also, special purpose distributions (like for real-time linux,
> clusters-technology ala beowulf, linux for embedded controllers,
> single-floopy distributions ala Linux-router project) are the
> reason linux get used for a lost of different different purpose outside
> the normal 'scope' of a unix-server).

--

 `-_-'   Ar rug t barrg ar do mhactre inniu?
  'U`    "Hint for long-term survival: be tasty, and farmable." -- Tanuki
         "And that's the real message of 'The Matrix'." -- Abigail

Quote:> : A question, I guess you use much of same tools that exist for linux (GNU
> : GCC, XFree86, KDE, Samba, Apache, netscape communicator, ...).
> : How much of the FreeBSD distribution (the complete system) is actually
> : written by the FreeBSD project.
> : The Kernel (of course), but besides that?
> : System administration tools? Binutils?
> None of the above.  All of the Berkeley unicies are the lineal
> descendants of the original Berkely UNIX from the mid 70's.

(I don't know if BSD had a Free C-compiler included, or do you use the
GCC?)

Quote:> This is
> the main difference between berkeley unix and linux, and thats why the
> BSD universe is so well grounded.   We have tradition, and in many
> cases, engineering decisions are based upon long standing experience
> with the problems.  People have written doct*dissertations on
> solving these problems.

IMHO, most papers in the field of computer-science are rather theoretic,
so can be implemented in any OS.
Only, is it much easier to take an existing OS and 'add' or rewrite a
certain portion of it, than it is to re-invent the warm water and build a
completely new OS from scratch.
(Except where new feature must be SO unlike the existing code; but I think
this still is small minority of the cases).

It is just that linux has a much less 'organised' way of developement.
I concider this just DIFFERENT, not 'better' or 'worse' but then the
more 'strict' developement model of the BSD-unices.

Anycase, as all parties (*BSD and linux) can and DO take ideas from each
other so -as a net result- everybody gains!

Quote:> Its safe to say that large portions of the FreeBSD kernel have been
> re-written since the release of 4.4BSD.    I won't belabor the
> history.  Suffice it to say that the existing BSD projects have just
> continued the long history of improvement.

Cheerio! Kr. Bonne.
--

Quote:>> I understand that this does have a number of advantages (more stable and
>> 'standarised' systems), but -in the linux-world- the distributions
>> are one of the main areas where there is a lot of competition.
> To me that simply means there is no competition in the kernel.

For kernel developement, this is the general scenario on how things work.

I take the example of linux-for-DECstations
(http://decstation.unix-ag.org/) as that is one I followed passively
-I have some left-over MIPS decstations I can use and yes, I know you can
run netbsd and openbsd on them (I 've actually had one of them running
NTP-server on OpenBSD).

- First you take, a certain version of the 'official' linux-kernel as
'starting-point'. (Usually, this is the latest developement kernel).

- You start your project, adding or changing that kernel.

- Once you have a 'working' project (which usually is after the the
official kernel-version has already gone up) you re-implement your changes
to the kernel, now every time to the latest developement kernels. (And
continue to work on the specific code of your project too of course)

- In a lot of case, your project can be seams as part of a bigger project.
(like the linux/decstation is actually a sub-project of linux/MIPS).
In these case, your code gets imported into the code of that project.

- If your code turns out to be good, stable and usefull enough, it gets
incorperated into the 'official' developement-kernel.

- If it makes sence to do so, your code also gets implemented into the
official 'stable' kernel-versions.

This is scenario if you are the only project working on in a certain area.

If there are several projects working on a simular feature, two things are
possible:
- The different projects merge into a single group. (Like the ports for
the mac-hardware).

- In the other case, there is competition in who's code goes into the
official linux-kernel.

To be complete, it should be noted that some projects that probably will
never go into the official linux-kernel as that would need a too large of
change of the kernel (like the micro-kernel linux-versions, the Real-Time
linux-version, MOSIX, ...).

Now, back to the distributions.
Unlike the kernel developement who all strive for a single point (the
official linux-kernel), there are a large number of different
linux-distributions available. This is because people use linux for a
large number of very different purposes.

Also, distributions are usually based on 'ready to run' binaries. (althou
the source in available, a lot of people (read: most of the) never
re-compile their kernel).

Quote:>> Also, special purpose distributions (like for real-time linux,
>> clusters-technology ala beowulf, linux for embedded controllers,
>> single-floopy distributions ala Linux-router project) are the
>> reason linux get used for a lost of different different purpose outside
>> the normal 'scope' of a unix-server).
> In FreeBSD you do this by running a different "make" target.

('First, we'll get the thing running, then we'll look how it works (as an
application), and -after that- we'll look at the code and see how we can
change it to fit our needs).

To be clear, I started my computer-carrier on a tandy color-computer
(6809-based machine sold as 'game machine'). On that machine, I ran
'OS/9' (nothing to do with MacOS/9), a real-time OS based on unix (not
code-wize, but as enviroment).
In the years after that, I used (in that sequence) AppleII, MS-DOS, unix
(some motorola-version at school), amiga, linux, OS/2 Warp, MS-windows,
Ultrix, DEC OSF/1, and solaris,
(I am currently looking into FreeDOS as I have a old 286-based portable I
would like to use packet-radio station.

So, I am strickly 'for' or 'against' a certain OS. Most of them have their
merrits in their fields.

Cheerio! Kr. Bonne.
--

Quote:> - In the other case, there is competition in who's code goes into the
> official linux-kernel.

Quote:> Unlike the kernel developement who all strive for a single point (the
> official linux-kernel), there are a large number of different
> linux-distributions available. This is because people use linux for a
> large number of very different purposes.

        1. What package-management tool they use.
        2. What install tool they use.
        3. What packages are installed by default.
        4. How /etc is laid out.

They all pick and choose from the same packages, so when all is said and
done you can pretty much make any distribution contain the same stuff as
any other distribution. It's just a matter of how easy that is to do.

And there's basically two ways to lay out /etc: you can have one big config
file that you edit to configure stuff (SuSE, BSD) or you can have a bunch of
small config files laid out in a directory tree (Red Hat, System V).

There's not a whole lot of room for creativity there. And yet, that's where
Linux distributions end up trying to compete... so you get radically different
trees without any clear advantages. There's some clear *dis*advantages to every
one I've tried so far, though.

So you end up with systems that could better have been produced by taking
Debian (because dpkg sucks a LOT less than RPM) and adding a custom pretty
installer... because then at least they'd all be configured the same way
instead of duplicating the worst aspects of the UNIX diaspora of the '80s
for no clear gain.

--

 `-_-'   Ar rug t barrg ar do mhactre inniu?
  'U`    "Hint for long-term survival: be tasty, and farmable." -- Tanuki
         "And that's the real message of 'The Matrix'." -- Abigail

: OK for the 'bin-tools' and stuff like mail and vi, but AFAIK X, KDE, bash,
: ... are not part of the 'Berkely UNIX'.

    Quite so, nor are they part of FreeBSD. X, bash, KDE are all available
as ports and packages but they do not form part of FreeBSD. I think the
same is true of the other BSDs too.

Quote:>> - In the other case, there is competition in who's code goes into the
>> official linux-kernel.
> So the competition is based on "what Linus thinks is the right thing".

What is true is that there seams to be no formal 'commity' on the
descision what goes into the kernel and what doesn't.

From what I've heard, the rule seams to be that if you make a strong case
in the kernel mailing-list (= good code, good design), you'll probably end
up in the official release.

On the other side, nothing stops you from maintaining your own
kernel-patches parallel to the official kernel.
Most embedded linux distributions also contain real-time linux, althou
that is no official part of the linux-kernel.

Quote:>> Unlike the kernel developement who all strive for a single point (the
>> official linux-kernel), there are a large number of different
>> linux-distributions available. This is because people use linux for a
>> large number of very different purposes.
> So far as I have been able to tell, the big differences between the
> distributions are:
>    1. What package-management tool they use.
>    2. What install tool they use.
>    3. What packages are installed by default.
>    4. How /etc is laid out.
> They all pick and choose from the same packages, so when all is said and
> done you can pretty much make any distribution contain the same stuff as
> any other distribution. It's just a matter of how easy that is to do.

IMHO, their are four kinds of distributions:

- 'General purpose' distributions:
Here you a number of 'mainstream distributions' (redhat, Suse, debian,
...) and a number of 'derivates' (like corel -based on debian-, or
mandrake -based on redhat-).

The differences are -here- indead limited to the things you mention.

The main thing they compete at (at this time) is the
installation-procedure and the overall system management tools.

- 'localised' or special-usergroup distributions:
Distributions aimed at a certain country (e.g. red-flag linux,
turbolinux, mandrake, turkish-language linux, korean-language linux, ...),
or a special group of users (like Blinux: linux for the blind, ...).

Technically, most of these distributions are based on a 'general'
distribution, but with special additions.

- 'NON-intel' distributions:
Althou some general purpose distributions are aimed at more then only the
intel-platform (especially debian), there are a number distribution that
aim specifically at a certain type of box (e.g. 'yellow-dog linux for
powerPC Mac and IBMs).

- 'Special purpose' distributions:
Distributions aimed at certain specific applications. Some examples:
- 'Linux Router project' (a single floppy distribution),
- 'embedded linux',
- 'clustering/beowulf linux',
- 'teaser' linux-distributions (like 'demolinux', that boots of a CDROM
and does not install anything), or 'winlinux 2000'.
- ...

Anycase, it always stays a balancing execise between two things: the
freedom to make a distribution for YOUR specific need, and -on the other
hand- the need for a standardisation so that software will run on as-much
distributions as possible.

So, let see how important these 'linux standard' really is:
- For some distributions (say like for embedded linux) it is not important
at all, as these kind of distributions serve a specific need and don't
need to run 'standard software'.

- For software distributed in source, the './configure' and 'make install'
scripts are usually intelligent enough to check on what kind of
distribution you have and install the software in the correct manner.

- In fact, the same thing is also true for instalation-scripts of software
that is distributed in binary form.
For every platform (i386, powerpc, ...), there are only a limited number
of 'main' distributions, so the installation-scripts only needs to take
each one of them in account.

Anycase, I hope the debian-group succedes in creating a debian-system on
top of a freebsd kernel.
In that case, we can test one system (debian) with three different
kernels: linux, freebsd and the hurd.

Cheerio! Kr. Bonne.
--