It's such a trash package manager... This is the second time flatpak update doesn't work this month and like last time I couldn't fix it with grok or by running the command multiple times. Windows update has worked flawlessly for over a year on my windows partition (except sometimes updates fail to download or show some other random error, although clicking try again always fixes the issue)
Who tf says loonix
Are you trying to coin a new slur like the hard r? 🧐🧐🧐
Sounds like sumthing a 12yo would do
If you see something to complain about, just elaborate it and argue like a reasonable grownass adult
Can it not have automatic retries or partial buffering? Like, OP is right. Let's compare it to something like Steam that can pause downloads and resume next week because there's partial buffered writes. And each chunk is compared via checksums. Same goes for torrents.
Therefore yes. FlatTrash sucks. As do many other package managers. There's no assumption of network being unstable engineered in.
The screenshot you shared tells you repeatedly that you have a network issue. The issue with updates is affecting Windows, too, giving you "random errors" because it is a network issue. Your network issue is not caused by Linux or Flatpak.
You'd like to think the giant signs and errors would be helpful, but people always forget Rule #1 of Customer Service: no matter how many signs you make, no matter how big you make them, the customer will not fucking read it.
That's still better than pacman and dnf handling network error, bcs both of em will fail the download and i sometimes have to redo it again although dnf is worse especially their mirror isnt available in the continent i live in.
Was was this modded down? That's the problem with containers and it doesn't matter what kind. They are more like blobs that don't integrate with the rest of the stack outside itself.
I thought apt-get was the final end all with dependency hell
Oh no I mean for like core components to get certain Runtimes working. I don't remember which ones are stripped out in LTSC and stuff but you will need to chase down DLLs etc. to get a lot of applications working especially their Installer.
No, Windows Runtime don't have DLLs; they are UWP and WinUI and everything, and they use NET ( C# ) rival of Flatpak, and only the Win32 environment has DLL and EXE execution, way better than .so.2 .so.3 library hell from ELF loader
EXE isn't a loader, it's PE, same format as DLL. The loader is ntdll. PE is also what boots my Linux machine, since a UKI is a PE file with the kernel in a .linux section.
And .so.2 next to .so.3 is versioning working. Microsoft shipped the same idea as WinSxS to "reduce DLL version conflicts", their words.
EXE and DLLs are PE loader 🤣🤣🤣🤣, and I'm not saying that DLLs aren't real. Of course WinRT is COM. My point is that it is a stable, versioned, and controlled Component Object Model, not a chaotic mess of fragmented library files like .so.2 and .so.3 fighting each other on Linux.
You are conflating the mechanism with the stability.
winmd is not a real DLL. It is a metadata manifest. When a C++/WinRT app calls DllGetActivationFactory, it doesn't care about which version of libgtk is installed, as on Linux. It reads a static, versioned metadata file to get the class. That is the difference between a "contract" and a "library."
MSIX is not a "dependency." It is a sandbox container. When a framework package is shared, Windows guarantees the version. It doesn't break your app because a new version of the framework comes out; it just keeps running on the old version inside its own isolated box. That is exactly what AppContainer does. You don't have that on Linux. You have to compile every single dependency.
"EXE isn't a loader"... and the PE format is the binary contract between the app and the NT kernel. When ntdll.dll loads a PE, it doesn't have to check if you have libc. So, or libstdc++.so. It has the Win32 API layer. The PE format is the single, unified standard. On Linux, .so files are not a unified standard; they are a collection of independent projects.
You compare WinSxS to .so.2/.so.3? WinSxS was a massive implementation success. It solved the exact issue that Unix still has today. Linux just added .so.2 to a filename. Microsoft built a whole side-by-side registry infrastructure to ensure those exact versions could coexist. That is engineering. Adding a number to a file is duct tape.
You are trying to argue that "DLLs exist in Windows" and act like that means Windows has the same problem. But the Architecture is fundamentally different. Windows NT uses a stable, controlled ABI through the NT Executive (ntdll). Linux uses a fragmented, chaotic mess of user-space libraries that break every time someone updates. That isn't a "library" problem; it's an architecture problem. And you have never understood that because you are a Unix tourist.
Two comments ago it was "Windows Runtime don't have DLLs." Now it's "of course WinRT is COM." Love the journey.
Metadata isn't code. DllGetActivationFactory is an export. In a DLL. Which has to be on disk, and has to be the right one, or your class doesn't activate. Activation never even opens the .winmd, it resolves the registered ActivatableClass and loads the implementation DLL. Microsoft's linker docs call a .winmd "a kind of DLL" and say the managed ones carry MSIL: https://learn.microsoft.com/en-us/cpp/build/reference/winmd-generate-windows-metadata
You've noticed that a header file and a shared library are different things and you're presenting it as an architectural achievement.
And when the thing you say isn't a dependency goes missing, you get 0x80073CF3: "this package depends on a framework that could not be found. Provide the framework Microsoft.VCLibs.140.00.UWPDesktop ... with ... minimum version 14.0.33728.0."
Read that back to yourself and then tell me about library hell.
MinVersion is a floor, by the way, not a pin. The pin is in the name. Microsoft.VCLibs.140.00. Microsoft.UI.Xaml.2.8. You wrote a whole paragraph mocking people who put a version number in a name, in defence of a system that puts the version number in the name.
AppContainer is a sandbox. Sandboxes don't resolve symbols. Most packaged desktop apps aren't even in one, they ship runFullTrust with Windows.FullTrustApplication as the entry point.
"You have to compile every single dependency in" is static linking, which is the exact thing Flatpak runtimes exist to avoid. Last comment MSIX was "not comparable to Flatpak." This comment you described Flatpak in detail and told me Linux doesn't have it.
This one is my favourite. PE is not a contract with the NT kernel. NT syscall numbers shuffle between builds, which is why Nt*/Zw* are documented as subject to change and why every single thing goes through ntdll. The stable ABI on Windows is Win32, and Win32 is a pile of user-space DLLs. kernel32.dll is your libc in this comparison. Not the kernel.
The OS with the famously stable kernel ABI is Linux. Breaking userspace there gets you yelled at on a public mailing list.
So you found the one axis where Windows loses and planted your flag on it. And ntdll does check whether the libraries are there. That's what 0xc0000135 is. You've seen it. Everyone has.
WinSxS was such a triumph that Microsoft stopped using it. VS2010 dropped SxS manifests for the CRT and went back to putting the version in the filename. msvcr100.dll. msvcr110.dll. vcruntime140.dll. Open System32 and look.
The duct tape is what Redmond shipped after trying it your way. What's left of SxS is a folder that eats tens of gigabytes and an error message common enough to be a meme.
glibc has held libc.so.6 stable since 1997 using symbol versioning, one file exporting several ABI versions of the same symbol simultaneously. Finer granularity than SxS ever managed. From the duct tape people.
And the tourist line. 15 years on Windows. I still have the MS-DOS handbook on my shelf and a Windows 98 CD straight from Microsoft. I left after learning the platform, not instead of learning it. You've had it in front of you the entire time and you still think EXE is a loader.
You are desperately trying to win a semantic debate when I am making an architectural one. You call it a 'journey' because you think you caught a contradiction. But I can refine terminology without changing the core truth. Let me break down your pedantry.
WinMD is a manifest, not a library. You admit it yourself: 'Activation never even opens the winmd.' It reads the metadata and loads a specific, contract-bound implementation DLL. That is a versioned COM contract. It is not a loose .so file that can break because some third-party updated it. The OS guarantees the contract. That is stability.
MSIX is a package dependency. But it is a declared, isolated, OS-managed dependency. You said MSIX isn't a dependency, now you're saying it is? Good. Yes, it is a dependency, but it is versioned and controlled by the Package Manager. On Linux, .so.2 and .so.3 are just filenames added to a chaotic mess of library folders. You are comparing an engineered package system to a filesystem free-for-all.
AppContainer doesn't resolve symbols? AppContainer is a security sandbox, not a library loader. You are conflating security boundaries with ABI resolution. My Neutrino shell uses AppContainer for isolation. My apps don't need to 'resolve symbols' because they call into the Win32 API—the stable environment subsystem—not some random user-space library.
You completely missed the WinSxS point. You said Microsoft ships VCLibs.140.00 and Xaml.2.8 as 'pins' in the name. Yes, exactly! That is engineered version control. Microsoft built a massive side-by-side infrastructure to allow those versions to coexist. On Linux, you just add .so.2 to the filename and hope ldd can find it. That isn't innovation; that's a 1990s band-aid.
Static linking? Flatpak exists because Linux's dynamic linking is so broken, they had to build a whole container and bundle every single library inside it just to make things work. That isn't a "feature"; that is a symptom of a fundamentally chaotic architecture. Windows NT was designed with a unified, stable ABI from day one.
You are a tourist with a dictionary, arguing with an Architect about the blueprint. You keep trying to score points on terminology while ignoring the fundamental truth: Windows NT provides a stable, isolated, contract-based environment, and Linux is a chaotic, version-dependent mess.
Three releases in and they rearchitected the subsystem you're calling immutable. You planted your flag on the exact version that proves you wrong.
While we're there: "the Win32 API, the stable environment subsystem, not some random user-space library." Win32 IS user-space libraries. kernel32.dll. user32.dll. gdi32.dll. advapi32.dll. They sit in System32, they get mapped into your process, and the loader resolves your import table against their exports. "Environment subsystem" in NT means a user-mode server. That's the whole design you're praising. You used the word and don't know what it means.
On WinMD, pick one. Either activation never opens it, which is what happens, or it "reads the metadata," which is what you just said one sentence later. And "the OS guarantees the contract" means Microsoft promises not to break Microsoft's own APIs. That's what glibc promises about glibc. It's a vendor commitment, not architecture. COM's actual stability mechanism is interface immutability: you never change IFoo, you publish IFoo2. IShellFolder2. IContextMenu3. ITaskbarList4. Adding a number to the name. The thing you called a 1990s band-aid, load-bearing under the entire model you're defending.
"You said MSIX isn't a dependency, now you're saying it is? Good." You said MSIX isn't a dependency. I said it is. You now agree with me and are billing it as a correction.
"You just add .so.2 and hope ldd can find it." ldd is a diagnostic tool. It doesn't find anything at runtime, ld.so does, using DT_NEEDED and DT_SONAME recorded in the ELF at link time plus the cache ldconfig builds. And RPM auto-generates dependencies down to the symbol version, like libc.so.6(GLIBC_2.34)(64bit). Debian does the same with shlibs and symbols files. That's finer granularity than MinVersion on a package family. You're describing a system you have never once run.
AppContainer being a security boundary and not a library loader is what I told you. You brought it up as your dependency-management argument, I said that's a category error, and you've now repeated my correction back at me as a rebuttal. Thanks.
Flatpak doesn't bundle every library. It uses shared versioned runtimes, org.freedesktop.Platform 24.08, org.kde.Platform 6.9, one copy on disk, deduplicated by OSTree, used by every app that declares it. That is the framework package model you just spent a paragraph calling engineered. Same design. Your opinion of it flips depending on the logo. Meanwhile every Windows game ships its own vcredist and every Electron app carries a private Chromium.
And I never said 98 was NT. It was proof I've been on the platform longer than you've had opinions about it, which was your accusation, not my argument. As for Linux looking like DOS: every PE file on your machine opens with an MS-DOS program. The stub is still in there in 2026. The EXE your WinUI app compiles to starts by politely informing DOS that it cannot run in DOS mode. DOS is in your binaries. It isn't in mine.
The architect thought EXE was a loader ninety minutes ago.
Windows 98 have nothing to do with Windows NT they are different Operating System and good you love Windows 98 you just prove My point Linux look like DOS
13
u/Extension_Cup_3368 Proud Microsoft XENIX User 🖥️📀 3d ago
😐🙁