systemd has now their private libc

... waiting for Linux kernel rewrite that systemd will ship ;)

&quot said:
Heya,

I just added a new module to systemd git, “libc”, and you are probably
wondering what that is about. Here’s a quick overview over what this is
and our plans with it.

We figured to complete the systemd project we were still lacking an
email program[1]. In order to get this off the ground quickly we noticed
we’d need a libc first. We had the option of either merging glibc into
systemd, or write a new C library. Of course, we are pretty good at
rewriting existing programs (we are simply faster doing that, since we
don’t have to read so much code), so we opted for the latter. The new
module ‘libc’ is the result.

Technically, this move makes perfectly sense, too. We are sick of
supporting unstable glibc APIs and ABIs, and we believe that we greatly
benefit from the fact that we now finally have everything the OS
userspace consists of in one single repository.

Of course, this new libc is not available to Ubuntu and other Linux
distributions that have not yet adopted systemd. However, after
deliberately choosing a home-grown display server (Wayland) over the
generally accepted one (Mir) we decided creating an incompatible libc
would be the best approach to create a strong platform following a
strict release cadence.

The current code is fairly limited. We hope to have something workable
by systemd 205 or so, and will then slowly move systemd’s own code over,
external programs can follow. We target Fedora 22 as first distribution
to adopt our libc for all packages. Given the shortcomings of the
current glibc development process we expect no opposition from
FESCO. Also, we expect that our friends from ArchLinux will port their
distribution over by systemd 204 already. Debian and Gentoo are likely
to support this new libc in addition legacy eglibc in parallel for a few
more years.

This new libc will expose all kinds of Linux-only functionality, and
will depart from the limited POSIX APIs for that. This will probably
mean compatibility with glibc systems will be dropped within a couple of
releases.

To make this new library exciting to developers we added a couple of new
calls that fix long-standing problems in glibc. For example, first of
all we added strlcpy() as known from OpenBSD. We also renamed the API
call “creat()” to “create()”, as modern operating systems do not have
the strict limitation on system call name lengths the way UNIX System 7
had.

Anyway, that’s all for now. If you have questions, or want to help
getting this off the ground, please ping us on IRC.

Thanks,

Lennart

Footnotes:

[1] We can add a kernel later on, following the GNU/Hurd’s successful
approach.

--
 
Looks like their digging their hole deeper and deeper.
 
What the heck :OOO This is not an April Fools Joke?

I can't remember it now but didn't one of the creators of UNIX say something like that if he'd had to do it again he would rename creat() to create() ?
 
Judging by Poettering's animosity towards any OS that doesn't have a penguin mascot, I really can't tell whether this is an April 1st "joke" or something more serious.
 
I'm not sure how to respond to this. They got me... but only because it's now 2nd April, and the statement is perfectly in line with what they're doing in general? (minus the email client part, which I didn't pick up on while skimming it)

Well played. :)
 
We had the option of either merging glibc into
systemd, or write a new C library. Of course, we are pretty good at
rewriting existing programs
(we are simply faster doing that, since we
don’t have to read so much code), so we opted for the latter. The new
module ‘libc’ is the result.
+
For the sake of the archives, and since this apparently wasn't obvious
to everybody: this was our attempt to being funny on April 1st.

There is no truth in the original mail.


Lennart

Well, what does that equal? :beer

So, even better trolled than I suspected, it seems that there IS truth in the original.
 
Back
Top