Insane Coding

When ALSA was imported into the mainline kernel, software mixing became possible without servers and they largely died out.

My experience was completely different. A few years ago, ALSA software mixing was not enabled by default and didn't work well when enabled. When not enabled, apps couldn't share the audio device at all. KDE created aRts to allow sharing at the app level, but aRts sucked, plus it hogged the audio device so non-aRts apps wouldn't work at all. Later aRts added a timeout after which it would release the device but this obviously wasn't a good solution. Gnome had ESD which I didn't use but it conflicted with aRts. JACK came along but was only ever used by high-end audio programs.

ALSA finally did get decent software mixing support, but now people are used to running sound servers. PulseAudio is the newest thing but last I heard a lot of people are still unsatisfied with it (e.g. http://jeffreystedfast.blogspot.com/2008/06/pulseaudio-solution-in-search-of.html ). Furthermore, people who know what they're talking about are recommending a move away from PulseAudio and ALSA and back toward OSS! Personally, I think the case is quite convincing: http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html

To my knowledge, the only filesystem which has poor performance when using fsync() is ext3 in data=ordered mode (which is not the default).

Not according to http://lwn.net/Articles/351422/

A few links gathered from a quick google search as a primer:

http://stevehanov.ca/blog/?id=97

https://www.evanjones.ca/portable-linux-binaries.html

https://insanecoding.blogspot.com/2012/07/creating-portable-linux-binaries.html

https://rpg.hamsterrepublic.com/ohrrpgce/Portable_GNU-Linux_binaries

https://github.com/wheybags/glibc_version_header

In other words: there are a lot of steps and a lot of gotchyas to doing this that you're glossing over. Linux userland libraries are generally designed with the intention that an army of third-party maintainers will integrate all of this desperately developed software together and place it in a repo. Naturally every distribution wants to do things a little differently too, and they have a habit of changing it up every couple years. When you try to step out of that mold, even just to static link, things unsurprisingly become more difficult. Whereas Windows, Mac, Android, etc. have been designed since the beginning not to require that sort of thing and it is consequently a much, much more straightforward process.

I'm curious why, since you seem to believe the process is so straight-forward, you think it is that so few people distribute a simple binary? Why were Flatpak and AppImage invented?

In the olden days the standard was the "Common File Dialog" [0], I think this existed on both Windows 2000 and XP. The CFD evolved over time.

Then Windows Vista came along and we were introduced to the "Common Item Dialog" [1] which is now the recommended way to File Open/Save.

> Acrobat has a sidebar with large icons of Recent Places, Desktop, Libraries, Computer, and Network.

Possibly your version of Acrobat is either older, or Adobe haven't bothered themselves to get with the present and implement the Common Item Dialog, or if they do they're customising it...or even worse it's a subclassed franken-dialogue. But I feel and appreciate your pain.

These two (fairly old) blog posts discuss the maddening situation with Windows file dialogues:

http://insanecoding.blogspot.co.uk/2007/03/file-dialogs.html

http://insanecoding.blogspot.co.uk/2007/04/file-dialogs-take-2.html

[0]: https://msdn.microsoft.com/en-us/library/windows/desktop/ms646960%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

[1]: https://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx

For watching movies or listening to music, the Linux audio system is fine, but ALSA and PulseAudio introduce unacceptable latency for game devs. For example the WINE developers are having major issues with PulseAudio's latency[1]

There are actually 2 low level audio stacks that apps can use in Linux, OSS and ALSA.
Only OSS offers great sound and low latency,[2] but the kernel developers have refused to add the free GPL'd OSSv4 updates into the kernel, so we are all stuck with OSSv3 legacy and ALSA's latency and poor design decisions. Using the PA layer only makes the latency situation worse and added another layer for things to go wrong.

[1]http://www.phoronix.com/scan.php?page=news_item&px=MTEyODM

[2]http://insanecoding.blogspot.hk/2009/06/state-of-sound-in-linux-not-so-sorry.html

Win32 actually gives you a way of getting lengths most of the time, like this example:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa364934(v=vs.85).aspx

... but the corresponding POSIX one doesn't:

http://pubs.opengroup.org/onlinepubs/009695399/functions/getcwd.html

http://insanecoding.blogspot.ca/2007/11/pathmax-simply-isnt.html