Posts
Nobody
@nobody_1677@lemmy.world
lemmy.world
New NTFS File-System Driver Submitted For Linux 7.1
13
2
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
Mid-life transitions - Christian Hergert stepping back from Red Hat and Gnome, s some major Gnome components are currently unmaintained
1
9
1
Nobody
@nobody_1677@lemmy.world
lemmy.world
daniel stenberg: The AI slop security reporting is basically extinct [in curl]... [bugs] are found with AI tools and normally high quality bug reports.
43
11
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
openSUSE Tumbleweed now defaults to systemd-boot on new installs
openSUSE Tumbleweed now defaults to systemd-boot on new installs
View on lemmy.world
15
2
1
Nobody
@nobody_1677@lemmy.world
lemmy.world
It’s based on Alma Linux, which is on version 10.1.
View full thread on lemmy.world
0
1
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
If you have all the AppArmor patches and use a custom snap store, I believe so. There’s some inefficiencies with flatpak that are currently ignored. For example, every flatpak app has its own bubblewrap processing running, though they are light on resource usage. However, inter process communication is really inefficient, there’s a lot of context switching. You have the app talking to the dbus proxy and the proxy talks the real dbus (there might even be a step between the dbus proxy and real dbus).
Meanwhile, for snap, this security stuff is handled by AppArmor security profiles. There’s no need for a dbus proxy.
View full thread on lemmy.world
3
0
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
That’s part of what I mean. Snap could be so much more interesting and useful if not for Canonical doing stuff like only allowing one store and slacking on proper support for non-AppArmor distros.
One of the more bizarre experiences I’ve had is that a Canonical employee packaged a version of a Minecraft launcher. It was absolutely garbage, didn’t even start. The first thing that comes to mind is that snap is just garbage. But for fun, I made my own package of it, and it just worked perfectly. Which just leaves me the question of why a Canonical employee who works on snap can’t create a good snap package.
There’s also the weird fact that Ubuntu dropped the ball with its core24 runtime. For some reason, Canonical’s own snaps stuck to core22 up until this month. Like, why wouldn’t they upgrade to their latest runtime? If there was an issue with it, why has it been broken for 2 years? Doesn’t inspire trust.
View full thread on lemmy.world
14
0
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
I can understand MIT being an issue in some cases. For example, VSCode is a proprietary fork of the MIT open-source Code. If Microsoft wanted, they could stop publishing the MIT open source version. Of course that code would still exist as MIT, but development would slow down without Microsoft.
But I don't see uutils being MIT as an issue. It's primary goal is to be compatible with GNU coreutils. You can't really rug pull a project with a goal like that. And permissively licensed utils have been around thanks to BSD and it's never been an issue. You don't see companies like Apple using proprietary forked versions as benefit. The "value" they add is higher up the tech stack with their own truly proprietary stuff or open stuff that encourages lock-in to its ecosystem, like Swift.
View full thread on lemmy.world
7
1
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
Snap as a technology is so interesting and more versatile than other formats. It’s just unfortunate that Canonical is in charge of the project, they’ve made some baffling decisions and continue to shoot themselves in the foot.
View full thread on lemmy.world
11
4
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
What’s new in security for Ubuntu 26.04 LTS?
Highlights
Rust rewrite of GNU coreutils and sudo-rs
TPM-backed Full Disk Encryption now considered stable
More secure services (don’t run as root if not needed, AppArmor profiles)
AppArmor prompting for snaps is still experiemental unfortunately
View on lemmy.world
48
14
1
Nobody
@nobody_1677@lemmy.world
lemmy.world
Flatpak 1.16.4 Brings Important Security Fixes For Sandbox Escape & Deleting Host Files
Flatpak 1.16.4 Brings Important Security Fixes For Sandbox Escape & Deleting Host Files
View on lemmy.world
66
2
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
Libinput Hit By Security Issues With Its Lua Plug-In System
16
1
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
It certainly has it’s issues. Takes up quite a bit of space since each app tends ships its own copy of electron (though distros like Arch do try to make apps share a single Electron build). Apps may ship out of date versions that may have security vulnerabilities, though it’s not always the end of the world since they tend not to access outside of their own domains. As for slowness and resource usages, it’s bit of a tricky subject; an Electron app can be optimized, but will always use quite a bit of RAM.
Though undeniably they have been beneficial for Linux if only because it allows some companies to support Linux without too much extra work.
View full thread on lemmy.world
0
0
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
I see two options.
The simpler of which is to have a wrapper script that says HOME=/custom/path/for/appimage. Apps that correctly follow xdg-specs will then put all their data in that path. But not all apps will. Apps that put stuff in /home/$USER will not use the correct location.
The more foolproof way would be using something like bubblewrap, which is used by flatpak. With bubblewrap, the sandboxing can make /home/$USER appear as /custom/path/for/appimage. However, this would take more work to setup, since I presume you want the appimages to feel unsandboxed.
View full thread on lemmy.world
0
0
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
Packagekit mainly.
It also helps if you just focus on a single package format. The Snap Store's performance is great, though I have seen some baffling QA issues with it (like categories showing up like "Devel..."). There's also that store that Universal Blue is pushing, forget what it's called.
View full thread on lemmy.world
5
2
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
It doesn’t work better or worse on Ubuntu. The fact it (partially) uses Ubuntu libraries matters very little given that the libraries are 14 years old… But I think the client now mostly relies on Debian 12 libraries to run since a year or two ago.
In this case, the DE is the main cause of issue, not the distro base.
View full thread on lemmy.world
0
0
0
Nobody
@nobody_1677@lemmy.world
lemmy.world
That was a combination of the Steam client being a piece of trash (incredible complexity and technical debt*) and COSMIC. COSMIC is quite buggy when it comes to Xwayland. I’ve had plenty of issues where I close a Xwayland window, but a ghost of the window remains.
the Steam Client runs on a combination of Ubuntu 12.04 LTS and Debian 12 libraries. It has a combination of their old VGUI code and newer Chromium GUI. It remains 32-bit and only supports X11.
View full thread on lemmy.world
0
7
0