Note that on 32-bit systems, btrfs will only work well until your inode numbers no longer fit in a 32-bit int, which unlike with other file systems can easily happen. stat() will return an error code, and critical things like the ELF loader will no longer work.

Yes, I've seen this happen.

Nope, sorry, not true. Parameter names never conflict with identifiers in any other scope.

They conflict with macros. Users are allowed to define macros before including standard library headers, and often do. I'm not familiar with GNU C coding standards, so you may have a point that __len should be _Len according to that, but as far as the C standard and POSIX care, either is fine.

Which would be fine, except that the glibc man pages don't say which functions are from which standard,

glibc doesn't include man pages, so firstly, your complaint isn't with glibc, and secondly, the ones on my system, as provided by man-pages, do. For example, from `man send`:

CONFORMING TO
4.4BSD, SVr4, POSIX.1-2001. These function calls appeared in 4.2BSD.
POSIX.1-2001 only describes the MSG_OOB and MSG_EOR flags. The MSG_CONFIRM flag is a Linux extension.

If a function comes from 4BSD but was later adopted by POSIX and SUS, what do you define?

If you're writing in the POSIX subset of glibc, you define the POSIX macro.

If you define the POSIX macro, then you may find that you've suddenly hidden a load of other things that were working correctly.

So you're not limiting yourself to POSIX anyway, and the problem isn't glibc's POSIX support, it's how to combine POSIX with glibc extensions.

There are some really fun cases where no combination of the public macros expose all of the features that you want and you need to define some of the glibc internal ones.

_GNU_SOURCE should make everything from glibc available. What are you using that isn't exposed by this macro?

Unfortunately for developers, Debian GNU/kFreeBSD uses GNU libc, rather than FreeBSD libc, so you get all of the fun of working with a libc written by someone who can't read the C standard (see unistd.h and its use of reserved identifiers for inline function parameters)

Well duh! Of course libc uses reserved identifiers for those. If it used non-reserved identifiers, it would conflict with valid user code.

and requires a huge mess of -D flags to compile POSIX / SUS code.

It requires one or more of the macros that, according to POSIX / SUS, the code needs to define. If the code (for convenience I'll include the build system in "code") doesn't define those macros, but does make use of POSIX functions, that's already a bug in the code.

Personally however, I think any judge would see through that and realize that the electronic ability to distribute only the modified part of a work doesn't change the intent to distribute a modified work itself.

If I publish an unauthorised errata for a paper book, would you expect me to get convicted of copyright infringement?

BTW, does the C standard demand that all integer types use the same representation?

The C standard almost requires that the corresponding signed and unsigned types have the same representation for non-negative values within the signed type's range, so you probably won't see a little-endian signed int and a big-endian unsigned int even on specially created weird archs, but other than that, anything goes. ("Almost requires": it doesn't actually require it, but there are a few ways where the standard allows you to read a signed value using an unsigned type or vice versa, so if the representations differ, some sort of type tagging is needed.)

If not, one could imagine that e.g. char uses signed magnitude, short uses ones complement, and long uses twos complement.

As far as I know, that does not violate any of C's rules.

The C standard says a char is one byte, but does not say one byte is one octet. It allows for 16-bit bytes, which of course also means 16-bit chars. Speaking of weird archs, omething I'm experimenting with myself is enabling alignment checks on x86 (x86-64 only right now; x86-32 causes too many problems); a large number of packages have no problems whatsoever with it, and of those that do, most of it comes from "if x86 then don't bother with alignment" logic, which is easily disabled.

Technically, yes, the protocol of a URL is required, but that's because a URL is a form of an absolute URI, and absolute URIs are those that include the protocol. Relative URIs are perfectly valid. The protocol is required in an absolute URI. If it is omitted, it's a relative URI. This is not the browser making assumptions, this is how URIs are defined.

Really? How many different places do you routinely need access to?

If any license that the user agreed to says "for non-commercial use", then it really doesn't matter whether it's patented or copyrighted: you agreed not to use it for commercial use. What matters is whether that license agreement is valid, and in some coutries, even those in the EU, it is.

3) I am pretty sure it is non valid, in europe, to impose a contract/EULA in an item which is only viewable AFTER the sale.

That's true in the Netherlands. However, the EULA does not need to be actually presented prior to the sale. As long as the buyer is notified of the fact that there is an EULA beforehand, has some possibility to view it, and agrees to the EULA (even by clicking "I Agree" during installation) after the sale, the EULA constitutes a contract.

For example, my Windows 7 box mentions (translated) "You must agree to the enclosed license terms before you can use this software. If you wish to read the license terms, visit www.microsoft.com/useterms. For use on a single computer or device." This sounds like it satisfies the criteria.

According to the same article, though, if I manage to install Windows 7 without breaking any laws and without clicking "I Agree", then the EULA does not apply to me, and Dutch copyright law allows me to use Windows anyway.

Where did you see "first one"? "Most complete" doesn't mean it's the first, it means it's more complete than the other browsers. (Whether that's true, I have no idea.)

Also, and I may be wrong here to please correct me if I am, I was under the impression that some video/audio content delivered via the new HTML5 facilities would be presented without the need for any scripting support?

You're correct, but NoScript doesn't block only scripts. It includes the option to block <video> content, and some other non-scripted annoyances.

The conventions never applied to signatories who were fighting adversaries that refused to follow them.

[citation needed]

I don't know if you're right, but I'm not going to just take your word for it, and it's not something that's easy to look up myself.

From your link:

7 Can any applications use the license?

The license is available for applications on any platform, except for applications that compete directly with the five Office applications that currently have the new UI (Microsoft Word, Excel, PowerPoint, Outlook, and Access). We wanted to make the IP available broadly to partners because it has benefits to Microsoft and the Office Ecosystem. At the same time, we wanted to preserve the uniqueness of the Office UI for the core Office productivity applications.

Firefox does not compete with Word, Excel, PowerPoint, Outlook or Access. Microsoft might claim Thunderbird competes with Outlook, if the Mozilla folks want to add ribbons there as well, but unless the actual license text is substantially different, there should not be any problem for Firefox other than possibly users' objections.