I remember in 1995-ish or something when I used the internet for the first time using the Netscape browser… And I was asking a friend if he had tried all the web sites yet. Just got a weird look back… :) I didn’t know what the internet was back then at first.
There are portals: docs.flatpak.org/en/…/desktop-integration.html#po… . they allow secure access to many features. Also any flatpak app still has access to a private app-specific filesystem, just not to the host.
Doesn’t work for all applications but for many sand boxing is possible without a loss of features.
No filesystem access for a flatpak app just means it cant read host system files on its own, without user permission. You can still give it files or directories of files through the file explorer for the app to work with, just that it’s much safer since it can only otherwise view files in its sandbox.
[…] aren’t there some folks who want flatpak/snap/appimage to basically replace traditional package managers?
There might be people who think that, but that isn’t realistic. Flatpak is a package manager for user facing apps, mostly gui apps.
The core system apps will still be installed by a system package manager. I.e rpm-ostree on immutable Fedora or transactional-update/zypper on OpenSUSE MicroOS.
Snap can do system apps and user facing apps and fully snap-based Ubuntu might come in the future.
But this won’t force people to use them. Traditional package managers will keep existing for system apps and maintainers will proabably keep their gui packages in the repos.
There’s Obfuscate, an image redactor, and Metadata Cleaner which is self-descriptive. Both works properly without any filesystem access at all, because they use the file picker portal to ask the user for the files to be processed.
This kind of thing could work for a few apps, say a color picker utility or a QR code generator etc.
Looking at the docs, it isn’t clear if apps can write to their own namespace (instead of writing to user folders directly), but if they can, we could expand the scope to games like supertuxkart, 2048 etc, which would then be able to save user milestones and progress in their own area - a bit like how Android apps do it
It’s a great start IMO, although admittedly there is still work to do. Flatpak atm bridges the gap with allowing new apps, requiring new libs, to run on older stable/LTS distros
Yes, they can. There are app-specific folders in .local that flatpaks can read and write to specifically for this purpose, and also the file picking dialog may give access to the one specific file you picked.
Android IMO has great usability in exposing a database to apps, which means they aren’t required to ship their own database engine.
Not what they did on the surface (limiting source to only customers). That’s allowed by the GPL. But they went beyond that which imo makes them non-compliant.
RH will cancel your access/agreement if you share the GPL’d source with others. That’s directly forbidden by section 6 of the GPLv2. RH is free to cancel your agreement when they want, but not because you exercised your rights under the GPL.
Once your agreement is canceled, you also lose access to the matching source for other GPL’d packages installed on your system. RH could offer other methods to be in compliance, but as far as I know, they have not.
Flatpak packages should ask for every permission they need, and the user needs to approve every one of them.
Right now, we have this weird in-between state where some flatpak packages ship with limited permissions (like Bottles). That’s because every permission the package asks for is immediately granted. The user doesn’t get a chance to refuse these requests. This current model serves to make life more difficult for non-malicious flatpak packagers while failing to protect users from malicious packages.
Also, GNOME needs a Flatpak permissions center like KDE. You shouldn’t need to install a third party program to manage permissions.
Absolutely, permissions should be disabled by default, and only when the app needs to do something that requires a certain permission should it ask for it.
Maybe even do something like Android, where permissions automatically get revoked if you don’t use an app for a certain time. I love that feature.
I think it’s enabled by default, but you can also just disable it for specific apps.
But if you leave it enabled and permissions get revoked after a while, you’ll get a notification telling you about it. I think that’s fair.
There’s always going to be a debate on whether something like this should be opt-in or opt-out, but for the purpose of privacy and data security, it makes sense to be on by default, I reckon.
I don’t doubt it, but this is a good place to start.
This claim has interesting phrasing:
Adding X11 sandboxing via a nested X11 server, such as Xpra, would not be difficult, but Flatpak developers refuse to acknowledge this and continue to claim, “X11 is impossible to secure”.
If you look at the GNOME post, you’ll see they haven’t argued against including a nested X server at all:
Now that the basics are working it’s time to start looking at how to create a real sandbox. This is going to require a lot of changes to the Linux stack. For instance, we have to use Wayland instead of X11, because X11 is impossible to secure.
I’m not saying they haven’t refused to acknowledge this elsewhere, but it’s strange to point to this blog post which acknowledges that the sandbox is very much a work-in-progress and agrees with Madaidan that X11 is hard to secure.
Does Xpra provide better sandboxing than XWayland? If not, I think the Flatpak developer’s solution to this is: just use Wayland. And obviously, there’s plenty of room to improve with the permissions Flatpak does offer.
I did some searching on the Flatpak Github for issues and found that you can actually use Xpra with Flatpak, and the answer is “just use Wayland”:
As odd as this may sound, you should not enable (blind) unattended updates of Flatpak packages. If you or a Flatpak frontend (app store) simply executes flatpak update -y, Flatpaks will be automatically granted any new permissions declared upstream without notifying you. Using automatic update with GNOME Software is fine, as it does not automatically update Flatpaks with permission changes and notifies the user instead.
It’s great that GNOME Software notifies you when permissions change! I don’t use Flatpak enough to know, but I hope flatpak update notifies you too if you don’t use the -y option.
I’ve tried to combat this a bit with a global Flatpak override that takes unnecessarily broad permissions away by default, like filesystem=home, but apps could easily circumvent it by requesting permissions for specific subdirectories. This cat-and-mouse game could be fixed by allowing a recursive override, such as nofilesystem=home/*.
But even then, there is still the issue with D-Bus access, which is even more difficult to control …
I think it is sad that Flatpak finally provides the tool to restrict desktop apps in the same way that mobile apps have been restricted for a decade, but the implementation chooses to be insecure by default and only provides limited options to make it secure by default.
I think the main reason why the implementation is insecure by default is simply because when it started most applications did not use portals and many portals we have today did not exist. You had to poke holes in the sandbox to make anything work cause all applications expected to run unconstrained. In the future as more apps become flatpak aware this should stop being an issue.
I’m not experienced enough with linux to understand if this is a question or a statement on what I can do. In either case, I don’t know how to interpret what this means.
They are confirming that, yes, it is an option to have a partition dedicated to just the user’s (your) home environment and folders
and
asking if that is an option that appeals to you or you have already considered.
It is what I prefer, but there are people who have good reason to not like that. It’s worth trying out imo, and later if you find that it doesn’t suit you, that’s okay, you’ll just need to find another solution
I find it annoying to worry about multiple partition sizes. Having to make sure your root and home partition are sized correctly is one more thing to think about.
That makes sense. I guess for my case it’s fine since I have more storage than I can use. Additionally, I keep my most important data on multiple offline storages and even that is quite minimal.
When installing Linux, you first have to partition your hard drive.
You can create a seperate partition for your /home folder in addition to the one you create for the rest of the system.
Then when you install a different distro, you can tell the installer to use your /home partition without changing or formatting it. After installation, you will have the new Linux system and the /home folder from your old one. That way, all user settings and flatpak settings will be the same as before reinstalling.
But if you’re a new Linux user, I don’t know how helpful this is. It’s easier to just copy everything in /home to an external drive, then copy it back after you reinstalled, for the same effect.
That first bit makes sense, I should be able to figure that out I think.
The reason I want to avoid using an external drive is because it takes a minimum an hour to transfer 4 games worth of data currently. That time is an inhibiting factor for me. I’d like to minimize downtime.
Also I’d like to test gaming oriented distributions with newer kernels compared to what Linux Mint ships with.
Additionally, ensure that flatpaks are installed within that home partition. Some distros (like Fedora) default to installing flatpaks system-wide (and thus flatpaks end up being installed in /var instead). So, after ensuring that your home folder is correctly found within the home partition, just install flatpaks with the flatpak install --user *package-name* command.
The desktop is finally catching up with the more restrictive permissions model where an app doesn’t just have the ability to do anything the user can do but instead only has access to what it needs.
Going with a familiar interface style like the ones people already use on mobile just makes sense.
I’m not a fan of all the blank space in their design language, it doesn’t look bad or anything but I don’t have a touch screen and having to move the mouse around so much for long periods of time physically hurts, especially on laptops.
I wish it was more… desktop friendly… If they took more advantage of the dynamic layout capabilities of GTK4 to have a better desktop layout based on their already existing design language while still having this mobile esk layout for other devices, we’d be golden.
If they don’t want to do that, they should at least increase the default mouse speed so it feels better out of the box.
Haha so true, and I say this as a Linux user for like 20 years. There are some Linux users who value functionality over form so much that they prefer cluttered user interfaces with tiny borders to maximize screen space.
If your laptop periodically freezes, switching distros won’t fix it.
Identifying the underlying issue (which is most likely a hardware defect) would be a better use of your time.
Your first step would be to try and reproduce the issue. See under what circumstances it happens. See if it happens from a live USB or only from your installed system (If it does, this eliminates the SSD as most probable culprit). Do a RAM test. Then ask for help with further trouble-shooting.
I’ve spoken to another user who has the same issue as me and they made a couple suggestions including disabling certain options in BIOS or trying a distribution with a newer kernel.
At first I thought it was issues with iGPU and dGPU switching but I’m beginning to suspect that’s not the case.
Reproducing when it freezes is a challenge because it’s very inconsistent and does not leave and crash reports.
The only improvement I’ve seen yet is switching from Linux Mint 21.2 to LMDE 6 but the kernel is still older compared to the versions that I was suggested for my hardware.
I would like to try a newer kernel just for the sake of trying.
I feel you. The bugs that get the machine to crash and you have zero chance of getting any useful debug information, are by far the most annoying ones.
In my experience it’s most of the time some driver issues in the kernel or the (NVidia) proprietary drivers. Or an hardware issue. On Debian I can install several kernel versions alongside each other. So there would be no need for me to install more than one distribution. Most of the times a proper crash isn’t caused by the userspace anyways, so it boils down to the different kernel versions and configurations anyways. You could also try an older kernel.
On my debian machine something like journalctl -b 1 -k shows stuff. There’s also lots of debug files in /var/log/ like boot.logdebug, kern.log, messages, syslog.
But it somehow needs to be able to store the log on your disk. If the system craps out completely, it won’t get written to disk. The magic SysRequest keys might help if it only freezes. I learned “Raising elephants is so utterly boring.” You might wanna goggle that and learn how to do it.
Other than that, I mostly look at all logs (no ‘-b1’ and search for the place where it rebooted. Sometimes you find other related stuff while scrolling. But my own (old) thinkpad doesn’t ever crash.
I think there are other crash-dump tools available. It believe there’s something called ‘kdump-tools’ available on Debian. YMMV.
I have an AMD + AMD setup but apparently the Dell G5 series has issues with linux so it’s been an uphill challenge.
I did see that LMDE 6 makes it easy to boot different kernels at startup which is handy. I tried looking at Liquorix Kernel but I don’t think it’s ready for LMDE 6 just yet. I can’t recall exactly why but I got a big nope when trying to download it. I think I tried looking at the Zen Kernel as well but couldn’t figure out if it’s just for Arch or if it’s compatible with Debian.
Too much to learn and now enough hours or attention span. Slow progress but I guess it’s a thing to do besides watching my plants grow.
pages like this also suggest things like updating the BIOS and the graphics card firmware with some AMD tool. And I’ve read several times you should try the kernel parameter amdgpu.runpm=0
Make sure to do all of that first. And observe if the freezes happen in certain circumstances. Maybe you can deduct something from that. Maybe it happens while gaming (GPU). Or when under load. Or if you move it around (loose connection), or when hot or after a certain time even if idle. Disable power management and see if that helps. Should be less effort than installing 5 operating systems. (If the crash isn’t super rare) And try using the magic SysReq keys to force linux to sync and reboot to see if the kernel is still alive somehow.
Fortunately I updated my BIOS from windows before switching to Linux and as of recently, I still have the latest version.
I added amdgpu.runpm=0 and that did increase stability considerably. My system froze up way less often which was great.
I also found that adding processor.max_cstate=1 has made my system even more stable and I haven’t had a freeze up in days now. This page gives a nice run down of what it does.
I wouldn’t be surprised if there is a freeze up in the future but overall my system has been a lot more stable making everything far more enjoyable.
Maybe just start with the different versions available in your distro’s package manager. I’ve never downloaded a custom kernel from somewhere else. (Well, I have but that was embedded stuff and not a desktop computer.)
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.