I should probably have characterized that better.

1. Not all desktop PCs are gaming PCs and not all desktop users are gamers. (eg. My mother quite happily uses Lubuntu as her only OS.)

At the time, I was playing Dungeon Siege (a notable example of "beautiful but boring") and my main interests were just finishing a shift to anime, manga, prose fiction, and my programming hobby... all of which Linux was quite good at servicing even in 2004.

(Note: When that happened, I boxed up over 600 CD-ROMs and left it to my younger brothers to spend all the time they wanted on our couple dozen games apiece for N64 and PlayStation. I wasn't a casual gamer by any means before my interests shifted.)

At the same time, my Windows XP setup had become a buggy, unstable mess and, for some reason, it didn't occur to me to pirate my missing install media and reinstall it.

2. I've never used VSync, even when I had the option, because I'm too used to input response without it and it made the mouse feel sluggish on the hardware I ran Windows on.

3. Linux is getting close to fixing the problem that requires me to lock out resolution-changing from both directions. Modern Linux games default to "fullscreen windowed" mode and Wayland will resolve the "my WM doesn't realize the resolution change is temporary" problem by providing a proper "change the resolution until I quit" API and limiting permanent resolution changes to the system settings application.

As for the scroll wheel on Windows, it was merely intended to characterize something Windows users don't think about which "sucks" about Windows when viewed from the outside. Other examples which can only be fixed using 3rd-party software now include the lack of support for redefining a key to be Compose, lack of the "primary selection" (the mechanism which allows you to copy-paste by selecting some text and then middle-clicking where you want it), and Windows's inability to support Linux/MacOS-style "click-drag-release to select a context menu item" interaction.

I'll have to disagree on that. If anything, the average Windows user is less sensible because you have to switch to Linux rather than growing up on it and childish minds are more likely to be driven away by the effort involved in learning the vagarities of a new system.

Have you seen some of the "I'm taking my ball and going home!" tantrums that mod creators and the like have had in various Windows gamer forums?

(...and I can't count the number of times I've seen that kind of behaviour from non-Linux-using people on Fanfiction.net and deviantART.)

This is a textbook example of having such a small sample that you can't draw useful conclusions because you can't tell signal from noise.

I'll take this in several steps.

First, yum, apt, and pacman are system package managers. They're intended to handle the stuff which is not distro-agnostic and they've also been around for a while.

For example, APT and Yum were developed in 1998 and 1999, respectively, (Yum being a nicer frontend for the RPM format, which dates back to 1997) and were intended to supplant just unpacking archives full of files. The vast majority of Linux distros use either APT or RPM-based packaging, so that's a good example of non-fragmentation. (APT stands for Advanced Package Tool because it was state of the art when it was created.)

pacman (Arch Linux) and emerge (Gentoo Linux) exist in part because APT and RPM weren't designed to be well-suited to rolling-release distros with an "automatically build from source" option, so they have a rationale for not just using the big two choices.

Flatpak, originally known as xdg-app, was explicitly designed to complement traditional packaging by providing a cross-distro way to distribute, sandbox, and update desktop applications. By design, it CANNOT replace the system package manager for non-desktop components like the kernel and core components like the init system. (Similar to how you can't update your Android phone's OS by installing an APK.)

The "xdg" is a clue... it stands for "Cross-Desktop Group" (the original name for Freedesktop.org) and, like other XDG utilities and standards, was explicitly developed as a collaborative effort to design something everyone was willing to work toward using. (Other XDG-standardized things include icon themes, D-Bus as a replacement for DCOP (KDE) and CORBA (GNOME), and the modern standard for allowing applications to define and install launcher icons once for all possible desktops.)

Snaps, on the other hand, were invented by Canonical around the same time as xdg-app as part of their continuing pattern of reinventing other people's wheels (and never in a superior way) ...usually so they can try to gain an advantage by granting themselves special licensing exceptions. (See also Mir vs. Wayland, Upstart vs. systemd, and libappindicator vs. KStatusNotifierItem)

Flatpak's adoption is actually coming along very well. The main holdup is that it takes time for the various desktop environments to implement the various Flatpak Portals APIs, then those updates have to get released, then those releases have to get integrated into distro release cycles.

As for Kdenlive, I whole-heartedly agree that what they did with their site is both idiotic and insane and there's no excuse for it.

That said, I know I've seen some pretty stupid and crazy decisions by Windows freeware developers over the last couple of decades. (I've had Internet access since 1997).

No barrel-digging needed. It's linked from the Wikipedia Flatpak article.

I can't say I've had internet access since 97 but I did familiarize myself with most of the methods to install all the different types of software. Out of the Linux repos APT is my preferred though I still prefer the Windows exe system more.
Appimage has the most promise but it also has a few draw backs. It's a bit slow and from what I hear can't interface with the OS as well as APT apps can. So it might not be very good for gaming. I like APT because you can easily backup all the deb files. But unfortunately there are two main hurdles with that. A. it's best to back up from either a live or fresh install of your distro of choice and B. they change with every release. With Windows you can download the exes of your favorite programs and drivers and as long as you have them, they will work. Not so for Linux deb files.

Not personally no. On sites like DA but I'm not a heavy forum use tbh

You'll get drama all over the internet but in my experiences it happens the most with Linux users. Even when trying to be constructive. I've never seen such fan outrage since the bit wars.



In my opinion Linux needs to adopt a future proof method of software deployment that supports closed source as much as open source. Open source is great but it can not and will not be suited to everything. If I could download a program for a Linux distro weather it was through a browser or a distro that would continue to work well into the future with further releases. This would mean that your software and games will continue to run.

This doesn't even happen with Windows but Windows got closer then anything else. Microsoft really does do software backwards and forwards compatibly really well. Hardware compatibility is another story though.

Yeah, they do it so well that newer version of Windows is a hard requirement for newer version of DirectX. Such a good design they got there. A hint - it has nothing to do with technical needs. It's purely political, since MS like to shove their policies down users' throats to make people spend more money on their bloat. If you like that kind of treatment - MS is good for you.

Appimage has been around since 2004 (originally under the name "klik") without getting significant uptake and it isn't the only such effort. (See also Autopackage, Listaller, and Zero Install.)

Avoiding that trap was explicitly one of the goals when participants in Freedesktop.org started working together to design what is now called Flatpak.

As for "can't interface with the OS as well as APT apps can", that's actually a good thing. If you want your applications to last, you want to isolate them from the changing platform and limit them to a small set of APIs with strong forward-compatibility guarantees.

(That's why, despite a herculean effort by Microsoft, a non-trivial number of DOS games required the "reboot into DOS mode" option on Windows 95. Their in-house DOS-era analogues to DirectX were hooking too deeply into DOS for Windows to fake without a full-blown emulator.)

Games are actually the best candidate for sandboxing via something like Flatpak because, aside from needing accelerated graphics and networking (which pretty much everything seems to need these days), they're completely self-contained.

(eg. They don't need to match the system widget theme or common dialogs (eg. Open/Save), they don't need to register file-type associations so you can double-click their documents, their disk access is limited to "config" and "saves" folders specific to them, they don't do any printing or scanning, their only special peripherals are joysticks/gamepads, which are about as standard as you can get for "special", they're not utilities meant to do something like screencasting or keyboard macros, etc.) The answer to that is complicated, but it boils down to Linux still catching up to Windows on the whole "solution to DLL Hell" issue.

GOG and other Linux game distributors try to address this by bundling known-good libraries but occasionally bundle too much. Flatpak aims to advance that technique by providing "runtime" dependency bundles for packages to depend on, which are analogous to WinSXS or the Steam Runtime.

That provides a balance point because the application asks for a specific version of the runtime and the distro still gets to tweak the boundary between "kept old for compatibility with the application" and "made new for compatibility with the OS". (Similar to how an emulator provides an isolation layer which is old for the application and new for the OS.)

We'll have to agree to disagree. I firmly believe this is selection bias. (ie. You're just hanging around in places where the more immature Linux users are.)

If you want to see more mature Linux users, check out places like the comment threads on LWN.net articles.

Again, that's one of the design goals of Flatpak. (Part of the reason it follows APKs in making sandboxing so easy is so that, if something doesn't get security updates, the potential harm will be as limited as possible.)

Flatpak also has something that none of the other options managed: They got patches into the big widget toolkits so that most applications don't need to do anything to work in a sandbox... if the application asks GTK+ or Qt for a standard Open/Save dialog, the toolkit will just detect that it's running inside Flatpak and use the Flatpak APIs for requesting Open/Save dialogs.

(Flatpak takes a browser-like approach to sandboxing Open/Save. The application can't see outside the sandbox, but Flatpak can, so the desktop's privileged Flatpak host displays the dialog and, if the user clicks OK, it'll poke a hole in the sandbox before returning the selected path to the program.)

That's also another reason to run your applications inside Flatpak once your distro's KDE or GNOME is new enough, even if you have sandboxing turned off. There's finally a way to have all your applications share the same Open/Save/Print dialogs, regardless of what GUI toolkit they're using. Yeah. They pour an unbeatable amount of paid employee time into testing and working around compatibility gotchas because they remember that compatibility with existing DOS apps is what allowed early Windows to beat its competitors and compatibility with early Windows apps is what allows later Windows to keep holding off its competitors.

Raymond Chen's blog, The Old New Thing, has some really fascinating posts on the lengths they went to in order to ensure that compatibility.

"Yeah, they do it so well that newer version of Windows is a hard requirement for newer version of DirectX" ummm what?

political? you think Microsoft is in cahoots with the government or something. https://www.youtube.com/watch?v=G2y8Sx4B2Sk

politics (n.):
6. use of intrigue or strategy in obtaining any position of power or control, as in business, university, etc.
8. [to] play politics: to deal with people in an opportunistic, manipulative, or devious way, as for job advancement.

Still sounds conspiratorial to me.

Only in the sense that a company is made up of multiple people.

In Microsoft's case, it's just "We control Windows and we control DirectX. We can increase profits by forcing people to upgrade Windows to get full function out of the latest video cards."

(As demonstrated by the fact that OpenGL provides full access to the latest hardware features for as long as the video card manufacturer decides to continue releasing new drivers for old Windows versions.)

That's not force, that's just business. I don't even think it's bad business or even unethical. Software companies do this all the time. They release new software with new features to get you to buy it. A lot of people don't like Windows 10 because of it's bloatware, spyware and ugly interface. Those are the things people should really be focusing on. If I was Microsoft I would just pull a Coca Cola and Re-release Windows 7 with DX12 call it second edition and charge $400 USD for it.

The use of the word "forcing" was secondary to my point.

Feel free to substitute another synonym:

"We can increase profits by requiring people to upgrade Windows to get full function out of the latest video cards."

actually accelerated graphics are one of the major problems for flatpak.
libGL is rather badly suited for virtualization, since you can say that it is more or less a driver for your video card (tightly coupled to the kernel counterpart). Keeping the openGL provider as part of flatpaks supposedly (almost) static, stable runtime is quite problematic.
In practice that means when updating your nvidia driver on your host system, all flatpaks that use openGL will be broken until the flatpak runtime is updated to the same driver.
with mesa you might run into the problem that the version in the runtime is simply too old to recognize your video card(*).
again you rely on a constantly updated runtime.

add to that as of now there is no way of accessing udev to support dynamic devices. Which means you are back in the past with all the pitfalls of a static device tree :/
stuff like Unity Engine using udev to dynamically discover plugged in game controllers just don't work afaik

i am still unconvinced that flatpak is as good as the hype around it

** for gaming that is ancient ....

edit:
turns out you can also get mesa 17.2.7 on top of that, which is not quite as bad

(Seems I must have fallen asleep while reading)

You make a good point. In future I'll have to emphasize the "something like" part.

I hope they resolve that quickly, given how well-suited games are to sandboxing on an abstract level.

Last I heard, the current discussion was around designing a Wayland protocol to manage exposing gamepads and other non-standard input devices to applications.

I'll admit I have mixed feelings on that.

One the one hand, it would probably mean that input idleness checks for the screensaver would finally take non-keyboard/mouse input into account.

On the other hand, it increases the chance that my "gamepad input is directed to a non-focused window" use-case will stop working. (It's already annoying enough that Mupen64Plus only listens to button presses when focused, despite always listening to the analog axes.)

I don't mean to come off as splitting hairs. I'm a pro capitalist looking to start his own business someday so I tend to be very detailed about this sort of thing. Anyway I still can't agree with you because DX12 is still only optional. Win 10 still supports DX 9 through 12 and there's opengl and Vulkan. I don't have much experience working with API's personally but I do know from history that Direct X 9c was preferred over openGL despite John Carmac pushing for it in his Quick 3 engine. He was like "The industry shall use openGL!" to which the industry said "Thanks for the Q3 engine John, we’ll use it in all our games, but you can keep opengl we’re using dx9c.” Then he went back to playing with action figures.

Joking aside I’m not sold on the whole Microsoft requiring people to use DX and I never was. Developers has always had the freedom to use what they wanted for their games. The games used DX because the developers wanted to make no mistake about it. Same goes for Nvidia Hair Works. People got upset when Witcher 3 used hair and blamed Nvidia for some reason. It was there because someone (most likely on the art department) wanted it there.

Today developers are moving away from DX in favour of Vulkan. You might think of this as a good thing I’m personally indifferent as long as the backwards compatibility works.

The question is why though. Linux fans would have you believe that it’s because it’s closed source and propriety. But I don’t think that’s the reason at all. I think the reason is much more practical and less ideological. Again looking at the Steam hardware survey Windows 7 is still the most used OS. With DX12 being a Win10 only feature and Microsoft doing very little to make people want to use it why would you bother with an API like DX12 when DX11 has more reach and vulkan has even more. Also it looks like Vulkan may even better then DX12. If Win10 wasn’t so loathed and highly adopted I would expect DX12 to be far more popular.

Same here. I'm not sure why classic bundling can't solve these problems if developers would put some effort into doing it properly.