Slashdot Mirror

The files are in a git repository. That's what matters, not what you wrap around it to provide for requests.

So http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.4.tar.bz2 gets pulled dynamically from git?

No, but git contains the complete history in a local copy, so all that needs to be done is for Linus (or anyone else with a local copy ) to write a script that unpacks every tagged version and compares it with what's on the server. Because git is decentralized, everyone who works on the kernel has a complete copy of every version, so it's very easy to verify the other forms of distribution.

You manage to post a link to http://kernel.org/ (where the details of the breach have been described in the news section), and then another one to some third party site (thehackernews.com), where all they do is repost the exact same information?

The files are in a git repository. That's what matters, not what you wrap around it to provide for requests.

So http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.4.tar.bz2 gets pulled dynamically from git?

the kernel developers Who Matter

Are you saying users don't?

"[I]t is unlikely to have affected the source code repositories, due to the nature of git" [emphasis added] Yeah, because no one has ever downloaded the kernel any other way than by making a local fork of the git repository. No one has ever used the http, ftp and rsync links on the kernel.org website, or clicked the "Latest Stable Kernel" icon on that very website, right? Also remember that the mirrors don't mirror the git repositories but the http/ftp archives from kernel.org servers, the very same servers that has been compromised. The kernel.org home page encourages visitors to use those mirrors so it is not unreasonable to assume that some people do in fact use them. How many of them could have downloaded a compromised kernel? How many of them could be using it as we speak? Seriously people, this is big. I really mean totally freaking big. Thanks to the open source nature of the kernel it is trivial to add a rootkit and make a new tarball. If the attackers were worth their salt then they should do exactly that.

Actually mounting an iso image in linux is basically mounting the image like a drive with the loopback device as placeholder for ioctls.

Mounting something is in the end a system call and by my definition part of the kernel and the core of the core of utilities.
(mount command comes in a util package from ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/)

That means, that mounting an image is totally independent from any linux distribution and couldn't be less third party than io.sys from dos and its modern counterpart from windows.

However clicking on a file in an ui can be considered third party/part of distribution ^^

FTP is not dead. Still useful for anonymous dowloading like for the latest Linux kernels. Don't recall ever seeing an anonymous SCP transfer method.

https://github.com/MostAwesomeDude
https://www.ohloh.net/accounts/MostAwesomeDude
http://cgit.freedesktop.org/~csimpson/
http://git.kernel.org/?p=linux/kernel/git/csimpson/linux-2.6.git;a=summary

Your turn. Put up or shut up. >:3

The irony is that the first version of android contains gplv3 software : https://android.git.kernel.org/?p=platform/external/dosfstools.git;a=summary .

But it was quickly replaced by a bsd clone : fsck_msdos.git

I don't know if there are any product with the gplv3 fsck. May be some cupcake versions.

They are not the only one. ETWS (Earthquake and Tsunami Warning System) was added in Android in 2.3.5 (Gingerbread)

As well, SIGFPE is non-portable for divide-by-zero handling, since ISO C does not guarantee it to be raised at all. Here's what the ISO spec says pertaining to SIGFPE:

An implementation need not generate any of these signals, except as a result of explicit calls to the raise function. ... The complete set of signals, their semantics, and their default handling is implementation-defined;

and man signal in Linux:

Integer division by zero has undefined result. On some architectures it will generate a SIGFPE signal.

Sure, but for this you'll have to pardon me as we dig deep. Let's look at the arm branch within the kernel:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm;h=d247ffd8707069e63d0b065f5be9ce460e062536;hb=HEAD

See each of those mach-* and plat-* directories? Each of those are major architectural variants which use the ARM Instruction Set Architecture for their CPU.

For comparison, here's the X86 arch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/x86;h=b12a856aa5e889280247287d48241beb16eb423c;hb=HEAD

But, to see where the problem really lies let's dig deeper. Let's select a popular architecture, the Texas Instruments OMAP2, also shared by the OMAP3 and OMAP4 series.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm;h=d247ffd8707069e63d0b065f5be9ce460e062536;hb=HEAD

See all of those board-* files? Each of those represents a specific implementation of the OMAP2+ architecture. The rest of the files are support for the underlying functionality exposed by these board files.

You see, this is a mess. The current state is akin to having each variant of X86 with its own file. E.g. an architecture directory for each PC manufacturer (IBM, Dell, HP, Compaq, Lenovo, etc) and then in each directory the variant implementation files (Lenovo X40, X41, T40, T60, T60p; Compaq Presario CQ50, CQ56, CQ62 and so on). Whenever you change an underlying subsystem used by many boards, such as USB or Flash, you have to visit each of these architectures and boards and update them.

The reason for the mess in ARM is that ARM is the CPU core, an ISA, that's all. Beyond that it is completely nonstandard. Memory locations, flash interfaces, Serial Peripheral Interface (SPI), Two-Wire Interfaces (I2C), USB controllers and numerous other hardware configurations are all chip specific. The PC has standardized these using the BIOS, EFI, PCI and other industry wide standards. Sure you'll need drivers to use the devices, but at least you can boot up and detect them. From there it is simply a matter of loading the module and away you go.

The lack of standards in ARM necessitates these board files. One system may boot using one board file, but the next may not be able to get their RAM configured appropriately using the same board file.

And with regards to a consistent ISA, that's not even true. There are multiple implementations of some functionality such as floating point. ARM has a couple implementations (notably Vector Floating Point (VFP) and NEON), but some manufacturers have decided to create their own implementations such as Cirrus' Maverick Crunch. But this isn't even a real concern here, as that is more a matter for the compiler.

Sure, but for this you'll have to pardon me as we dig deep. Let's look at the arm branch within the kernel:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm;h=d247ffd8707069e63d0b065f5be9ce460e062536;hb=HEAD

See each of those mach-* and plat-* directories? Each of those are major architectural variants which use the ARM Instruction Set Architecture for their CPU.

For comparison, here's the X86 arch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/x86;h=b12a856aa5e889280247287d48241beb16eb423c;hb=HEAD

But, to see where the problem really lies let's dig deeper. Let's select a popular architecture, the Texas Instruments OMAP2, also shared by the OMAP3 and OMAP4 series.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm;h=d247ffd8707069e63d0b065f5be9ce460e062536;hb=HEAD

See all of those board-* files? Each of those represents a specific implementation of the OMAP2+ architecture. The rest of the files are support for the underlying functionality exposed by these board files.

You see, this is a mess. The current state is akin to having each variant of X86 with its own file. E.g. an architecture directory for each PC manufacturer (IBM, Dell, HP, Compaq, Lenovo, etc) and then in each directory the variant implementation files (Lenovo X40, X41, T40, T60, T60p; Compaq Presario CQ50, CQ56, CQ62 and so on). Whenever you change an underlying subsystem used by many boards, such as USB or Flash, you have to visit each of these architectures and boards and update them.

The reason for the mess in ARM is that ARM is the CPU core, an ISA, that's all. Beyond that it is completely nonstandard. Memory locations, flash interfaces, Serial Peripheral Interface (SPI), Two-Wire Interfaces (I2C), USB controllers and numerous other hardware configurations are all chip specific. The PC has standardized these using the BIOS, EFI, PCI and other industry wide standards. Sure you'll need drivers to use the devices, but at least you can boot up and detect them. From there it is simply a matter of loading the module and away you go.

The lack of standards in ARM necessitates these board files. One system may boot using one board file, but the next may not be able to get their RAM configured appropriately using the same board file.

And with regards to a consistent ISA, that's not even true. There are multiple implementations of some functionality such as floating point. ARM has a couple implementations (notably Vector Floating Point (VFP) and NEON), but some manufacturers have decided to create their own implementations such as Cirrus' Maverick Crunch. But this isn't even a real concern here, as that is more a matter for the compiler.

Sure, but for this you'll have to pardon me as we dig deep. Let's look at the arm branch within the kernel:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm;h=d247ffd8707069e63d0b065f5be9ce460e062536;hb=HEAD

See each of those mach-* and plat-* directories? Each of those are major architectural variants which use the ARM Instruction Set Architecture for their CPU.

For comparison, here's the X86 arch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/x86;h=b12a856aa5e889280247287d48241beb16eb423c;hb=HEAD

But, to see where the problem really lies let's dig deeper. Let's select a popular architecture, the Texas Instruments OMAP2, also shared by the OMAP3 and OMAP4 series.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm;h=d247ffd8707069e63d0b065f5be9ce460e062536;hb=HEAD

See all of those board-* files? Each of those represents a specific implementation of the OMAP2+ architecture. The rest of the files are support for the underlying functionality exposed by these board files.

You see, this is a mess. The current state is akin to having each variant of X86 with its own file. E.g. an architecture directory for each PC manufacturer (IBM, Dell, HP, Compaq, Lenovo, etc) and then in each directory the variant implementation files (Lenovo X40, X41, T40, T60, T60p; Compaq Presario CQ50, CQ56, CQ62 and so on). Whenever you change an underlying subsystem used by many boards, such as USB or Flash, you have to visit each of these architectures and boards and update them.

The reason for the mess in ARM is that ARM is the CPU core, an ISA, that's all. Beyond that it is completely nonstandard. Memory locations, flash interfaces, Serial Peripheral Interface (SPI), Two-Wire Interfaces (I2C), USB controllers and numerous other hardware configurations are all chip specific. The PC has standardized these using the BIOS, EFI, PCI and other industry wide standards. Sure you'll need drivers to use the devices, but at least you can boot up and detect them. From there it is simply a matter of loading the module and away you go.

The lack of standards in ARM necessitates these board files. One system may boot using one board file, but the next may not be able to get their RAM configured appropriately using the same board file.

And with regards to a consistent ISA, that's not even true. There are multiple implementations of some functionality such as floating point. ARM has a couple implementations (notably Vector Floating Point (VFP) and NEON), but some manufacturers have decided to create their own implementations such as Cirrus' Maverick Crunch. But this isn't even a real concern here, as that is more a matter for the compiler.

Time to call out an ARM manufacturer.

We recently got a Freescale i.mx53 Quickstart Board. Nice piece of kit they just released. Seems good for many of the applications we're thinking of.

Problem: It ships with 2.6.35, more than a year old. With 505 patches. And proprietary graphics.

We really want the 3.0 kernel, because it's supported by the -rt patches.

Freescale, Freescale, Freescale! PLEASE make more of an effort to mainline your changes! And use a graphics core that has drivers that can be recompiled, even if it's the NVIDIA model.

If the target for a long-term stable kernel is embedded systems, then I would suggest having some sort of arrangement with the real-time kernel patches which typically don't release with every kernel.

If, for example, 2.6.39 was chosen as a -longterm, it's unattractive for many embedded developers without the option of the -rt.

That would be an interesting and a not too hard a project, I am assuming. So this in turn would imply that there would already be an option in the kernel to do it right? So why not improve the performance of gaming or computation systems by recompiling the kernel to do this?

I suspect they are using some form of real-time extensions to the linux kernel. One thing they all share in common is little to no OS functionality is available to applications that are running real-time because, it is almost always the case that as soon as you ask the kernel to do something for you, all bets are off as to when it will get done or even when you will get scheduled back on to your cpu.

So, in order for a game to take advantage it would need to isolate out whatever parts of the code are performance and dead-line critical so they wouldn't need to interact with the OS. And then the user would have to install and boot a linux kernel with the real-time stuff turned out.

Also, FWIW, real-time is not about speeding up computation, it is about hitting your deadlines exactly when they need to be hit - not too soon, not too late. In many cases you trade off computational performance in exchange for the ability to meet those deadlines.

I wouldn't call failing to distribute the source a "tiny mistake".

http://android.git.kernel.org/

Looks distributed enough to me.

And I know that's only the kernel -- but that's all that matters. The userspace stuff isn't "derived" and thus doesn't have to be licensed under the GPL.

And I also know that the above is a Google-provided site, not one provided by the handset manufacturer. But that doesn't matter either as long as the handset manufacturer doesn't himself modify the GPLed parts of Android (i.e. the kernel) and then fails to distribute the source for that. As long as the handset manufacturer just distributes the Android kernel as-is, the source code is available under the above link, and that's it.

There actually are relatively few closed pieces necessary to make something like Nexus S go. For the most part they're firmware, not actual "drivers", though the opengl libraries fall into a middle ground -- the SGX kernel driver is GPLv2, the userspace opengl libraries are closed. We've been working with vendors to make the closed pieces available under a license that allows them to be included in builds and distributed non-commercially (commercial distributors tend to be OEMs which have direct relationships and licenses with these vendors already):
http://code.google.com/android/nexus/drivers.html

I'd use the term "proprietary components" rather than "drivers" (the above URL is unfortunately named), personally, since at least for lead devices that Google works on, all the kernel drivers are GPLv2 and readily available:
http://android.git.kernel.org/?p=kernel/common.git;a=shortlog;h=refs/heads/android-3.0
(kernel/common is code common to all variants, SoC-specific work is under kernel/omap, kernel/msm, etc)

Google hasn't released what they've considered "official" sources for Honeycomb, but lots of the code shipping on tablets, etc is out there.

http://support.asus.com/Download.aspx?SLanguage=en&m=Eee+Pad+Transformer+TF101&p=20&s=16

Here's the Honeycomb branch of the Xoom kernel: http://android.git.kernel.org/?p=kernel/tegra.git;a=shortlog;h=refs/heads/android-tegra-2.6.36-honeycomb-mr1

and so on. Yea, it's not open source in the bazaar-style development model, but Google puts the sources out in reasonable timeframes.

You could do this yourself with a post-receive hook on your main repository and a new kind of ref. (For example, refs/revisions/3)

I didn't really understand the numbering scheme you tried to illustrate in your diagram, but assuming your numbering system is deterministic and can tolerate non-linear history you should be able to implement it.

You can configure what types of ref git will fetch when it retrieves new items from a remote, so you can expand the default wildcard including refs/tags/* and refs/heads/* to include refs/revisions/* too. Then when someone tells you "check out revision 3" you can just say "git show refs/revisions/3".

Of course, you would eventually end up with lots of files in refs/revisions which might degrade performance. Using some kind of sub-directory hashing scheme would mitigate that.

As you've noted, that's because Git indexes things by their hash, not an arbitrary name. While it works in Git's favour in this case, that doesn't mean all other VCSes have to be like it. Why is it a "design flaw in bzr" that it doesn't index things by hash? The only advantage of this is that it would interoperate with Git. Now on the one hand, you're telling me "why should Git be changed to support Bazaar" (to which I said: it doesn't have to support Bazaar, it just has to support a single generic feature), and on the other hand, you're telling me "Bazaar should be changed for the sole specific purpose of supporting Git."

Also, you're wrong about git-svn (as far as I can tell). From my reading of this manpage, it does store metadata in the commit log ("git-svn-id"), which it needs in order to rebuild the Git data structure (which is richer than Subversion's, since it can have merges). There is a --no-metadata option but it "can only be used for one-shot imports as git svn will not be able to fetch again without metadata". It sounds as if Git does rely on metadata in the foreign VCS! (In this case, it is crudely shoved in the commit log, which is something that bzr-git does too.)

The fact is that all VCSes have slight (or major) differences in their data, and properly interoperating requires "polluting the dataset of the original". It's just a question of whether the original has metadata (so the additional data can be stored away where nobody has to see it unless they really want to), or if it's necessary to crudely shove that data into the commit log, like git-svn does.

Would this do it?: http://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_sparse_checkout

Commit messages are metadata and you can put whatever you want in there. But if you are looking for something more structured: git notes. Probably the most important metadata that git saves though are merge commits. It is extremely useful to know the development history of a merged branch.

Most of the other things you list are merely different design decisions.

git-tag

All assets are in RCS as there are many code changes tied to art assets, they need to be in sync.

Perhaps git's submodule feature would be of service here. From the man page: 'Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit.'

The last shipped game that I worked on had a minimum sync size of ~43GB. That did not include movies, design documents, style guides or multiple language support. That built the PC, XBox360 and PS3 SKUs. A full sync was well over 100GB which I never did as I didn't need that stuff.

I wonder whether something like bup (which is based on git) might be useful for managing the large datasets; given that bup stores data in git repos, you could probably even use it as the basis for a submodule (perhaps with the help of scripts to unload the data where desired).

However, I think the main point is that git is optimized for managing code history and that it's kind of silly to expect git or any other tool to handle both usage cases well. When it comes to managing code history alone, git probably provides better tools than what you espouse:

I want my multiple change lists and the ability to sync any file to any revision easily for testing. I want to be able to select someone else's change list and revert it locally without hassle. I just find that git gets in my way when I have shit to do and little time to do it.

You can do all of these things easily with git's `fetch', `log', `whatchanged', `diff', `merge', `show', `checkout', `reset', `stash', `revert', `rebase', etc.

If there's on thing you can do with git, it's slice and dice code and revision history in any which way you please. Frankly, I think you're frustrated because you don't know what you're talking about with regard to git; you've never bothered to learn what you assume is an inferior tool. In reality, the inferiority is your mindset.

Git does have commit metadata... and for awhile now... see git-notes... http://www.kernel.org/pub/software/scm/git/docs/git-notes.html http://progit.org/2010/08/25/notes.html

> because Git lacks commit metadata, it is impossible to meaningfully use any other revision control system in conjunction with Git -- what a selfish decision.

git-notes(1)

Linux lacks a standard DRM solution.

Then what's this? That sure looks like DRM.

But seriously: Netflix could just cook up its own digital restrictions management solution. Why hasn't it? Is it the fact that anybody can modify an X server to tee the raw pixels into a transcoding process?

They're currently on 3.0 RC4. So I imagine that what will and won't be in the release has pretty much solidified by this point.

http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.0-rc3.tar.bz2

Linux is copyrighted!!!

It seems like they have: http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git;a=blob;f=btrfsck.c;h=63e44d1dbc26f2ee9f6ef29c08ae0eb9d19e48db;hb=HEAD

If there is no fsck for btrfs then what is this?

http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git;a=blob;f=btrfsck.c;h=63e44d1dbc26f2ee9f6ef29c08ae0eb9d19e48db;hb=HEAD

So far, you need to stay at ext2/3 or xfs if you want defragmentation.

False. You obviously argue from ignorance, so I'd suggest you read up on how btrfs actually works. Look here for an example. Google will tell you even more.

It says right here on the btrfs wiki: "While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. This will be fixed when the fsck tool is ready. "

So I'd say yah, that's a pretty important piece to be missing if you're talking about making it the default for a distro, even one as free-wheeling as Fedor.

It seems like they haven't: https://btrfs.wiki.kernel.org/index.php/FAQ#When_will_Btrfs_have_a_fsck_like_tool

Hopefully they know something about it being released soon since making the decision to use it.

Until they make a public announcement to the contrary we have no reason to believe otherwise.

Depends on what you understand by hardware support... to me, it sounds very much like drivers

The 11.05 cycle will add hardware support for Samsung and Freescale in addition to the existing OMAP, ARM Versatile Express Platform and U8500 based boards.

and

Linaro is also working with its member chip companies to maximize upstream SoC support, i.e. to move most of the SoC specific drivers into the official sources on http://kernel.org/ .

Sounds like a public enough declaration of support for open-source drivers?

There's a release about every three months, which gives four releases per year. I would say about 4-5 years old. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=de46c33745f5e2ad594c72f2cf5f490861b16ce1 Oh hey, it's four years old after all.

I like his 3.0 commit message
"Version numbers? We can increment them!"

Thankfully, Linus hasn't rewritten the kernel in VB.

Also this version has codename "Sneaky Weasel"

--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
-VERSION = 2
-PATCHLEVEL = 6
-SUBLEVEL = 39
-EXTRAVERSION =
-NAME = Flesh-Eating Bats with Fangs
+VERSION = 3
+PATCHLEVEL = 0
+SUBLEVEL = 0
+EXTRAVERSION = -rc1
+NAME = Sneaky Weasel
 

Are they needing compatibility hacks to work with a kernel from April 1999? At some point, you should just give up on the three people still running that version.

To obtain all of the ext4 performance, tweaks, and reliability benefits, you MUST perform an ext4 format.

That's not entirely correct. With two commands, you get a full conversion from ext3 to ext4 without a reformat, leaving your data in place:
tune2fs -O extents,uninit_bg,dir_index /dev/DEV
e2fsck -fDC0 /dev/DEV

(On an unmounted filesystem, obviously. Source. )

A counterpart to /dev/random is /dev/urandom ("unlocked"/non-blocking random source[4]) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random. While it is still intended as a pseudorandom number generator suitable for most cryptographic purposes, it is not recommended for the generation of long-term cryptographic keys.

Source: http://en.wikipedia.org/wiki//dev/random#Linux

A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.

source: http://www.kernel.org/doc/man-pages/online/pages/man4/random.4.html

Android Webkit source Git repository? Some of the branches in that repo explicitly mention Honeycomb...

Good question. I'm not sure the OS support is really there - in particular, Windows XP apparently doesn't support writing to UDF filesystems at all, and older Linux kernels have problems mounting UDF volumes on hard drives or other similar non-optical devices. It's also a horrid mismash of different versions and optional features which various operating systems support different subsets of, thought that mostly affects optical drives.

I guess partly it's an accident of history - Windows didn't support UDF until relatively recently, well after MP3 players and digital cameras became widespread.

No, libhardware is just a part of Android. It's here, if you care. It is not a driver issue, or a Motorola specific issue. I'm talking about files that have been updated in Google's internal source code repository, that are on real phones right now, that have not been released as open source.

The earlier AC said "Real Android devices haven't been affected by the closure [, only tablets]" and the fact is yes, 'real' Android devices have been affected.

I realize this is probably an attempt at humor, but it's not funny and a lot people still seem to be confused about the issue. Linux is 20 years old, but GNU is 27 years old. There are complete operating systems based on GNU (and not Linux) as well as those based on Linux with very little or no GNU components. The term GNU/Linux only makes sense when one is talking about an operating system based on both of them, which is by far the most common way to use either one of them.

The Android user-space isn't GPL licensed but mostly licensed under ASL2.0. They don't have to make the source available on request. But people are allowed to distribute the binaries and to distribute the source if they have it. The Android Linux kernel is GPLv2 licensed and the source, including Honeycomb, is available at http://android.git.kernel.org/.

Because Android isn't GPL licensed, only the kernel is.

For the record, the kernel is available at android.git.kernel.org

Could some of you idiots who keep voting this guy "insightful" explain your reasoning? For fuck's sake, he quoted the COPYING file, so all you had to do was glance up and read and you could see his claim about it is wrong. It says nothing about the kernel header files.

You generally do not need to use the kernel header files in order to write or compile programs that make system calls. For example, to write a program that uses fork, you include sys/types.h and unistd.h.

The COPYING file IS for the kernel source, including (drum roll please) the kernel headers.

But let's cut to the chase. Bionic is generated from the kernel headers in the linux distribution. Here's what the article from h-online reported a few days ago when this all started

Nimmer looks at the process that the Android developers created to produce the header files for Bionic, a compact alternative to glibc which also includes Android specific functionality.

The build process for Bionic takes the GPL licensed kernel header files and, using a number of Python scripts, reprocesses them to create "clean" header files for Apache licensed Bionic

OR, you could read the the very first line of the Bionic README.txt, which also says that this uses kernel header files:

Bionic comes with a set of 'clean' Linux kernel headers that can safely be included by userland applications and libraries without fear of hideous conflicts. for more information why this is needed, see the "RATIONALE" section at the end of this document.

these clean headers are automatically generated by several scripts located in the 'bionic/kernel/tools' directory, which process a set of original and unmodified kernel headers in order to get rid of many annoying declarations and constructs that usually result in compilation failure.

the 'clean headers' only contain type and macro definitions, with the exception of a couple static inline functions used for performance reason (e.g. optimized CPU-specific byte-swapping routines)

they can be included from C++, or when compiling code in strict ANSI mode. they can be also included before or after any Bionic C library header.

So , who's the idiot - the people who modded this insightful, or you for calling them idiots?

But let's look further - the kernel source headers used, as per the README.txt file:

the generation process works as follows:

* 'bionic/kernel/original/'
contains a set of kernel headers as normally found in the 'include'
directory of a normal Linux kernel source tree. note that this should
only contain the files that are really needed by Android (use
'find_headers.py' to find these automatically).

* 'bionic/kernel/common'
contains the non-arch-specific clean headers and directories
(e.g. linux, asm-generic and mtd)

*'bionic/kernel/arch-arm/'
contains the ARM-specific directory tree of clean headers.

* 'bionic/kernel/arch-arm/asm'
contains the real ARM-specific headers

* 'bionic/kernel/arch-x86'
similarly contains all headers and symlinks to be used on x86

* 'bionic/kernel/tools' contains various Python and shell scripts used
to manage and re-generate the headers

Looks like you made a monkey of yourself :-)

NOTE! The linux unistd library-functions (the low-level interface to
linux: system calls etc) are excempt from the copyright - you may use
them as you wish, and using those in your binary files won't mean that
your files are automatically under the GNU copyleft. This concerns
/only/ the unistd-library and those (few) other library functions I have
written: most of the rest of the library has it's own copyrights (or is
public domain). See the library sources for details of those.

Kernel 0.01 was dated only a year earlier, so the vast majority of the code in question isn't in question (especially since the vast majority of the code has nothing to do with this issue :-)

The bionic source is extremely easy to find, I'm pretty sure they expected the reader to be able to do that.