I had this problem with flatpaks, I changed the dbus implementation to dbus-broker (in endeavouros) and it fixed the issue. It may be the same problem.
I installed dbus-broker and the package manager checked the dependencies and removed the unnecessary stuff. After that I applied the dbus-broker services:
Yes, I remember reading about a gtk thing that interacts with flatpak, they said it should not give this error in April, but it seems to still be happening, idk.
Edit: I just saw that you deleted the gtk portal and it worked! So no need to install another dbus daemon.
alright edit: I have a Flatpak issue, not an SSD issue. does anyone have any thoughts? this could be due to the new linux mint update. my pc is a samsung galaxy s2 (750XED P13CFG)
the linux mint discussion forum has a post about my model not being great but last update my system worked just fine. i actually think having a full ssd broke flatpak. otherwise ive hit a horrible regression issue github.com/orgs/linuxmint/discussions/277
SSD’s dont work like old HD’s depending on the generation of tech it might be storing multiple values per cell which means when you “filled” the SSD you put a charge into every single storage cell on the drive.
Garbage collection and TRIM will slowly over time clear out all the cells flagged as deleted but if one bit is still valid in a cell that was holding 3-4 other bits it cant overwrite that, or relocate it.
That means that your files/videos and such stay fragmented and may never get put back together sequentially or in a way that the controller can optimize again for speed.
The only fix, may be running a factory wipe from the Drive MFG’s tool set, that should fully blank each cell and let you re-install and make it feel fresh again.
Be warned though, you have already done a full drive write once at least, this would be another. You can expect some dead cells and while there is over provisioning that should provide replacements you could see a loss in usable space sooner than later.
If you prefer a graphical tool, you can do the same thing with GNOME Disks, which also has options for disk benchmarking.
In the resulting report, the overall health state should be “PASSED”, the “Type” column should show “Pre-fail” and “Old age” values, and the “Media-Wearout-Indicator” should be close to 100. If the overall health state is “FAILED”, then you will want to back up your files immediately and consider getting a new SSD.
Not specifically. It’s probably actually a configuration problem though, for any other program I’d delete or default the settings. Not sure how to do that for flatpak itself as I won’t use it.
Definitely flatpak related then. Try running one of your flatpak apps from the terminal, and post the output here; might help pinpoint the issue. You can list the ones you have installed with flatpak list, then flatpak run <one of the listed apps, e.g. org.videolan.vlc>.
it took 30 seconds but this got outputted and then the file ran: dave@dog: ~$ flatpak run org.x.Warpinator Gtx-Message: 14:29:03.389: Failed to load module “xapp-gtk3-module” Using landlock for incoming file isolation
Now I’m gonna tell you what nobody talks about when moving to Linux:
Proprietary/non-Linux apps provide good features, support and have tons of hours of dev time and continuous updates that the FOSS alternatives can’t just match.
The difference is that there’s a lot of commercial support when it comes to supporting Linux servers due to many reasons, when it comes to the desktop it simply isn’t there.
If you require “professional” software such as MS Office, Adobe Apps, Autodesk, NI Circuit Design and whatnot Linux isn’t a viable options. The alternatives wont cut it if you require serious collaboration… virtualization, emulation (wine) may work but won’t be nice. Going for Linux kinda adds the same pains of going macOS but 10x. Once you open the virtualization door your productivity suffers greatly, your CPU/RAM requirements are higher and suddenly you’ve to deal with issues in two operating systems instead of just one. And… let’s face it, nothing with GPU acceleration will ever run decently unless big companies start fixing things - GPU passthroughs and getting video back into the main system are a pain and add delays.
To make things worse the Linux desktop development ecosystem is essentially non existent. The success of Windows and macOS is the fact that they provide solid and stable APIs and development tools that “make it easy” to develop for those platforms and Linux is very bad at that. The major pieces of Linux are constantly and ever changing requiring large and frequent re-works of apps. There aren’t distribution “sponsored” IDEs (like Visual Studio or Xcode), userland API documentation, frameworks etc.
Run a full memtest on your RAM. Very likely you may have developed a few bad areas. Take pics if it finds bad zones, you can use the addresses to tell the kernel to avoid them.
Large parts of the rewrite came from contributors who had never worked on fish before.
That’s pretty useful alone.
And there’s this:
Thread Safety
Allowing background functions and concurrent functions has been a goal for many years. I have been nursing a long-lived branch which allows full threaded execution. But though the changes are small, I have been reluctant to propose them, because they will make reasoning about the shell internals too complex: it is difficult in C++ to check and enforce what crosses thread boundaries.
This is Rust’s bread and butter: we will encode thread requirements into our types, making it explicit and compiler-checked, via Send and Sync. Rust will allow turning on concurrent mode in a safe way, with a manageable increase in complexity, finally enabling this feature.
Vibes are just as important to free/open source software as proprietary software and although there were solid technical reasons for the port, the PR outcomes are added benefits.
Seems one of the main reasons is to use Rust’s thread safety to enable “concurrent mode”. Anyone with the knowledge able to explain what advantages that would yield for an end fish user?
will have to wait for the first while loop to complete, which takes 0.5s, and then run the second.
So it takes 0.5s until you get the first output and a full second until you get all of it.
Making this concurrent means you get the first line immediately and all of it in 0.5s.
While this is an egregious example, it makes all builtin | builtin pipelines slower.
Other shells solve this via subshells - they fork off a process for the middle part of the pipeline at least. That has some downsides in that it’s annoyingly leaky - you can’t set variables or create a background job in those sections and then wait for them outside, because it’s a new process and so the outer shell never sees them.
While I agree, most people shouldn’t have to be concerned with it, you can’t deny the resource impacts of various languages, libraries and frameworks, like compare the memory usage of Discord or Teams with those of FOSS chat applications, and you’ll notice those two consistently eating much more memory. You can also compare compute speeds of a higher level language like Python vs lower level languages like Rust and you’ll find that Rust is quite a bit faster (though generally takes more dev time). So yes, users shouldn’t have to be concerned with involved languages, but if you’re running something on a low-resource device, such as a Raspberry Pi, those little details can make all the difference.
PL can have a large impact on features, bugs, bug reports, troubleshooting, performance and documentation. Particularly when dev resources are limited.
It’s hard to see how this opinion holds any water.
Rust is a great choice for a shell built as an interactive shell that doesn’t have to be core to the OS. Over C++ this also makes development more accessible to young programmers.
I’m using GNOME Wayland on Fedora 39 and I don’t have the problem you describe. I just go to settings and select my keyboard layouts:
English (US, intl., with dead keys)
English (intl., with AltGr dead keys)
And everything just works. I specially like the second one because it doesn’t interfere with keybindings in games, which can be a problem in GNOME Wayland.
Oh, I think I get the issue you’re having, you can’t find the Çç character on the Linux layout 😅 I always have to explain this to people migrating from Windows, it’s AltGr+, (right Alt key plus Comma). I like this shortcut better than the Windows layout, but I understand some people might not like it. Unfortunately, I can’t answer your question, as I too don’t know how to customize the keyboard layout. I just got used to the Linux layout.
You should be able to type ç the way I described for all apps, so you could just remove your custom layout. I highly recommend the English (intl., with AltGr dead keys) layout, it’s perfect for coding and writing in English. It’s a bit more work to write in Portuguese, though, so it took me a while to get used to it, but it’s worth it if coding is what you’re doing most of the time. In this layout, you must hold AltGr to get the dead keys, otherwise it’s a normal English layout.
You can also use two layouts — one for English/coding, one for Portuguese — and the keyboard shortcut Super+Space to switch between them. I always have two layouts setup like this, but I never switch anymore because I just learned to love the English (intl., with AltGr dead keys) layout — and I don’t write much Portuguese nowadays.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.