LWN: Comments on "The kernel and the C library as a single project"

The kernel and the C library as a single project

gvy — Sun, 02 Jan 2011 13:27:38 +0000

Did it really need attention?

Oh, but it does...

Trelane — Sun, 19 Dec 2010 16:22:19 +0000

Absolutely right. There are a large number of people in violation of the OEM licensing terms. Read the FAQ for yourself: Some highlights:

Q. My customer wants to purchase a "naked" PC from me and acquire the Windows license through a Volume Licensing agreement. Is this OK? A. No. Full Windows licenses are not available through any Microsoft Volume Licensing program, including academic volume licenses. The customer must first acquire a Windows operating system license via OEM software included with a new PC from an OEM or system builder, or via the retail channel.

Q. Can my customers transfer or sell their OEM software licenses? A. After an OEM software license has been installed on a PC, the license may not be installed on or transferred to another PC. However, the entire PC may be transferred to another end user along with the software license rights. When transferring the PC to the new end user, the software media, manuals (if applicable), and Certificate of Authenticity label must be included. It is also advisable to include the original purchase invoice or receipt. The original end user cannot keep any copies of the software.

Q. Can two or more users access and fully utilize OEM Windows operating systems concurrently on the same machine? A. No. The End User Software License Terms do not permit two or more users to concurrently use the full feature sets of Windows operating systems. However, the Windows End User Software License Terms do allow for a limited number of computers or other electronic devices to connect to the computer upon which the software is installed to utilize one or more of the following services: File Services, Print Services, Internet Information Services, and telephony services. The End User Software License Terms also permit limited concurrent use in connection with the Remote Assistance and NetMeeting technologies. Please refer to the applicable End User Software License Terms for detailed information regarding such limited concurrent uses.

Q. How does a company qualify to become a direct Microsoft OEM? It seems that the larger companies currently have an unfair advantage compared with smaller OEMs. A. Direct OEM licensees do receive a discount compared to buying through the System Builder channel, but that discount is based on the licensees commitment to receive ongoing bulk shipments versus purchasing at will. Other elements of the direct licensing agreement require significant initial investment from the OEM. Furthermore, legal and technical requirements are placed on direct OEMs to protect Microsoft intellectual property, and these requirements can add other costs to the production of a PC. The primary difference between the two programs cannot be gauged merely by looking at prices and software licenses. Each program is designed to meet the specific needs of the partner.

Q. Can a PC with an OEM Windows operating system have its motherboard upgraded and keep the same license? What if it was replaced because it was defective? A. Generally, an end user can upgrade or replace all of the hardware components on a computerexcept the motherboardand still retain the license for the original Microsoft OEM operating system software. If the motherboard is upgraded or replaced for reasons other than a defect, then a new computer has been created. Microsoft OEM operating system software cannot be transferred to the new computer, and the license of new operating system software is required. If the motherboard is replaced because it is defective, you do not need to acquire a new operating system license for the PC as long as the replacement motherboard is the same make/model or the same manufacturer's replacement/equivalent, as defined by the manufacturer's warranty. The reason for this licensing rule primarily relates to the End User Software License Terms and the support of the software covered by that End User Software License Terms. The End User Software License Terms is a set of usage rights granted to the end user by the PC manufacturer and relates only to rights for that software as installed on that particular PC. The system builder is required to support the software on the original PC. Understanding that end users, over time, upgrade their PCs with different components, Microsoft needed to have one base component "left standing" that would still define the original PC. Since the motherboard contains the CPU and is the "heart and soul" of the PC, when the motherboard is replaced (for reasons other than defect) a new PC is essentially created. The original system builder did not manufacture this new PC, and therefore cannot be expected to support it.

Q. Can I create my own recovery disks and sell these with the computer systems that I build? I have heard that direct OEMs can do this, so why can't I? A. No. System builders may not offer a recovery solution with removable media (e.g., a recovery CD) because it is prohibited by the terms of the Microsoft OEM System Builder License. A full version of the Windows operating system is provided on a hologram CD in the Microsoft System Builder pack for each end user, and the CD must be transferred to the end user at the time of distribution. The hologram CD acts as the recovery media. However, system builders can offer a hard disk recovery solution in addition to, but not as a replacement for, the hologram CD. Third-party software companies can also help system builders do this. Learn more about the legal, licensing, and technical requirements for this type of hard disk-based recovery solution. System builders are bound by the Microsoft OEM System Builder License, affixed to the side of the System Builder packs, which is different than the direct agreements utilized by direct OEMs. The licensing terms for system builders and large OEMs are different because they are designed to address the specific needs of each community. The right to create recovery media is limited to the OEMs with direct agreements; however, these OEMs are also bound by other contractual obligations. The OEM System Builder License is designed to make it easy for system builders to acquire and distribute genuine Microsoft software, and accordingly, its terms are different.

Q. Can I provide a computer system to my customer without an operating system (also referred to as a "naked PC")? A. Yes. There is nothing illegal about selling a computer system without an operating system. However, getting the operating system preinstalled is your customer's most cost-effective way to acquire a genuine Windows operating system license. A customer who subsequently wants to install a Microsoft Windows desktop operating system on that naked PC will need to acquire it through the retail (full packaged product) channel which is a more costly option. Full Windows operating systems are not available through any Microsoft Volume Licensing program, and an OEM operating system license cannot be transferred from an "old" PC to a new one.

Q. What are the different ways in which Microsoft OEM System Builder Windows desktop operating system licenses can be distributed? A. The current OEM System Builder License allows system builders to distribute Windows desktop operating system licenses in the following ways: 1. Preinstalled on a new PC. 2. Unopened OEM System Builder packs (1-, 3-, or 30-packs) can be distributed to other system builders by themselves. Note that they must remain unopened so the receiving system builder can accept and be bound by the break-the-seal license agreement that is affixed to the pack.

Additional information "For hobbyists":

OEM System Builder Software[...]Must be preinstalled on a PC and sold to another unrelated party.

(commonly misunderstood part bolded and partially italicized by me)

OEM System Builder Software[...]System builder that preinstalled the software must provide support for the software.

Q. I would like to build PCs for my company and use OEM System Builder software for the operating system. Can I do this? A. OEM System Builder software must be preinstalled and then resold to another party. If you are using the PC within your organization, this "resale" requirement will not be met. In addition, as a system builder preinstalling OEM System Builder software onto new PCs, this requires that you grant the end user license terms to the third party acquiring the PCs from you. If you are distributing the PCs within your organization, you cant grant the end user license terms to yourself.

Volume licensing FAQ is also highly recommended: http://www.microsoft.com/licensing/resources/faq.mspx

Oh, but it does...

Jan_Zerebecki — Sun, 19 Dec 2010 11:37:26 +0000

AFAIK Microsoft does not offer free support with normal OEM versions, I would guess they make money with all their support offers, that need work per support incident, i.e. not including things like Documentation. (I just looked it up that a support Question for Microsoft Windows 7 Professional N costs 72.)

Copy, right?

marcH — Mon, 06 Dec 2010 00:24:21 +0000

> Ha. And, of course, I'm wrong.

Err... you mean, you are right?

Every bullet point you quote is about reproducing the original work in one way or the other. That does not seem to stretch the meaning of "copy" a lot, or does it?

Obeying licenses

giraffedata — Sun, 05 Dec 2010 18:48:35 +0000

When you bundle you must obey _ALL_ relevant licenses.

A license isn't something you obey. It doesn't command you to do anything. Copyright law is something you have to obey.

When you bundle, you must meet the conditions of all relevant licenses (i.e. the licenses you use).

Pity Linux doesn't support virtual files or filesystem

nix — Sat, 04 Dec 2010 23:05:53 +0000

ld-linux.so.2 is never really paged out anyway. It's only a dozen pages long and all of it is in use by *something* nearly all the time.

The kernel and the C library as a single project

nix — Sat, 04 Dec 2010 19:38:01 +0000

Indeed Fedora just got hit with a mass rebuild due to just such a codegen bug in GCC's 4.5 branch (never released, but Fedora update periodically to tip-of-branch rather than using releases, so they were hit, and had to rebuild everything built with the buggy compiler).

The kernel and the C library as a single project

oak — Sat, 04 Dec 2010 00:24:44 +0000

And if it would be a real dynamic library (instead a kernel emulated one), intercepting file system calls would be much easier. Currently libc functions can internally do all kinds of interesting things, but with syscalls being in a separate library they could simply be cought with an LD_PRELOAD...

(And the other alternative for interception, ptrace(), changes signaling semantics and race-free interception of calls in threaded code with ptrace() needs architecture specific code.)

The kernel and the C library as a single project

Darkmere — Fri, 03 Dec 2010 21:07:06 +0000

A few Gentoo users got bit by that by trying out the gold linker. When you end up with a 64bit linker that dumps core when linking something major, like gcc, you have a somewhat usable but ultimately badly broken system.

So yeah, infrastructure upgrades like bash, glibc, gcc, binutils, python make us all _very very_ concerned. It may not be noticable at first, but if it causes bad code generation or breaks on non-trivial things, you end up with a nightmare to recover.

ABI backward-compatibility is the trick...

Spudd86 — Fri, 03 Dec 2010 19:50:24 +0000

I don't think anyone was talking about letting the kernel break libc<->kernel ABI, the talk was about making new API available sooner and having new implementations of the (old) ABI in the libc sooner. Statically linked stuff would still use the old KERNEL ABI, and it would still work, but dynamically linked stuff would use then new libc which would use new kernel ABI, hopefully offering improved performance in the process.

Basically API/ABI-wise nothing changes (at least not intentionally), except the speed at which new parts become useable.

ABI backward-compatibility is the trick...

Spudd86 — Fri, 03 Dec 2010 19:43:27 +0000

... not if they're linked against libc5 (OK that's slightly more than 10 years ago... but still, you can't run those binaries on a modern distro)

Also the kernel developers ARE aware of this.

The kernel and the C library as a single project

Spudd86 — Fri, 03 Dec 2010 19:34:22 +0000

Well that wasn't the suggestion, it the suggestion was basically make linuxgate.so into libc. (OR at least make libc work like linuxgate.so, probably making it relocatable, unlike linuxgate)

The kernel and the C library as a single project

job — Fri, 03 Dec 2010 09:47:49 +0000

Indeed.

Another thing that causes hair pulling but should be fairly straightforward is executable file format migrations. _Every_time_ that has caused problems.

;-)

Pity Linux doesn't support virtual files or filesystem

jzbiciak — Fri, 03 Dec 2010 05:09:58 +0000

Could it be built / linked to a kernel similarly to an initrd? The main thing you'd lose is the ability to page it out, I imagine...

"Mere aggregation" is there for a reason.

sfeam — Thu, 02 Dec 2010 18:52:05 +0000

It is possible to claim copyright on a compilation (== "collection"), yes. But I am not aware of any requirement to do so. If there is no additional license/copyright on the compilation as a whole, then redistribution is only limited by the terms of the individual items within the collection.

In fact you can only claim additional copyright on the collection if your preparation of the compiled materials involves sufficient additional work to constitute "an original work of authorship" in its own right. Just stuffing a bunch of existing packages on a disk would be unlikely to merit a new copyright as a compilation. Preparing a full linux distro's worth of packages selected and possibly modified for interoperability, together with meta-information, installation scripts, yadda, yadda, is clearly a different story.

"Mere aggregation" is there for a reason.

vonbrand — Thu, 02 Dec 2010 18:25:46 +0000

There must be a license (i.e., a permission to do something you normally aren't allowed to do) on the collection as such, else you can't redistribute it either... Red Hat (the collection) used to go under GPL, I suppose Fedora does the same (plus trademark restrictions). Ubuntu does restrict (via trademark) what derivative can (and can't) be called Ubuntu.

Does it have to be the C library?

nix — Thu, 02 Dec 2010 14:42:11 +0000

No. Internal glibc->glibc calls do not go via the PLT and are not subject to interposition, thus LD_PRELOAD has no effect on them. (This is a big speed boost.)

The kernel and the C library as a single project

nix — Thu, 02 Dec 2010 14:41:27 +0000

libpcap was also near-dead for a long, long time.

It's not a kiss of death, but it's not a magic bullet to make things instantly be well-maintained, either. :)

Pity Linux doesn't support virtual files or filesystem

nix — Thu, 02 Dec 2010 14:39:09 +0000

Yeah, that would work. Kinda weird to have your libc provided by the kernel but I don't see a fundamental problem with it... except that the machinery in the kernel to export things like the vdso to userspace would need a *lot* of retooling to be able to export things as big as a C library.

The kernel and the C library as a single project

i3839 — Thu, 02 Dec 2010 13:43:14 +0000

Agreed. It's a bloody bad idea.

More problems would be solved if the kernel would drop bad system calls before they are in widespread use, instead of the stupid "stable ABI forever, even new bad ABI" mindset. The sooner crap is removed, the better. Only once it's in widespread use it's bad to break the ABI. But that can only happen if you didn't remove the bad ABI early enough. I hope one day Linus gets a clue about this.

Oh, but it does...

tialaramex — Thu, 02 Dec 2010 12:08:42 +0000

It's not "charmingly naive" to believe that users know the difference between a can that says "Coke" and one that says "Pepsi".

And if that was the comparison we were actually discussing it might be relevant.

There is a difference between being stupid and choosing not to invest time and energy in something.

Indeed, and a great many computer users (which means many millions of Microsoft customers) choose not to invest time and energy into understanding how a computer works. Microsoft has no problem with this, but it does mean they need to ensure that when those users buy a "PC with Windows" they don't get "a PC that could run Windows, but right now it's booted into BeOS". Because Microsoft (not Be Inc, not the guy on Slashdot promoting BeOS) ends up with a lot of the support costs if that happens.

If it's "elitist" to believe that some people don't care about computers then I guess I'm an "elitist" by your definition, but I caution you that this is an unusual definition which is likely to cause you problems.

Oh, but it does...

cmccabe — Thu, 02 Dec 2010 03:42:48 +0000

> Despite everybody's best efforts, none of today's PC operating systems
> actually work properly on a brand new PC. In say, Fedora this can be
> painfully obvious as your brand new HP laptop runs X with VESA graphics or
> refuses to acknowledge the existence of its built-in touchpad. Sure
> there'll be an update that fixes it, but that's later, and you've got the
> new laptop now.

It's fine to offer a restore CD with the driver pre-loaded. However, Microsoft should also offer the ability to download a clean version of Windows from its website, if you input the correct product key.

Microsoft has spent a lot of effort tying product keys to specific configurations and models of computer. They created Windows Genuine Advantage and barred pirated copies of the OS from downloading most updates. Offering a copy of the original Windows CD would really not be challenging for them.

> You mention trademark law as a solution to the dual boot problem. This is
> charmingly naive - to sophisticates like us it's obvious if you're running
> OS/2 or Mac OS X, but to the average user it's all a muddle. My sister
> continues to be caught out by the need to buy different software for her
> "new computer" (a MacBook). Trademarks don't help because they're not
> aware of the trademarks, it's just more technical mumbo-jumbo.

It's not "charmingly naive" to believe that users know the difference between a can that says "Coke" and one that says "Pepsi". It's also not naive to believe that users can't tell the difference between a big Apple logo plastered on the startup screen, and on the desktop afterwards, and the same situation with a Windows logo.

Frankly, I find your comments to be elitist. Just because a person is not a computer professional, doesn't make him stupid. There is a difference between being stupid and choosing not to invest time and energy in something.

Oh, but it does...

tialaramex — Thu, 02 Dec 2010 01:51:51 +0000

The restore situation I can explain (the quality of the restore though, you should blame on your OEM).

Despite everybody's best efforts, none of today's PC operating systems actually work properly on a brand new PC. In say, Fedora this can be painfully obvious as your brand new HP laptop runs X with VESA graphics or refuses to acknowledge the existence of its built-in touchpad. Sure there'll be an update that fixes it, but that's later, and you've got the new laptop now.

In Windows this is hidden by pre-installing the necessary patches, new drivers, utilities etc. at the factory.

But if the user re-installs from a "clean" OS DVD they don't get any of that, and then end up with the experience familiar to bleeding edge Linux people. They will, of course, report this as a fault, which will cost someone a bunch of support money. Hence, there is no way to install a clean OS, because they know it won't work properly anyway.

You mention trademark law as a solution to the dual boot problem. This is charmingly naive - to sophisticates like us it's obvious if you're running OS/2 or Mac OS X, but to the average user it's all a muddle. My sister continues to be caught out by the need to buy different software for her "new computer" (a MacBook). Trademarks don't help because they're not aware of the trademarks, it's just more technical mumbo-jumbo.

"Mere aggregation" is there for a reason.

nybble41 — Thu, 02 Dec 2010 01:49:36 +0000

That's true of section 106 the original Copyright Act, but section 109 ("Limitations on exclusive rights") and the Doctrine of First Sale pretty much nullify the third point in the case of simple redistribution or public exhibition of existing copies--apart from sound recordings or software, which were (idiotically) excluded from the limitations in section 109(a) by 109(b).

"Mere aggregation" is there for a reason.

cmccabe — Thu, 02 Dec 2010 01:10:40 +0000

> Right. So we need to check if Android or Ubuntu are derived work of kernel
> and if the license of kernel cover the whole "work". First part is simple:
> of course Android and Ubuntu are derived works! They quite literally
> include millions of bytes of code from kernel! Second part is equally
> clear (if you ignore "mere aggregation" clause): you can only ever
> redistribute "any work based on the Program" if you'll distribute the
> whole compilation under GPL terms.

Android as a whole is, indeed, a derived work of the Linux kernel. But that doesn't mean that all of the component parts of Android are derived works of the Linux kernel. You can, and companies do, make changes to the BSD part of Android and ship them, without making the code publicly available.

Here is another example. If you're a book seller, you can put several books on the shelf-- even ones with the same subject-- that have different copyrights. You do not need to get permission from the authors to do so. Just putting two things side by side does not make one a derived work of the other.

And we haven't even talked about "fair use"-- the quantum physics of copyright law. What a confusing topic!

Oh, but it does...

cmccabe — Thu, 02 Dec 2010 00:57:20 +0000

> And Microsoft's position here even makes sense, even if it was in practice
> anti-competitive and therefore perhaps unacceptable.

OEMs continue to choke systems with shovelware. Microsoft doesn't give a hoot as long as they get their cut. In fact, Microsoft has made the situation considerably worse by refusing to give out Windows install discs along with new computers. It used to be that you could at least re-install a clean version of Windows to get rid of the adware and spyware. Now, all they give you is essentially a restore-from-ISO tool that has all the crap on it.

The restriction on dual-boot computers was never about helping users; it was always about killing the competition. Enforcing trademark law would have been enough to ensure that users didn't blame Windows for Linux's (or BeOS's) failings.

> More recently we've seen what happens when Microsoft's OEM negotiators let
> the OEMs bully them - that's what led to the Vista debacle

Bad project management led to the Vista debacle. If your new operating system can't run on the newest hardware that's coming off the production lines, maybe you ought to delay shipping it until it can.

Don't get me wrong-- there's a lot of things that Microsoft has done well (Xbox comes to mind). But Vista wasn't one of them.

Yes, they do use this tatic.

cmccabe — Thu, 02 Dec 2010 00:42:37 +0000

> We are not talking about uninstallation. We are talking about bundling.
> And yes, restrictions here are quite legal and at least Microsoft actually
> uses this tatic - and judges accept it.

As far as I know, the legality of those contracts between Microsoft and the OEMs was never tested in court. So you can't say "judges accept it," because they were never asked.

It would be incredibly self-destructive for any OEM to sue Microsoft over this matter, because Microsoft has the ability to make or break them by offering or witholding discounts on Windows. To put it another way, Microsoft is the sole supplier for an essential part-- the Windows license.

> It's the same as with book: if you buy two books from authors which hate
> each other and then you can use scissors and glue to create "private
> compilation" of their works - noone can prevent this. But if you want to
> publish such compilation you'll need permission from both authors.

That's a clear, obvious case of creating a derived work. It has nothing to do with bundling.

On a somewhat related note, I know that Microsoft claims (in their EULA) that you can't run certain versions of Windows inside a virtual machine. I'd really like to see the legality of that restriction tested in court.

If it's legal for them to enforce this restriction, then logically it should be legal for any program to do the same-- so we'd end up with a bunch of programs charging extra for the "prviliege" of using them inside a virtual machine.

Pity Linux doesn't support virtual files or filesystem

kmself — Wed, 01 Dec 2010 19:07:48 +0000

Oh wait, scratch that.

/proc, /sys, /lib-ld-linux.so.2, /usr/games/nethack ....

Actually, since /lib/ld-linux.so.2 is already a symlink, it'd be even easier.

ls -l /dev/std{in,out,err} f'rex.

The kernel and the C library as a single project

roblucid — Wed, 01 Dec 2010 17:53:56 +0000

Ooh may be Ingo could intergrate an http daemon into kernel.. oh hang on.. been dun already???

The kernel and the C library as a single project

busterb — Wed, 01 Dec 2010 16:45:35 +0000

I don't think libaio failing indicates a general problem with the approach. libpcap and libevent seem to be doing well.

The kernel and the C library as a single project

busterb — Wed, 01 Dec 2010 16:42:06 +0000

There are libraries that do this today. A couple of examples:

libpcap abstracts the OS-specific calls to setup and capture from a raw socket. It includes several variations on a theme for Linux specifically, ranging from select/read semantics to mapping a shared-memory ring buffer.

libevent abstracts OS-specific replacement syscalls for select/poll, using whatever is fastest for a particular OS.

libaio is similar, but for asynchronous IO

These libraries all present a stable ABI for apps to use, similar to libc. Having a library like this seems like the perfect incubator for new syscalls as well.

The kernel and the C library as a single project

nix — Wed, 01 Dec 2010 16:40:07 +0000

Paging Roland McGrath... (who also has about as much pull on the glibc side of things as it is possible to have... of course he's also very busy and probably doesn't have time for this.)

The kernel and the C library as a single project

nix — Wed, 01 Dec 2010 16:37:41 +0000

Yep! And the aio functions are maintained in a separate library (libaio), not in glibc. This has really helped libaio develop fast, oh, wait, no it hasn't: it languished unmaintained for years.

The kernel and the C library as a single project

butlerm — Wed, 01 Dec 2010 16:33:55 +0000

No one is proposing importing the C library into the kernel, but rather the kernel source tree. Big difference.

The kernel and the C library as a single project

nix — Wed, 01 Dec 2010 16:30:26 +0000

The worry here is not 'the ABI breaks'. The worry here is 'it compiled, but if you run it it is too buggy to run significant programs without crashing'. Anything from miscompilation to buggy toolchains to general build environment problems to installation problems to a buggy glibc can do this.

The reason why glibc works when distros package it is because they take a lot of care, because they run 'make check', and because they know from experience which longstanding test failures indicate real problems. 'make check' takes, oh, half an hour on a fast Nehalem. This is not something that would add only a small amount of time to a kernel build!

The kernel and the C library as a single project

nix — Wed, 01 Dec 2010 16:27:47 +0000

Uh, you can't make libc a kernel module. It is both a userspace program and contains a component (ld-linux.so.2, the dynamic loader) whose absolute filename is wired into every dynamically linked binary on the entire system.

I suppose you could perhaps have a scheme where the kernel reads a PT_INTERP of '/lib/ld-linux.so.2' and looks for /lib/lds/{kernel version}/ld-linux.so.2 first, but I suspect this would have trouble getting upstream, because one extra path lookup per exec() is quite a cost.

The kernel and the C library as a single project

deater — Wed, 01 Dec 2010 15:25:21 +0000

I guess when you're a kernel developer you think any userspace problem can be solved by importing it into the kernel. It makes me weep.

So far Ingo has proposed moving performance counter utilities and qemu into the kernel and now libc. I can't wait until the web-browser gets merged too, I hear everyone else is doing it.

The kernel and the C library as a single project

hmh — Wed, 01 Dec 2010 14:48:13 +0000

Hmm? The onus is, and has always been, with whomever is proposing the new interfaces.

The liaison might get some flak from whomever is proposing the new interfaces and being told to go back to the drawing board. But the liaison will be in a position of power in that case (as long as he is someone that is respected by Linus for his good taste in ABIs/syscalls).

The way these things have worked in LKML lately is that you either do _something_ productive when people decide to oppose your new syscall/ABI, even if it happens at the very last moment, or you are at a reasonable risk of all your effort being declared "not for mainline".

But yes, it HAS to be someone respected by both sides, or someone who is respected in LKML (he has to have power to reject bad interfaces since day one), and who has a large potential to become respected within the glibc community.

Does it have to be the C library?

marcH — Wed, 01 Dec 2010 14:14:52 +0000

Isn't LD_PRELOAD=liblinux.so able to sneak new code into glibc and solve this problem?

He meant GLibC function, not syscall...

paulj — Wed, 01 Dec 2010 14:14:22 +0000

It's not alien, it's solid engineering. Further, it takes attention to detail and work to maintain ABIs, which can be boring and unsexy - which is not what a lot of evening/weekend hackers are interested in. So likely most of this work is being done by commercial distros in response to customer demand.

Further, even for the API, there are ways to offer multiple versions of those. You can categorise your APIs in various, including with levels. Applications can then *choose* to explicitly depend on certain APIs or they can choose not to and use whatever the default API is - some applications will do that through laziness or ignorance.

All boring and hard engineering work, but it's what widely deployed (in space and, especially, time) systems tend to have to acquire.

LWN: Comments on "The kernel and the C library as a single project"

The kernel and the C library as a single project

Oh, but it does...

Oh, but it does...

Copy, right?

Obeying licenses

Pity Linux doesn't support virtual files or filesystem

The kernel and the C library as a single project

The kernel and the C library as a single project

The kernel and the C library as a single project

ABI backward-compatibility is the trick...

ABI backward-compatibility is the trick...

The kernel and the C library as a single project

The kernel and the C library as a single project

Pity Linux doesn't support virtual files or filesystem

"Mere aggregation" is there for a reason.

"Mere aggregation" is there for a reason.

Does it *have* to be the C library?

The kernel and the C library as a single project

Pity Linux doesn't support virtual files or filesystem

The kernel and the C library as a single project

Oh, but it does...

Oh, but it does...

Oh, but it does...

"Mere aggregation" is there for a reason.

"Mere aggregation" is there for a reason.

Oh, but it does...

Yes, they do use this tatic.

Pity Linux doesn't support virtual files or filesystem

The kernel and the C library as a single project

The kernel and the C library as a single project

The kernel and the C library as a single project

The kernel and the C library as a single project

The kernel and the C library as a single project

The kernel and the C library as a single project

The kernel and the C library as a single project

The kernel and the C library as a single project

The kernel and the C library as a single project

The kernel and the C library as a single project

Does it *have* to be the C library?

He meant GLibC function, not syscall...

Does it have to be the C library?

Does it have to be the C library?