because they can't just hard code that right into the chip and never let you see it
No, because we would see either the software interfacing with the hard-coded backdoor, or some undocumented hardware means of communication coming out from the chip, and we'd start asking questions.
So if I just embed my code into the processor itself, you won't bitch.
Thats just silly.
Embedding code in (readonly or flash) ROMs is actually preferred from Stallman's point of view, because it allows the hardware to work out-of-the-box when using free software to control that hardware. Binary firmware is problematic for free software operating systems, not because free software enthusiasts have some maniac obsession about not running binaries that they haven't compiled themselves, but because the copyright holders of the firmware binary blobs often attach very restrictive licensing conditions to them, making them very hard or impossible to redistribute.
Now name one that the UN left for the US to hop the bag on for over a decade instead of taking care of business
Then next time Russia or some other country you don't like "takes care of some business" without waiting for the U.N. don't act outraged. Principles can't be bent to one's convenience.
There are other countries that repeatedly defy the United Nations and the U.S. would never invade.
Which is not to say that Saddam Hussein was a nice guy and the U.S. are the empire of evil - I certainly am happier to live under the U.S.' influence rather than Russia's - but let's not paint conflicts of political interests with manicheism.
Except statically linked binaries. Those were linked at build time, but they don't invoke the linker when they are executed. Guess what I use musl for? Building static binaries.
But you're changing the goalpost now. What I said was troublesome was using musl (or anything else, if glibc-incompatible) as a replacement for glibc. Using it for selected static binaries that you build yourself is another thing.
Nope. Binaries I only need one or the other, not both. Libraries only when I need a musl version of a library.
That's because I was talking about replacing glibc with musl, and be able to run binaries, over which you have no control, written for any of the two libraries. Which is the only scenario that would makes final users happy, should glibc coexist with musl.
No. Only for shit software that doesn't have any kind of protocol.
Again, that's stuff that is out of our control. Engineers have to design their systems for the worst case, not for the best.
Wrong. ISO C specifies stdint.h, int64_t is a standard way to get a 64-bit signed integer, and uint64_t is standard for 64-bit unsigned integers. The fact that you don't know ISO C is illuminating.
Microsoft's stuff is compatible with ISO C90. uint64_t was unsigned __int64 in their world until very recently.
Never works in practice. If the prototype for a library function is the same, and the calling semantics is the same, then it can be relinked without recompilation whether it was statically (unless it was stripped) or dynamically linked, and if either has changed, the code needs to be reviewed, rewritten and recompiled in either case.
With versioned symbols (glibc) you haven't this problem. But if you add support for them in your library, then you add "bloat". So you have to decide whether you want to add "bloat", or to make your users unhappy.
I don't know what adding getline has to do with existing programs. If they are not already making use of getline, then even if they are recompiled, they will still not make use of getline, and will not require it's symbol for linking. The Austin group (POSIX) are careful to not break stuff when revising standards, though I'm sure you can still point to some breakage; in general they tend to revise things by adding new symbols, or assuming the greatest common behavior between implementations.
They added getline() to the standard, and doing so they broke all the software that, perfectly standard-compliant until then, used the getline() name for their own stuff. This is to say that imagining to resolve binary compatibility with standard compliance simply doesn't work. They're two different problems.
Autotools gives me, as a user, and have done so since the 90s: - cross compiling support;
Never works.
I've bootstrapped my entire 64-bit Linux installation from a 32-bit host using it. It has almost always worked for me, even for packages whose developer hadn't ever thought about the possibility of cross-compilation. I have no doubt that packages using autotools were the ones that gave me fewer problems.
However plain old Makefiles, I just set CC, CFLAGS, LD, LDFLAGS and LIBDIR and things just work (also CXX and CXFLAGS for C++).
Only for the simplest cases. When things get more complex, you'll have to handle the difference between the host C compiler (which can be used to compile stuff which will run on the build host, such as code generators) and the target C compiler (which can only be used to produce binaries that won't run on the build host).
- ability to change any installation path;
I can do that with "PREFIX=/foo/bar make install" with any well written makefile.
That's the difference, with autotools you are almost sure that you get those features out of the box, and they're standardized, with other systems you have to hope that the developers wrote their makefiles well, and I can tell you that the current trend among developers is that they like less and less to invest time into packaging their source code. You also have to study the makefiles and see if it's DESTDIR or INSTALL_ROOT or ROOT_PREFIX or something else. Also, consider the difference between PREFIX and DESTDIR. The first can end up into paths stored in the generated code. The second won't.
- support for building shared and static libraries simultaneously using the best compiler options for each case; and probably something else that I'm forgetting.
make staticlibs; make dynamiclibs
Then you have to take into account the different flags required for building static vs shared libraries on every platform that you want to target (e.g. Linux supports non-PIC code in shared libraries on i386, other OSes don't, x86_64 never supports it...). With autotools you get that for free and out-of-the-box.
Fixing a broken homemade Makefile takes me a few minutes. Fixing a broken autobarf takes me hours to days.
Modern
Porting code to 9front is basically a rewrite as it's so alien, so let's put that to one side.
I don't think autotools work well, if at all, outside UNIXish systems. Even on Windows, they require impedance adaptation layers such as cygwin or mingw or interix.
Virtually all binary software is distributed in enormous tarballs containing their own libc, and every other library they use, and a bunch they don't simply because static linking doesn't work against glibc properly (and violates the license for non-free software).
Please don't spread false information this way.
Take Firefox for example, from Firefox.org, not the version shipped with your distro. Every Firefox tarball includes their own build of GTK, GDK, glibc, libnspr, etc.
Yes, let's take the version from firefox.org that I'm using right now.
$ ldd
linux-gate.so.1 (0xb77bb000)
libpthread.so.0 =>
libdl.so.2 =>
librt.so.1 =>
libstdc++.so.6 =>
libm.so.6 =>
libgcc_s.so.1 =>
libc.so.6 =>
See? It's using my libc, so what you said is completely incorrect. Shall we see if it uses its own GTK library as you've said?
I'll past the ldd result here: http://pastebin.com/UsP0MHUe , so you can see for yourself that firefox uses the system libraries instead.
Because dynamic linking is so horribly broken on Linux that is the only way it could possibly work on more than one distro.
Dynamic linking on Linux is state-of-the-art. If it doesn't work for you, look for responsibilities somewhere else than the operating system. If anything, it's static linking which is badly supported (by glibc, not by Linux).
SORRY.
...
Actually it is.
It's linked by any executable on your system and it has the role of loading every single dynamic binary that you have installed, including init. It's special.
I have both musl and glibc on my systems, and they have different filenames, so I can have both installed without conflicts.
Of course you can have both installed, but not without conflicts, you must be very careful to avoid the sea of conflicts that arise when you have two incompatible libraries with the same name.
Programs interoperate through IPC and the filesystem, so having programs built against different libc on the same system is not a problem.
You'll have to:
- duplicate every single binary and library to have libc and musl versions;
- ensure that the version of each binary is the same for its libc and musl image (otherwise IPC and filesystem communication will fail);
- ensure that the libc and musl versions of the binary are installed in two different paths and don't interfere (otherwise a libc program dlopening a musl plugin will fail), and rewrite all the software which uses hardcoded paths (e.g. Python);
- ensure that libc and musl types are binary-compatible (otherwise IPC and filesystem communication will fail);
- ensure that every package you compile finds the correct version of both libc and musl when you compile it;
- have your machine withstand the memory pressure of two different and unshareable userspace images running simultaneously (so much for fixing "bloat");
-
And musl and glibc are both source-code compatible in that they both implement a POSIX and ISO compatible libc.
Even Microsoft Visual C++ is ISO C compliant. So you can write programs that will compile on both GLIBC and Visual C++. As long as you don't use non-standard stuff such as 64-bit integers.
The only place where you would get source incompatibilities is in non-conformant programs that take advantage of defects or non-standard APIs of one of the libc, and the real solution here is to have developers fix their code so that it conforms to the standard.
If I am a user, I want my binaries to run and that's it. I don't have the option to ask whoever coded the programs that I use to rewrite them because I don't like their choice of API usage.
Furthermore, any library that is actually deployed and used will get bugs fixed, which can cause incompatible changes, and standards will be amended in ways that can break compatibility (for instance, the addition of getline() to the C library). What do you do then? Ask users to rewrite all the programs that they use every time such a thing happens?
the headaches around trying to get Gnu's arcane and defective build system to work
I've heard millions of times that autotools suck. That's true. The problem is that everybody else (and I mean scons, cmake, waf,
- cross compiling support;
- ability to change any installation path;
- ability to have a temporary installation path for packaging;
- ability to apply a transformation to program names;
- a standardized way to change any of the tools to be used during compilation;
- support for building shared and static libraries simultaneously using the best compiler options for each case;
and probably something else that I'm forgetting.
You get your binaries from distributions anyway
No, I get binaries from wherever I want and it works.
and with musl your closed source bits can just statically link safely libc and live happy and isolated.
I can't live happily without shared libraries. They were invented for good reasons tens of years ago and have been used extensively ever since. Think about the "bloat" of statically linked executables and the fact that they don't get updates of the linked-in library code (including security fixes).
If a subordinate asks you a pertinent question, look at him as if he had lost his senses. When he looks down, paraphrase the question back at him.