Poettering: The Biggest Myths

Posted Jan 29, 2013 12:49 UTC (Tue) by khim (subscriber, #9252)
In reply to: Poettering: The Biggest Myths by nix
Parent article: Poettering: The Biggest Myths

glibc is also portable, in theory -- it's just that all the ported bits have fallen into disuse and disrepair.

This is nice theory but it's not supported by practice. You see, just recently we've needed to port GLibC to ARM for PNaCl-arm. We've talked about about this project with Roland and eventually the resolution was to add support for NaCl-arm to GCC. If Roland feels it's easier to add support for the new architecture to GCC rather then port GLibC to Clang I tend to think that it's basically impossible to do in practice.

The portability framework is unlikely to rot anytime soon because it is also the system library for the Hurd, which at that level is quite thoroughly unlike Linux in some ways.

Sure. You can use GLibC with two different kernels (and soon with third one if you'll count NaCl as separate "kernel") but it can only be used with GCC and binutils - and you need quite recent versions of both.

Kinda like systemd with udev, journald and others: you can use udev separately but systemd can only work with one particular version of udev and one particular version of journald.

Heck, until very recently there were a bunch of targets on which you could run GCC but could not use binutils -- your claim is false on its face.

And there are bunch of targets where you must use GNU ld and GNU as and can not use system-provided versions. Basically it's all very simple: GNU tools are supposed to be used with other GNU tools only but where feasible to use system-tools provided by different platforms they do that. This is very explicitly not some nirvana of free-for-all pick-and-choose, but a set of decisions made by sane people: they used system versions of tools where it was harder to port binutils to the new platform and the forced GNU tools in most other cases.

Poettering: The Biggest Myths

Posted Jan 29, 2013 16:14 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

One bit of portability you will *not* generally find is portability for lowlevel components like C libraries to different compilers. I am not at all surprised glibc only works with GCC: it's stuffed with GCC-specific stuff, just as its makefiles are very heavily GNU make dependent. (I'm amazed you thought it might have been worth trying to make it work with something else.)

Poettering: The Biggest Myths

Posted Jan 29, 2013 20:22 UTC (Tue) by khim (subscriber, #9252) [Link] (3 responses)

One bit of portability you will *not* generally find is portability for lowlevel components like C libraries to different compilers.

Many C libraries can be compiled with different compilers. Including GLibC 1.x. But version 2.x was redone to consciously use features of GCC - just like systemd was consciously redone to use features of Linux. Somehow it's ok for GLibC but not for systemd? Why?

Poettering: The Biggest Myths

Posted Jan 30, 2013 16:21 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Well, I wasn't one of those arguing that systemd should be portable across OSes: init systems generally aren't, not even the simple ones. I was arguing against your claim that this is universal in other sorts of software: it is not. Lots of software supports portability in various ways, be that compilation with different compilers (binutils, GCC), or running on different platforms (glibc, to an extent)... and huge amounts of software doesn't care e.g. what glibc or binutils or kernel version it was built with. The coupling is not as tight as you suggest.

Poettering: The Biggest Myths

Posted Jan 31, 2013 22:43 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

I was arguing against your claim that this is universal in other sorts of software.

Please remind me where I've made such claim.

Lots of software supports portability in various ways, be that compilation with different compilers (binutils, GCC), or running on different platforms (glibc, to an extent)... and huge amounts of software doesn't care e.g. what glibc or binutils or kernel version it was built with.

Lots of peripheral software is portable. The core is not. And this is exactly what I've said in the very beginning: Most popular OSes are all almost completely monolithic per this definition: Android, Busybox, BSDs. Only GNU/Linux is weird creature which includes robust and reliable monolithic part (GNU components: GCC, GLibC, binutils, coreutils, etc - they are not really supposed to be used with anything else) and loose and flaky things like sysvinit with it's plethora of weird scripts.

Take any non-Linux-based OS you want - and you'll find out that he core is built from a single repo using a single build script. Kernel, libc, some core utilities. The next ring is more portable: BSD make itself may be ported (and was, in fact, ported) to other platforms but you can not use anything else to build, say, FreeBSD's kernel or libc. The outermost ring is the most portable: these are applications which can be ported to other platforms.

But a quirk of history made Linux an exception from this rule and, surprise, surprise, this exactly where a lot problems originates: various tiny core components don't cooperate well enough and require plethora if work from distribution makers to somehow create something usable. And even then they often fail. Note that usually you can not even replace these core components: even distributions which formally offer such ability (like Debian or Gentoo) crumble and start misbehaving when you actually try to use such "freedom".

The coupling is not as tight as you suggest.

The coupling is as tight as I suggest and to me systemd looks like a try to finally bring this approach to desktop and server linux. Note that places where Linux dominates - such as routers and mobile phones - already use this approach.

P.S. It's also looks funny to me when people try to say that what systemd developers are doing is somehow against the "UNIX philosophy" when, in fact, they are doing what UNIX did from a day one and what all direct descendants of UNIX are still doing today.

Poettering: The Biggest Myths

Posted Feb 2, 2013 19:14 UTC (Sat) by nix (subscriber, #2304) [Link]

I'm not even going to bother arguing with this. If you want to keep arguing that black is white and that GNU binutils, GCC, and the other parts of the toolchain are nonportable, that's fine. You're wrong, and spouting nonsense, but you're allowed to do that.

Poettering: The Biggest Myths

Posted Jan 29, 2013 16:18 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

This is very explicitly not some nirvana of free-for-all pick-and-choose, but a set of decisions made by sane people: they used system versions of tools where it was harder to port binutils to the new platform and the forced GNU tools in most other cases.

This is entirely incorrect. System versions of tools are supported for toolchain building where they are not too broken to work reliably, particularly if it seems likely that people would otherwise need to resort to cross-compilation to get the thing built on that platform. Heck, the horrible bundled K&R HP-UX 10.x C compiler was supported for many many years, despite barely grasping advanced concepts like functions: if your allegations were true it would never have been supported at all. (It is true that, these days, it is much easier to cross-compile from a random Linux system than it ever was before, so tolerance for totally broken crap like that is going down. On the gnulib list, they say "we are not running a software archaeology project", and they are quite right.)

Unfortunately there are a lot of broken assemblers, linkers and the like out there. (Oddly, one of the most often broken components is sed. sed! How hard is it to write a working sed, I ask you...)

Poettering: The Biggest Myths

Posted Jan 30, 2013 0:48 UTC (Wed) by malor (guest, #2973) [Link] (1 responses)

(Oddly, one of the most often broken components is sed. sed! How hard is it to write a working sed, I ask you...)

Heh, I bet most of the broken implementations started out with that exact thinking..."how hard could this be?"

Poettering: The Biggest Myths

Posted Jan 30, 2013 16:30 UTC (Wed) by nix (subscriber, #2304) [Link]

Most of it seemed to be classic Unix thinking, "we can just use a fixed N-character buffer here, nobody will want more than X of these". So you get fun like seds that coredump if you use more than 512 characters in an s// expression's regexp part, and that sort of thing. A crashing sed tends to annoy configure scripts...

Poettering: The Biggest Myths

Posted Jan 31, 2013 21:45 UTC (Thu) by dirtyepic (guest, #30178) [Link]

>Sure. You can use GLibC with two different kernels (and soon with third one if you'll count NaCl as separate "kernel") but it can only be used with GCC and binutils - and you need quite recent versions of both.

I'm not sure what you define as quite recent, but as of last month the minimum requirements are binutils-2.20 and gcc-4.3, which are both 3+ years old. Before that you could still build glibc with gcc-2.95.3 with a bit of futzing.

Oh, it also requires a kernel later than 2.6.16 (or 3.7 if you want AArch64 support which is obviously a conspiracy) so I guess you'll have to make some room for it under your tightly-knit GNU umbrella.