LeFantome

joined 2 years ago
[–] LeFantome@programming.dev 15 points 4 months ago

The appeal of Flatpak is not that I prefer it to my distro package manager.

The appeal is for the application author who finds the fragmentation in Linux a problem. It is a way for them to target “Linux” and not individual distros. It is a way for app authors to control the distribution and the support surface in a way that turning over control to package managers does not allow.

Which means the appeal for me is just that I can get apps as Flatpak that I cannot find in my distro repo.

On Arch, I hardly ever use Flatpak. On other distros, I use them more. I do use the pgAdmin Flatpak everywhere though because all the distro versions I have tried are garbage.

[–] LeFantome@programming.dev 4 points 4 months ago (1 children)

If you are using FreeBSD, you are probably using the Almquist Shell.

https://en.m.wikipedia.org/wiki/Almquist_shell

BSD has not used Bourne since the 90’s. Bash is of course the “Bourne Again Shell”.

For Linux fans, “dash” is the (Debian Almquist Shell). It is the Linux version of the BSD shell. Dash is the default /usr/bin/sh in Debian and Ubuntu I think. So, pretty close to the same shell as FreeBSD.

[–] LeFantome@programming.dev 2 points 4 months ago

In APK based systems (Alpine, Chimera, Adelie) there is /etc/apk/world

It is a list of all the packages you have explicitly installed. When you add and remove from this list (all apk does), the system solves for dependencies and makes sure you have the right packages installed.

You could bring up a new system by updating this file.

[–] LeFantome@programming.dev 6 points 4 months ago

I was intrigued by XFCE on Wayland so I looked into it.

XFCE is not really available on Wayland yet. XFWM is X11 only and there is no XFCE compositor.

What Leap is doing is running the XFCE panel and apps on Labwc. When I have tried this, “it works” but it is certainly not as polished as XFCE on Xorg.

I am a Wayland fan so overall I support OpenSUSE moving to Wayland. This seems like a bit of disservice to XFCE fans though as I am not sure the DE is ready yet. And the take-away is going to be that it is Wayland that is not working.

[–] LeFantome@programming.dev 13 points 4 months ago

limited functionality as it’s not the full blown .NET

This is misleading to the point of being completely wrong

On Linux, you do not have access to Windows UI frameworks like WinForms, the Windows registry, and to System.Drawimg (because it is just a thin wrapper over Win32). Essentially the entire .NET standard library is available on Linux.

I would argue that .NET is actually better on Linux for some things (like web dev).

That said, I can see no reason to use PowerShell on Linux unless you are a .NET dev.

There are PowerShell cmdlets that do not work on Linux. Again, mostly stuff that talks to explicitly Windows services and sub-systems. But that has nothing to do with .NET at all. Also, path separators and case sensitivity is different on Linux. So, cross-platform scripting is a pain.

[–] LeFantome@programming.dev 1 points 4 months ago (1 children)

Stable should mean that it runs stable, runs without crashing. In most Linux distros though, stable means “not changing”. That is not the same thing.

So, Debian Stable can ship software with a design problem that makes it prone to crashing. That problem can be solved in a newer version (more stable) but Debian will continue to ship the older version (the crashy one) because that is what stable means to Debian.

A good example is that Debian Trixie is about to ship with NVIDIA drivers from a year ago that have problems with Wayland. There are newer drivers that work better. But Debian will ship the old ones.

Static and stable are not the same thing.

[–] LeFantome@programming.dev 1 points 4 months ago

Of course there is lots to criticize. And it does not get worse than electron. But it is pretty easy to run a fairly lean desktop in 2025. And bloated applications are not a new invention.

I guess we can talk about the “rise” of interpreted languages. As long as we ignore that the Lingua Franca of the 8 bit era was BASiC I guess. Or Logo! We also have to ignore hugely popular languages in their era like Perl 5, Lisp, TCL, Scheme, and PHP. How about all those Bash scripts? And Javascript is less interpreted than it used to be as you say. I assume you mean Python but it is over 30 years old and PyPy is a thing. Most newer languages are JIT or fully compiled. Rust, Go, Swift, Carbon, and Zig are all compiled languages. Kotlin, Gleam, and Elixir are JIT. What are all the new interpreted languages? If anything, I would say the trend is towards performance and efficiency.

JavaScript works against his point in a big way. Javascript was released 30 years ago and yet javascript code runs dramatically faster (on the same hardware) in a modern web browser than it will on one from back then. JavaScript engines are VERY heavily optimized and browser devs will move mountains for another percent or two. And WASM is even faster.

You can build Rust applications on Windows 95 and they are faster than C++ was back then. Not everyone has given up on performance.

Modern code can be much more parallel and asynchronous (faster). And there is a strong recent focus on memory safety and efficiency.

Networking and file systems are both much faster and more efficient than they used to be.

And of course modern processors are not just faster but have many more performance focussed instructions (SIMD, AVX, vector extensions, etc). And we have hardware acceleration for media codecs and of course virtualization which speed up applications dramatically. And technologies like hypervisor clusters and containers can lead to significantly better resource utilization in practice.

Anyway, his point is obvious and of course true to an extent. Not nearly to extent he claims though.

[–] LeFantome@programming.dev 1 points 4 months ago

I did not say it was incapable. I said that it doesn’t. It sounds like we agree.

[–] LeFantome@programming.dev 1 points 4 months ago

Very true though most have more in their own repos than EOS does.

[–] LeFantome@programming.dev 1 points 4 months ago

I know I am pointlessly late on this but…

You do not distribute the Flatpak runtime or Flatpak itself. You can depend on it but it is distributed separately. Flatpak may download these dependencies at the same time as your app bundle but it is not downloaded from you. And the libraries you are linking to (like Glibc) are LGPL or even more permissive.

If you put a GPL library into your application bundle, that could be a problem. But if your app is closed source, you are presumably not doing that.

[–] LeFantome@programming.dev 1 points 4 months ago (3 children)

I have not used Elementary in a long time. More “static” than stable though I would say. And you may have a problem with app selection.

It is less of a problem these days with things like Distrobox and Flatpak that you can use to expand your application selection.

view more: ‹ prev next ›