No, we have been making our own platform toolkit (libcosmic), which is built upon iced-rs. We are using this both for our wayland compositor applets, and our desktop applications.
iced? Interesting. I though it’s still pretty experimental. There’s no official documentation yet, right? When I was looking at Rust UI libraries Yew and Leptos looked more mature. I guess you’re confident iced have enough backing and isn’t going anywhere.
How do you find working in Rust on a bigger UI project? Any issues?
Iced is a lower level GUI library, similar to what GDK is to GTK. We built our own COSMIC-themed GUI toolkit around iced, which is called libcosmic. As we’ve gotten more and more widgets and application logic developed, actual application development with libcosmic is a breeze. Even if you do have to create a custom widget, it’s much easier to creating custom widgets in GTK. We’re able to develop much faster than we ever could with GTK now.
Yew and Leptos aren’t comparable since they’re not native GUI toolkits. These are for web developers rather than application development. It wouldn’t be possible to use this for developing layer shell applets for COSMIC, either.
Why develop libcosmic around iced instead of going with something else modern that’s easy to develop in such as Flutter? Iced/libcosmic is probably a bit more efficient resource-wise but that probably wasn’t a huge point.
That would compromise our vision of a GUI platform built from the ground up in Rust. It would also not be feasible to use Flutter for applet development. We can easily make modifications directly to iced for all the Wayland integrations that we need in COSMIC, as the iced code base is very lean, and written in Rust.
Got it. So being written in Rust is one of the requirements. Makes sense. Flutter is great for self-contained applications but we can definitely use another sane native toolkit besides Qt that has wider applicability.
This sounds really cool. I don’t see any documentation for libcosmic. Are you planning to promote it as an alternative toolkit for building desktop apps or do you see it more as an internal tool strictly for COSMIC DE development?
What’s the accessibility story for blind users for example?
Is it going to be suitable to use with proper bindings with other languages or it’s not an interest at this time or are there plans to support things like that and stability of apis, etc?
You can generate documentation by running cargo doc and browsing the generated web pages in target/doc. There are also examples in the examples directory of libcosmic, as well as a design demo example which is a WIP.
libcosmic is an alternative toolkit for building desktop applications and layer shell applets. It wouldn’t make much sense to build a toolkit only for ourselves. It’s the best way to develop layer shell applets for COSMIC, and other Wayland compositors that support the layer shell protocol.
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.
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:
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
had issues with Remmima and Win 10 last week - worked around it by using xfreerdp directly at the command line. this is what I use from a linux command line to set the resolution and sound (audio-mode:1 is same as Remmima local sound, or supposed to be)
this keeps all audio local on the system, which is what I need.
Remmima was working fine until I messed with the settings to see if I could have both local and remote audio with RDP (you can’t) and then I could not get the local audio back no matter what I did - tried deleting profile, reinstalling, etc. Nothing worked until invoking xfreerdp directly. Been flawless since then.
Applications needs some coordination between each other in order to act like you would expect - things like one window at a time having focus and thus getting all keyboard and mouse inputs. As well as things like positioning on the screen and which screen to render to, the clipboard, and various others things.
X is a server and set of protocols that applications can implement to allow all this behaviour. X11 is the 11th version of the server and protocols. But X was also first created in 1984, and X11 since around 1987. Small changes have been made to X11 over the years but the last was in 2012.
Which makes it a very old protocol - and one which is showing its age. Advances in hardware since then and the way we use devices have left a lot to be desired in the protocol and while it has adapted a bit to keep up with modern tech it has not done so in the best of ways. I also believe its codebase is quite complex and hard to work with so changes are hard to do.
Thus is has quite a lot of limitations that modern systems are rubbing up against - for instance it does not really support multi cursors or input that is not a mouse and keyboard. So things like touch screens or pen/tablets tend to emulate a mouse and thus affect the only pointer X has. It is also not great at touchpads and things like touch pad gestures - while they do work, they are often clunky or not as flexible as some applications need.
It is also very insecure and has no real security measures in place - any GUI application has far more access to the system and input then it really requires. For instance; any application can screen grab the screen at any point in time - not something you really want when you have a banking web page open.
Wayland is basically a new set of protocols that takes more modern hardware and security practices in mind. It does the same fundamental job as X11, but without the same limitations X11 has and to fix a lot of the security issues with X.
One big difference with X though is that Wayland is just a protocol, and not a protocol and server like X. Instead it shifts the responsibilities of the X server into the window manager/compositor (which used to manage window placement and window borders as well as global effects such as any animations or transparency). It also has better controls over things like screen grabs so not every application can just grab a screen shot at once or register global shortcut keys or various things like that. Which for a while was a problem as screen sharing applications or even screenshot tools did not work - but over time these limitations have been added back in more secure ways than how X11 did them.
Additionally any application using a GUI toolkit (like kde, qt or gtk etc) only needs to to update to a version that has native Wayland support. Which means most applications already support it. At least if they don’t use any X11 APIs directly (which is not that common).
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
So many content? You mean so many levels? While searching for the current download link for Debian 12, I really just couldn’t find the right one I think, so I just went for one which had amd64 and gnome in the title. It was for a CDROM, but I flashed that onto some USB.
The risk of running into this stuff is exactly why I have timeshift take a BTRFS snapshot before upgrading between versions.
First, double check all of your /etc/sources.list and /etc/sources.list.d files to make sure they point to the right versions, and then run the update + (dust) upgrade again. There’s a chance you have an external dependency that’s keeping some packages locked to an old version or something like that.
If all else fails, sudo aptitude reinstall ‘~i’ will reinstall every package on your system. It’ll prompt you to replace tons of updated configuration files, so maybe make a backup of /etc just in case. You may need to install aptitude first (it’s in the normal Debian repos).
If that fails: copy /etc and your home directory to an external drive, dump all installed Debian packages to a file, reinstall Debian, restore the package list from that file, and copy back your config. This would also be an opportunity to make any low level changes to your system (i.e. upgrading the security of your LUKS header, maybe setting up a filesystem with snapshotting, fixing any partitioning mistakes you may have made over the years).
Aptitude allows you to do this in a one-liner, without spawning apt over and over again. Plus, its conflict resolution options still beat apt’s “there’s a conflict, so you can either remove 95% of your system or you don’t install anything at all” approach.
I don’t have any sources files in my /etc directory. My Debian install in general is really weird, since the default apt sources came only with some CD ROM source, which did not work with the Internet. So I had to manually add all sources myself (probably caused some of my troubles…) These are my sources right now
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free non-free-firmware deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
I’m assuming these are correct, as they all got that bookworm in them.
I’m back from trying that reinstall with aptitude, and it keeps getting file sizes wrong. It says, that reinstalling all software will take 0 Bytes. After not finding some sources, it tells me that the unpacked packages will combine to 0 Bytes again:
E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python2-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python2:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »libpython2.7-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »python2.7-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »7.0-5« von »libreadline7:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.2.0-travis995~0f91801+bionic« von »appimagelauncher:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »4.9.2-427« von »blockbench:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »0.0.39« von »discord:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »3.2.1-9« von »libffi6:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »libpython2-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »libpython-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »libpython2.7-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »1.1.1n-0+deb10u6« von »libssl1.1:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »python2.7:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2023.1« von »trenchbroom:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »0.11.4« von »weylus:amd64« herunterzuladen. Nach dem Entpacken werden 0 B zusätzlich belegt sein. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python2-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python2:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »libpython2.7-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »python2.7-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »7.0-5« von »libreadline7:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.2.0-travis995~0f91801+bionic« von »appimagelauncher:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »4.9.2-427« von »blockbench:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »0.0.39« von »discord:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »3.2.1-9« von »libffi6:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »libpython2-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »libpython-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »libpython2.7-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »1.1.1n-0+deb10u6« von »libssl1.1:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »python2.7:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2023.1« von »trenchbroom:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »0.11.4« von »weylus:amd64« herunterzuladen. E: Interner Fehler: Liste der herunterzuladenden Pakete konnte nicht erzeugt werden. E: Perhaps the package lists are out of date, please try ‘aptitude update’ (or equivalent); otherwise some packages or versions are not available from the current repository sources
“Es konnten keine Quellen gefunden werden” meaning, that it couldn’t find the sources for a specific program. I already ran sudo aptitude update so that is not the issue. Soo maybe I really do need to reinstall the entire system?
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.
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.
I use my Yubikeys all the time in OpenSUSE Tumbleweed and Linux Mint - a Yubikey 5 NFC and a Yubikey 5C NFC (mostly with Firefox). I have never had any problems with them. Mint is Ubuntu-based so they ought to work in Ubuntu. Sorry I can’t advise you on why yours isn’t working, but it should definitely be possible to get it working.
Tumbleweed user here. Thinking of buying a yubikey; is it easy to setup for logins etc or does it involve terminal commands etc. I mean is there a repository app?
There’s an appimage for their manager app there. You might also try using Distrobox to give yourself access to a distro that uses apt, and then add Yubico’s PPA and install the software from there. I don’t know whether it would work but in principle it should.
As a last resort you could install docker from apt, build an image from a distro has rar in its arm repos, then run containers ephemerallly, mounting your work dir into the container where rar runs. Try the suggested methods of getting a binary first. 😅
<span style="color:#323232;">docker run --rm -v /your/work/dir:/destination/in/container your_image rar ...
</span>
Haha. Definitely last resort. Having learned what a pain rar is due to its propriety nature, I’m going to see if they care if I convert them to tar or zip first.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.