Quoting: fagnerln

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* AppImage is clearly not the way to go and I think most developers knows that
* Snap is basically Ubuntu-only
* Flatpak is cross-distributions

I'm just curious, what's the problem with appimage? It seems to work fine, some big projects like onlyoffice and emulators like yuzu and rpcs3 have success

I think the main issue with Appimage is that it's back to pick up sw randomly off the Internet. Which is not that great. Having only one centralized source sucks. But having a set of sources handled by professionals who check what you will install is quite great. AppImage is a bit like .exe for windows, with all related issues.
A secondary issue is that it is the supreme bloat since you really pack a whole lot of things in your app, and its corrolary: you can't update any part yourself - is it monolithic -, whereas for flatpak, you could force a newer runtime for the basics at least, or overload an installed flatpak with new features/libs if you want.

As you say, it is not a complete blocker either, and it does have some cases where it can be useful for distribution by stores like gog as an example. RPCS3 which does have a flatpak is not the best example though :)

View this comment - View article - View full comments

Quoting: CreakI didn't know Snap was installed by default on that many distros, I stand corrected.

EDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support [External Link]

Quoting: CreakI didn't know Snap was installed by default on that many distros, I stand corrected.

EDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support [External Link]

Indeed flatpak is default on all trendy distro I'd say: mint/pop/ elementary and Endless. Not bad, plus the big ones centos/RHEL and Fedora. On ubuntu, it is easy to install, and works golden. So I'd say that it has more effective user adoption than snap. You can also search the endless quantity of users asking how to remove snap from ubuntu... Whereas you don't really see anyone asking to remove flatpak. Simply because it is much less intrusive, no deamon running, and pretty much transparent when running. And especially because no on tries to shove it in our throats ... Flatpak is only there for when you need it: proprietary app you can't trust (slack, zoom etc), maybe browser if the sandbox makes you feel better (it shouldn't but that's another story) or on CentOS/RHEL where it enables you to access recent apps without messing with the base OS.
And if I want to deploy nextcloud, I prefer to use podman and use it to segment and isolate properly than to use a packet which update itself and I can't really control ... So thx for trying to package that, but no thanks.

In the end canonical did what canonical does: they made their own solution, trying to lock in people, tried to shove it to ubuntu users and derivatives, but seems to be slowly failing in front of the "common" alternative which was actually developped by more than one company, is better engineered and is actually focused on solving one problem instead of being a do-it-all/good-for-nothing that snap is (it tries to solve basically all deployement problems - app, server components, low level OS and even kernel ! - which have very different problematic and requirements with a "one size fit it all approach", needless to say that's not usually the best way to tackle engineering issues ...)

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: Cyba.Cowboy

Quoting: CreakWell there is at least a huge difference between AppImage and the others (AppImage being merely a huge dump of files that are uncompressed at a specific location and run there).

Meh.

I meant similar in the sense that AppImage loosely has similar goals... There are of course, some obvious differences (such as the fact that it doesn't usually provide libraries, it's not isolated, etc...); but the general idea is the same.

It is quite clearly the "most" different of the three, though...

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* Snap is basically Ubuntu-only

Not really.

According to Wikipedia [External Link], Snaps are supported "out of the box" by at least:
* Ubuntu (plus most of its deviations)
* Gallium OS
* Manjaro
* Zorin OS
* KDE Neon
* Solus
* Li-f-e

I'm not familiar with some of those operating systems, but Manjaro are KDE Neon are certainly big names, and Snaps can be optionally added to a MUCH bigger list of operating systems... In theory, it can run under almost any Linux-based operating system.

So no, not Ubuntu-only.

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* Flatpak is cross-distributions

Snap is too, so I don't understand your point.

As I wrote above, FlatPak is slightly more "open" - which is the primary reason why I think it is the superior of the two (though I find the performance much better under Snap); but it is certainly not the only one of the two that has cross-distribution support.

Huh, I would be shocked if 'out of the box support' equals 'installed by default'. Especially for Manjaro.

The main issue with snaps is that they are not decentralized, Canonical controls tge store. Where flatpaks and AppImages are open. AppImages are basically the same as the Mac's DMG files, so there is that.

Indeed, snap is not setup out of the box on Manjaro: https://wiki.manjaro.org/index.php/Snap [External Link].

The fact that it is "supported" other distos does not say much either. It is supposed to work on Fedora, but it has been broken on Fedora 33 for quite a while before it was fixed as an example (due to a bug which avoided gui snaps from working on gnome 3.38 and wayland). I also had issues with snap + SELinux there when I tried which made spotify insta crash (and never tried again after to be honest, was just intellectual curiosity).
There is a large chance that it would break the same on Manjaro which also used gnome 3.38 and wayland. And from what I saw, bug probably stayed for month, which would tend to say that not many people cared either.

Also, Linux mint is now trying to act against snap after the chromium fake apt drama. PopOS stand agaisnt snap also ... So yeah, I think Snap can be considered a mostly ubuntu/some derivatives stuff. And no, it does not seems to be preinstalled on that many distros.

As for the perf, snap tend to be slow to load because of decompression, and require a root daemon to setup the loops (which is a design flow no matter how you look at it, as it enlarge attack surface).
For perf, I have used flatpak a lot at home, and I did use snap on my ubuntu work laptop, and flatpak - even on ubuntu - seems to be more reactive. At least, flatpak loads instantly even after a reboot, can't say the same for snaps. Flatpak also runs golden on the distros I've used it on (ubuntu,debian, arch and centos).

So yeah, I would say that flatpak is an overall win as a general, non distro specific packet manager. Also, it does not rely on a fully proprietary server, completely controlled by one company which is the last nail in Snap's coffin in my opinion.

View this comment - View article - View full comments

Quoting: GuestAs for someone who is still undecided which CPU to get for an overdue upgrade the "refreshed 10th gen" i3-10325 looks quite good in comparison to a ryzen 3600 or is it? At least the price looks appealing.

Considering the price difference, I would go either with a 11400 or its "F" version if you don't care at all for integrated graphics. If you care for integrated graphics, 11400 will be the must buy anyway since it comes with massively faster igpu.
Both get 2 extra cores, and real 11th gen IPC boost.
The F version (no integrated gpu )is 3$ more, so it's almost a no brainer at that point ... The non F version is about 30$ more, but I'd say it's well worth it if you care for igpu. Quite cheaper than the ryzen 3600 I found on the internet still, and quite likely much more available. You get same core count, higher freq and with 11th gen IPC so it should be better overall indeed.

My recommendation for igpu: I find it's always nice to have one, and a good one if possible as you can always fry your gpu, or you might want to use iGPU for VMs when you want to try out updates or a new distro without installing bare metal. Intel has hw accelerated gpu virtualisation tech even in consumer CPUs which is very cool too, and can help you test much more stuff.

EDIT: For someone interested in iGPUs, the 11500 is just 10$ more, still quite cheaper than the ryzen 3600, slightly higher freq, but also full Xe die (33% more of everything), so should be even more powerful on that iGPU front.

View this comment - View article - View full comments

That does seems to take the right path. For the pcie lane, I see 44 lanes, so 20 gen 4 and 24 gen 3 ?
That being said, with the 10nm supposedly coming this year, I wouldn't buy this gen unless my current hw died. And even then I'd go AMD as stocks seems to finally be coming (unless gaming bench show intel be wayyyyyyy above, and it would have to be really significative).
Overall, even if you want to stay with Intel, I'd recommend to wait for 10nm sunny cove end of year. Considering what they seem to have fianlly managed on 14nm+++++++++++++ their 10nm should finally be great again. And more pcie lanes is awesome, albeit I hope they can deliver at least 24 pcie 4 lanes next gen, for dual ssd on pcie4, or to have some spare for an sfp+ network card on a x1 slot.

View this comment - View article - View full comments

Quoting: PinguinoCould anyone give me a one-sentence summary on the difference between emulators and translation layers? I've done some searching and I think I got the gist of it (low-level emulators are basically trying to recreate the emulated OS instead of just wrapping individual functions), but I couldn't see much distinction between high-level emulation and a translator.

TLDR: A translation layer is passive while an emulator is active.

I think the cleanest way to explain is that in a translation layer, the target code is executed as is, natively. There is no action on the code itself, it runs normally on the hw, without any active layer in between. This means that the translation layer is completely passive, you just drop libraries that translate a windows call into a Linux one, and they are called transparently by the target code.

An emulator on the opposite is active, even for an "high level" emulator. There is an active piece of sw that reads the target code and modify it on the fly, executing the resulting code on the host. You can have various levels of emulation, if both target and host have the same CPU arch, you can for example only replace some bits of codes to call a different set of sw function, or you could translate older instructions into new optimized one. You can also emulate some target sw parts, such as the os, using a native library. So when you catch a call to a syscall used to print a char, instead of translating the target implem of that syscall, you will replace it with a call to the native version. And of course, you can also have a complete emulator (older consoles that don't really have an OS as an example) which will translate absolutely all the code, and also emulate the hw itself to have the best precision (accurate timing information as an example).

View this comment - View article - View full comments

Somehow, it feels like fighting games just got more eccentric, except for the laugh, hard to be interested honestly.

View this comment - View article - View full comments

Quoting: Guest

Quoting: 3zekiel

Typically, a filesystem requires an executable file to be flagged as such before the operating system can run it. The most common implementation is part of what is typically referred to as "traditional Unix permissions." Unlike other modern (and many historic) operating systems, this is not supported by Windows or its default filesystems

And there goes many security issues with the ability to exec anything off the internet ...

For the tools itself, it's true that it's a good idea. Might help with some very easily avoidable issues.

I don't get it, "anything off the internet"?
This tool seems to allow you to set executable bits on executable files on files the user wants to execute because he wants to play.
?

I was not talking about the tool, but about the windows filesystem, which has no basic right management. Meaning, nothing avoid you from executing random stuff. Well, nowadays there is some pop up that might appear to ask your passwd before installing stuff, but users are so used to just type it (and so many passwds are probably just "qwerty") whenever asked ...

View this comment - View article - View full comments

Typically, a filesystem requires an executable file to be flagged as such before the operating system can run it. The most common implementation is part of what is typically referred to as "traditional Unix permissions." Unlike other modern (and many historic) operating systems, this is not supported by Windows or its default filesystems

Ah windows and its lack of executable bit in the filesystem - or of any native access control btw. There goes so many security issues, since it gives the ability to exec anything downloaded anywhere on the internet ...

As for the tool itself, it's true that it's a good idea to solve this kind of small issues. Might help with some very easily avoidable issues and frustrations.

EDIT: made the message clearer (hopefully).

View this comment - View article - View full comments

Quoting: EMO GANGSTERwill this work with q4os it's a fork Debian I have an old tiny Optiplex that be great for a remote pc

As long as you have flatpak support, yes. It is the wonderful part of flatpak :)

View this comment - View article - View full comments