All what come with gedit only? The KDE-based distributions probably don't come with gedit only.

You might not, but the user base as a whole might want it. At least some of the major desktop environments have their own text editors (Kate for KDE, gedit for GNOME), and may be set up so that's what you have by default; having extra ones doesn't cost much in terms of disk space (if it costs a lot in terms of brain stress at having to deal with having a choice, Linux probably really isn't for you - but, then, given both Notepad and Wordpad, Windows might not be for you, either).

The answer to the third question is "because there's hardware lockdown", i.e. Apple have chosen not to offer OS X for non-Apple machines and have chosen not to use AMD CPUs in their machines and, therefore, as they didn't need to support AMD CPUs in XNU, have chosen not to bother supporting them.

The answer to the first and second questions is "because, for whatever reason, Apple isn't interested in offering them" (combined with "because there's hardware lockdown", so you can't have machines like that from anybody else running OS X unless you make the machine a Hackintosh).

If that was deliberate, it gets the "funny post of the day" award.

If it was accidental, it gets the "funny typo of the day" award.

A knockoff that's competing with a family of OSes that aren't 100% compatible with each other at the source level, that run on machines that are typically more expensive than the primary class of machines on which the knockoffs run and that don't even have the same instruction sets as each other (so that binary compatibility is out of the question), and on which a lot of the software is either open-source or written in-house so that it can be compiled and run on the knockoff, could succeed.

A knockoff that's competing with a single OS that has a ~90% market share and that has a huge collection of binary-only packaged applications that might depend (explicitly or implicitly) not only on documented behavior but also on undocumented behavior is a different story.

Well, there's the Darling project. I get the impression it's very much a work in progress, however.

They sell diesels here in California now, with the availability of low-sulfur diesel fuel.

As others have noted, that reverses the timeline; he became a billionaire before he became a mayor.

One of the earliest networks allowing collisions and using collision detection was the ALOHA network, and that was wireless, but that also wasn't Ethernet. Are you thinking of ALOHAnet?

I can't find a copy of Metcalfe's "Alto Ethernet" memo, but this Wired article has a diagram from the memo that does include "radio ether" but also includes "cable ether" and "telephone ether".

I.e., in S/370, invalid signs in decimal numbers suppressed, rather than terminating, the operation? (A change not unique to ZAP.)

"Dependent on features from a specific kernel" as in "doesn't work with 2.6.22, works with 2.6.23, doesn't work with 2.6.24", or "dependent on features from a specific kernel" as in "doesn't work with 2.6.22, works with 2.6.23 and later"?

The former either means they introduced a feature in 2.6.23 and yanked it in 2.6.24 or that it's dependent on implementation details from a specific kernel. The first of those might be done less in Windows, but that's a question of whether the OS's developers treat "preserving compatibility" as being more important than "not leaving cruft around". The second of those can show up in applications for any OS if the developer isn't careful.

The latter means "gee, they introduced a new feature in 2.6.23, which my program uses"; that happens in Windows, too - try unconditionally using an API or an API feature introduced in Windows Vista and then see whether your program runs on XP. One trick to handle that, at least in the case of a routine being introduced in a newer version of Windows, is to do a LoadLibrary() on the library containing the API and GetProcAddress() to try to get the address of that routine; if it fails, disable the feature requiring that routine or work around its absence in the code. That same trick can be done on UN*Xes, including Linux; replace LoadLibrary() with dlopen() and GetProcAddress() with dlsym().

"Windows does this to some degree but by shippping a runtime its possible to translate the instructions of the application in question to an older or newer kernel." sounds more like changing the system call interface to the kernel and changing the routines that use it to match. That's not restricted to Windows; one goal of the SVR4 shared library mechanism (which is what Linux's shared library mechanism is based on) was to allow that to be done transparently to compiled applications, by having applications dynamically linked with system libraries, so that an application binary gets the appropriate version of the library for the kernel version. OS X's shared library mechanism works the same, and Apple doesn't even support statically linking with its libraries.

pkg-config is part of the installation process for libfoobar-devel packages. It's not part of the installation process for libfoobar packages; you may need the .pc files for a library if you're developing code that uses it, but you don't need them if you're running prebuilt binaries that use it.

As do 100% of Linux applications, *BSD applications, Solaris applications, HP-UX applications, AIX applications, OS X applications, etc., because accessing files such as shared library files on those OSes involves the kernel.

However, at least as I read the Windows Internals books, the actual loading of dlls other than ntdll.dll is done in user mode by LdrInitializeThunk.

On most current UN*Xes, the process of launching an executable image, except for 100% statically-linked images, involves the execution of the run-time linker, with the executable image itself handed to the run-time linker as a parameter in some fashion (e.g., being opened as a file, with a file descriptor for it being available to the run-time linker); the run-time linker, running in user mode, loads the shared libraries. (See the PT_INTERP program header element in ELF or the LC_LOAD_DYLINKER load command in Mach-O; those specify the image file to use as the run-time linker.)

It might be easier to use a different mechanism for loading dynamically-linked libraries on Linux (or other UN*Xes) than on Windows, but it still takes work.

Are the Linux apps that don't use the standard Linux mechanism (ld.so) 100% statically-linked images, or what?

(Actually, it's a shell builtin, not a program; it has to be, as a child process can't change the parent process's current working directory.)

It's called "chdir" in V6 UNIX, which is what that script was from. See the SH(I) man page in section 1 of the V6 manual.

Beats me. Why don't you ask this guy?

Well, you're not likely to have multiple versions of the C runtime installed, because, in most if not all UN*Xes, the C runtime is part of the equivalent of kernel32.dll (libc.so, libSystem.dylib, or whatever it's called).

But, yes, you can have multiple "major" versions of libraries present. The SVR4 shared library mechanism, upon which the Linux and *BSD shared library mechanism are based, and the SunOS 4.x shared library mechanism upon which the SVR4 mechanism is based, gives libraries "major" version numbers, which change when the library ABI changes in a binary-incompatible fashion, and "minor" version numbers, which change when the library ABI changes in a way that preserves binary compatibility with older library versions but might add features (routines, flags to routines, etc.) that, if used, won't work with those older versions.

However, if your application uses libfoo version 2, but it's linked with a library that uses libfoo version 1, that's a problem. (Replace "a library" with "libpcap", and replace "libfoo" with "libnl", and you have one of the problems that makes me want to have libpcap on Linux talk directly to netlink sockets without the "help" of libnl, but I digress....)

If libfoo is done correctly, any program linked with version 1.0.0 should Just Work with version 1.0.1239, and Program B should only upgrade to 1.0.1239 if there's a bug in 1.0.0 through 1.0.1238 that breaks Program B so it requires 1.0.1239 or later, and Program A should just require 1.x.x and not install 1.0.0 if 1.0.1239 is installed.

Yes, that's the question of the extent to which the real "specification" upon which clients depend on is the official specification or the full behavior of the implementation, and the extent to which you're willing to tell developers of code that doesn't fit the former specification but fits the latter specification to go pound sand if you "break" their code. Sometimes you end up not telling them to go pound sand, e.g. the "7090 compatibility mode" in the IBM 7094 (in which mode the index number field in instructions is interpreted not as an index register number but as a bitmask with bits corresponding to 3 of the index registers, with all the index registers specified by the bitmask being ORed together to generate the index) or the hacks in various OS X libraries in which the library detects that program XXX is using the library and falls back on the old buggy behavior (I think Raymond Chen's "The Old New Thing" has examples of similar hacks on Windows).