What's that "GNU/Linux" in the beginning? [LWN.net]

What's that "GNU/Linux" in the beginning?

Posted Dec 30, 2006 23:08 UTC (Sat) by man_ls (subscriber, #15091) [Link]

Sure, just look under non-Linux Debian ports. There's also Nexenta: Debian on the OpenSolaris kernel.

What's that "GNU/Linux" in the beginning?

Posted Dec 31, 2006 3:36 UTC (Sun) by landley (guest, #6789) [Link]

> I have not considered this issue in a good long while now, but are there
> any "Linux" distros out there with no hint of the GNU software?

I'm working on one. Firmware Linux (http://landley.net/code/firmware).
It uses busybox and uClibc instead of the gnu tools and glibc.

Currently, building it still requires four gnu packages (gcc, binutils,
make, and bash), but replacements for all four are in the works. (The
replacement for gcc/binutils is tcc, which still needs some work, and I'm
writing my own shell and when that's ready, my own make.) If your final
system doesn't need to be a development environment, then it doesn't have
to have any gnu code in it at all.

By the way: Linux came out of the Minix development community, not the GNU
project. If you accept the logic RMS uses to insist it's not Linux
but "GNU/Linux/Dammit", then the company that put out OS/2 was Watcom.

Rob

What's that "GNU/Linux" in the beginning?

Posted Dec 31, 2006 14:11 UTC (Sun) by gnb (subscriber, #5132) [Link]

I'm curious: is tcc really a plausible gcc replacement? Having worked on
systems that used gcc as a cross-compiler I'm aware that some of it,
particularly the build system, is "interesting" and it might be nice to
replace it, but a lot of work has gone into the gcc optimiser and last I
checked it seemed to generate pretty reasonable code (at least on ARM).
I'd guess a distribution called Firmware Linux is pretty size-conscious,
so optimisation quality must be a significant factor for you.

What's that "GNU/Linux" in the beginning?

Posted Jan 4, 2007 20:37 UTC (Thu) by dwheeler (guest, #1216) [Link]

tcc is quite usable, but it's not a gcc replacement. tcc parses the statements and nearly immediately generates assembly that implements that statement, with VERY little optimization. The good side: tcc compiles VERY quickly, in some cases 10x faster than gcc. Indeed, there's a demo "FASTBOOT" that boots the tcc compiler, which then compiles and runs the Linux code from source (!). The downside: tcc code runs VERY slowly compared to gcc-generated code. By design, tcc generates something that works, but it doesn't have any of the intermediate structures that make good optimization possible. Granted, tcc-generated code runs fast enough for many purposes. But most users NEVER compile programs, and constantly run them, so trading away run-time performance is often not worthwhile. That said, tcc is very good for some purposes. I used it for my work to counter the trusting trust attack. tcc had some bugs, and the primary developer isn't doing much maintenance of tcc (because he's busy with other projects like QEMU), which is another problem. I some others are doing some maintenance of tcc.

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 19:38 UTC (Fri) by landley (guest, #6789) [Link]

I've got my own mercurial repository which has turned into a semi-fork:

http://landley.net/hg/tinycc

But I've got too many other things going on to want to become the
project's new maintainer right now. The old maintainer (Fabrice) has his
hands full with QEMU.

And it does do a little optimization, simple constant propogation and
such. It wouldn't be that hard to shoehorn dead code elimination in
there, which makes it a lot more usable for things like the linux kernel
and busybox (where dead code elimination is relied on by the configure
system to avoid lots of hideous #ifdefs).

Getting the linker to garbage collect is a larger project...

What's that "GNU/Linux" in the beginning?

Posted Jan 9, 2007 17:20 UTC (Tue) by nix (subscriber, #2304) [Link]

Doing DCE properly requires a lot of dataflow analysis which would be really rather hard to ram into tcc (at least it would have been the last time I looked at it).

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 17:37 UTC (Fri) by nix (subscriber, #2304) [Link]

The build system is a good bit less 'interesting' than it used to be (although still quite hairy). (Not that GCC is devoid of cruft in other areas, of course...)

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 19:54 UTC (Fri) by landley (guest, #6789) [Link]

The gcc build system sucks rocks, I've just learned where to hit it with
a large stick.

A compiler is a program to turn input files into output files. It takes
multiple sources of input (c source, header files, libraries), but so
does a docbook to PDF converter that needs fonts or style sheets.
There's no fundamental difference between the two.

If compiling the docbook to PDF converter cared a lot whether it was
running on ARM or Mips or Sparc it would be broken and unportable. But
you can't configure gcc to say "build arm files" without telling it "and
you're running on i386" as if it makes a huge difference.

The difference between a cross compiler and a native compiler is hugely
artificial, and gcc's insistence on being told --host as well as --target
is stupid. The fact it can be told _three_ (--host, --target,
and --build) is just _crazy_. And its insistence that if --host
and --target are the same string then you're obviously not creating a
cross compiler, so build everything differently, is just _evil_. (Hello,
host has glibc, target has uClibc. The dynamically linked binaries
you're producing won't run on the host because uClibc isn't installed.
YOU ARE CROSS COMPILING.) One of the reasons I like tcc is that it
doesn't make a big deal about this: configure it to produce arm binaries,
build it _with_ a compiler that links it against uClibc, and it just
works. There doesn't have to be a special name for doing that ("canadian
cross") because it's NOT A BIG DEAL.

If the current gcc build system is a distinct improvement over what came
before, we are _beyond_ "damning with faint praise".

And don't get me started on its' path search logic.

What's that "GNU/Linux" in the beginning?

Posted Jan 9, 2007 17:34 UTC (Tue) by nix (subscriber, #2304) [Link]

The path search logic has just got a little cleaner :)

Of course it makes a difference what the build system is: it needs to know if the files it builds to incorporate into the (many) little-language code generators it builds and uses during the build process can also be linked into the final compiler binary. It needs to know if a three-stage bootstrap is even *possible* or whether `make' should invoke a one-stage build (`make bootstrap' is so 2004, y'know, it's just `make' like every other package these days). It needs to know if there are any differences between e.g. the floating-point representation used on the build and host system. It needs to know if it can run configure tests to determine properties of the host system, or whether it has to assume safe defaults (you wouldn't want it doing the latter in the common case). (tcc doesn't need to do this to such a degree because it doesn't come with a bunch of runtime libraries. Also it doesn't need to cater for the nest of snakes which is exception unwinding and the related nest which involves shared libraries, destructor invocation order, and so forth.)

And as for the distinction between a native and cross-compiler being artificial, well, in *theory* a compiler could be made that didn't care what its host system was, but in practice unless it is to be intolerably slow it *must* know the machine's native types at least (which varies between OS and platform because it is ABI-dictated, and on many platforms GCC/binutils do not set the ABI). (A sufficiently nonportable compiler could avoid paying attention to systems that don't have IEE754 floating point, but GCC is not that nonportable, or at least at one point it wasn't: I'm not sure how many non-IEEE754 systems are left. I think some are, discounting ia32/x87 of course with its horrible `extended precision' mess, which is slowly becoming legacy anyway as SEE fpmath takes over.)

The `target triplet' stuff GNU has got is a bit ugly, but if you consider it to be an `ABI-and-OS-and-core-libraries indicator' (which is basically what it is), then it makes a bit of sense. uClibc just needed a new target triplet/quadruplet (and, oh look, *-*-*-uclibc works perfectly well).

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 19:42 UTC (Fri) by landley (guest, #6789) [Link]

The tradeoff here is do I want to include 35 megabytes of gcc/binutils to
build "hello world", or do I want a 100k executable to do the same thing?
And if you ship a compiler that can't rebuild the system, it's not a real
compiler ("gcc 2.96/kgcc" for example).

Yes, the system is size conscious, but there's a lot of meanings for
that. (Install image, runtime memory, requirements of the system you
build it on...) Nice to have multiple options...

What's that "GNU/Linux" in the beginning?

Posted Jan 10, 2007 10:32 UTC (Wed) by nix (subscriber, #2304) [Link]

I'd agree that tcc is a good choice for a self-hosting embedded distro (although a lot of `embedded'/handheld-or-smaller systems these days could swallow most of a normal Linux distro without breaking a sweat, there are some systems that can't. Whether this will still be true when really large flash RAM chips become common is another matter.)

What's that "GNU/Linux" in the beginning?

Posted Dec 31, 2006 22:51 UTC (Sun) by Arker (guest, #14205) [Link]

Linux was built using Minix and GNU at the start. The use of Minix to bootstrap the project ended very quickly however.

I was using GNU/HPUX before I ever heard of Linux. When I found Slackware, I no longer had to beg for access to the math departments HP boxes, I could run GNU on a cheap 386 at home. Of course working with boxes of floppies and downloading all week on a dialup SLIP connection (yes, PPP came later) was a pain in the butt, but it was well worth it.

Don't tell me I'm not running GNU/Linux, I know better.

What's that "GNU/Linux" in the beginning?

Posted Jan 1, 2007 15:35 UTC (Mon) by grouch (guest, #27289) [Link]

It might be appropriate here to mention an older work:

Linus began to experiment with his own hacks, using Minix as scaffolding to develop a new program. "I made two processes and made them write to the screen and had a timer that switched tasks," he recalls. "One process wrote A, the other wrote B, so I saw AAAA, BBBB, and so on."
[...]
GNU's aim was to write a complete "free" version of Unix - the kernel and all the associated elements - that is, one that gives users the freedom to share and change software but not add restrictions and impose them on others. With the Linux kernel, Stallman says, "the available free software added up to a complete system."
Rather than wait for someone to write applications designed specifically for his operating system, Linus tweaked Linux to perfectly fit GNU's pre existing apps. "I never ported programs," Linus says. "I ported the kernel to work with the programs. Linux was never the primary reason for anything - user programs have always been the reason."
-- The Greatest OS That (N)ever Was, Glyn Moody, August, 1997

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 20:13 UTC (Fri) by landley (guest, #6789) [Link]

Interesting juxtaposition, but the connection he's trying to suggest by
it isn't really there. "Just for Fun" goes into a lot more detail, such
as the fact that the system call reference he used to implement his
system call list was the SunOS manuals in his university library. (And
nobody calls it Sun/Linux.) The working Unix systems he had lying around
were Minix and the university's MicroVax he dialed into to access the
internet. (And you'll notice Linux grew out of his terminal program for
dialing into that MicroVax, he wrote the term program to boot from a
floppy because Minix's serial handling couldn't even keep up with 2400
baud without dropping characters, and he had to take over all the
hardware himself to get his home PC to talk to the university machine.)

You might also want to read the first year of the linux kernel
mailing list (which was pretty low traffic back then). Back when I did
that, I bookmarked a bunch of posts I found interesting when I read
through it, and strung the posts together into two files:

http://landley.net/history/mirror/linux/1991.html
http://landley.net/history/mirror/linux/1992.html

What packages are mentioned? Several minix files, the mtools package
(from isc, not fsf), X11 is a pervasive early goal (since that's the big
thing minix just couldn't do). In 1992 mentions of gnu tools start
showing up, but the emacs he used was microemacs and version 0.12
included pmake from bsd. The first networking support was through the
KA9Q package.

Kernel development being driven by running real applications doesn't have
anything to do with gnu. This is not mere opinion, I've been researching
computer history for years. http://landley.net/history/mirror

Rob