woops my bad, I mean to link this github.com/…/wayland-x11-compat-protocols it’s a repo of going to be protocols, to fill in the gap instead of pretending the issue doesn’t exist
I did and quite frankly it’s trash, XDG portals are a clunky and quite frankly terrible and poorly thought out api. I’m not the only one that disagrees with this sentiment as multiple people are trying to get protocols like ext-screencopy-v1 for screen recording and ext-foreign-toplevel-* for window management upstreamed into wayland so that xdg portals aren’t necessary for these use cases. I don’t mind the reliance on pipewire too much, but I too think that It shouldn’t be necessary for screen capture.
IMO It is one of nate’s worst takes of all time if not the worst. Usually I agree with most things he writes, but not this, xdg-portals is a travesty, pipewire is nice and all, but I don’t see why we should need an entire media system for basic screen capture capabilities. and clearly im not alone on this sentiment
And that’ll shake out in the time it takes for X11 to go away. I get what you’re saying, although I don’t share your opinion about portals from a user perspective: I’m just happy that Firefox finally uses the Plasma file picker.
I have a couple of issues with portals. One is that we’re putting too much eggs in the basket of something that is designed for containers. XDG portals Have rejected features that people have requested because they don’t want to expose that functionality to a container and they are allergic to permission prompts apparently.
I also have other issues with the portals for instance video capture. It requires you to have a camera portal. It requires you to have a desktop capture portal. It also requires you to have an app to app, video, portal, which doesn’t exist yet. All of these things require pipewire pretty much in most cases, so why can’t we just have a single pipewire portal? It may not scale well in the future, but it doesn’t scale well now anyways. If you want just a generic pipe wire stream, you’re not gonna be able to have it, you’re going to have to conform to one of the standards anyways. For a case in point example, the OBS pull request for Game Scope Capture is the perfect example of this over reliance in XDG portals.
I’m showcasing this just to highlight the fact that the XDG portals are incredibly poorly thought out, and I don’t think that it’s a reliable method for the future going forwards.
PS. Please pardon any oddities in this, I had to use speech to text, since my RSI is acting up.
I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.
I partially agree about the focus on containers/sandboxes. Yes, it makes sense to criticize that something designed for a different use case results in different trade-offs. But on the other hand, are the use cases really that different? We’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?
Otherwise I don’t know enough about the standards to comment there, you’re probably right!
I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.
The idea of a using a separate thing for it is fine, in itself, but necessitating it is an issue to me. There are a LOT of wayland compositors now, for all sorts of systems, each one also new needs a compatible xdg portals implementation (or whatever third party tool you like), in the case of xdg portals this also means pulling in things like dbus. It actually becomes a lot to build a “Minimal but fledged out” ecosystem. something which should otherwise be possible.
we’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?
sure but then you have xdg-portals denying actually useful a11y protocols because they “don’t want to expose it to containers” -_- apparently they never heard of a permissions system? but this also highlights why the wayland ecosystem right now is so poor for select individuals (and why they get heated when told that they need to swap to wayland)
I’ve owned a Thinkpad A485 with touchscreen for years and had several Linux distros on it including Manjaro and Linux Mint which I am currently using.
Never had any issues, touchscreen always works out of the box without me having to do anything extra. In fact, with a few distros, I’ve had issues with certain wireless mice, but my touchscreen always has worked. So I’ve actually had slightly better luck with the laptop touchscreen than some external mice lol.
Now a qualifier: I rarely use the touchscreen, and when I do, it’s always just to click something or scroll on an article or file list. I don’t do any special gestures or fancy touch functions, so I can’t speak to support from that perspective.
I think we may be looking at these wrong. Yes there’s a visible throughput/latency improvement here but what about other factors? Power savings? Cache efficiency? CPU cycles saved for other co-running processes?
These are going to be pretty hard to measure without an x86_64 simulator. So I don’t fault them for not including such benches. But there might be more to the story here.
KDE has been a treat for me after having used Gnome so long, I like both and in fact I still keep Gnome on the laptop, especially for the smooth gestures.
On the desktop I’m keeping KDE as it feels more suited by default, for that I suggest Fedora Kinoite because I honestly can’t ever imagine running a mutable system anymore, unless it is strictly for tinkering and, since it seems you’re looking for something that has to just work, that will be a great fit!
::: ..Now to talk about what hasn't just worked for meI used to experience freezes and crashes, but don’t see them happening anymore (maybe it was my hardware being too new?); containers (mostly distrobox), I don’t know what the heck is happening behind the scenes, but I think I’ve seen my containers breaking for the third or fourth time across updates this year, luckily it’s not a tragedy as you can usually roll back the system temporarily (OSTree rocks!) and/or remake them from snapshots or apply fixes that are mentioned in the issue trackers and whatnot when they pop up, the podman devs and others folks are fast and responsive.
All in all, these being the biggest issues for me, this distro is one of the most rock solid there are!
Seems like Fedora Kinoite is getting several votes. Maybe I’ll give that a go for myself. I also like the idea of Fedora more since they are starting to offer their own Laptops with pretty nice hardware it seems.
The idea of buying new laptops that all just have proper OS support seems, novel.
Yeah, now try adding components to it in order to make it a bit more modern, decent RAM, nvme, I’m at 1900. Pass. But hey, I support them and if I had that kind of money, I’d buy it.
You took the words out of my mouth, that’s what I felt with most, if not all, “Linux laptops” I’ve seen up to now: concept is great, hardware is great, price is, well, greater.
I do hope that everyone that can afford System76, Slimbook, Starlabs, etc. (hey, I’m noticing an unusual pattern here 🤔) will buy from them because I’d love to see both more adoption and makers that can improve Linux as a whole thriving
Be careful with these containerized distros. I would read bit more before jumping into something not standard as of now. In particular, making changes to the root image by installing packages works a lot differently than good old Linux distros.
Otherwise Fedora’s KDE spin is quite good, too. They include a lot of extraneous packages, though.
Ya, but you’re overlaying all that stuff, codecs, nvidia, etc. ublue works out of the box and updates are quicker due to not having to re-overlay everything. It’s just less friction. Also it comes with automatic updates enabled which is really nice (and safe in an immutable, intrinsically rollbackable environment)
Overlaying isn’t bad. It’s kind of what we’ve done the past years anyway.
Does the speed of updates matter in any way? Unless it’s not days, there’s no reason for me to complain update the duration since everything is done in the background.
What’s the difference to the auto update in silverblue?
Ootb fedora doesn’t even have gnome extensions installed. We have to adjust our systems anyway
Personally, I’ve been enjoying uBlue over vanilla Fedora Atomic for what they offer in terms of system management.
To give you a better idea on what I mean; just a month ago an update to Podman caused breakage and people weren’t able to use their containers created with Distrobox/Toolbx^[1]^. Sure; a rollback is accomplished relatively easy and I’m sure some would even be able to fix it themselves. Regardless, every Fedora Atomic user that relied on Podman would have been interrupted to some capacity.
Which, of course, begs the following questions… Isn’t it very inefficient for everyone to fix this issue themselves? Wouldn’t it be easier if somehow Fedora forced some fix upon all of us so that just one entity is burdened instead of all of us? Heck, wouldn’t it be better if Fedora just withhold the update until it’s fixed? Is this perhaps some pipe dream that will never see the light of day? etc…
The interesting part, though, would be how I (a ‘uBlue-user’) didn’t even notice Podman was causing issues in the first place. “How?” you might ask, well… The uBlue devs noticed the issue, applied some magic so that I and many other uBlue users like me just went on with their day like they would otherwise; without being interrupted because Podman just had a bad update. (Did the supposed pipe dream actually already exist in some form or fashion?)
This is just the most recent example of this. But in the last year or so, out of the top of my head, there have been a few more times in which uBlue users didn’t even notice a thing while the others either had to rollback or fix their issues themselves. If you enjoy this interruption and/or are willing to deal with it for the sake of whatever, then please feel to continue to do so. However, I prefer to have a system I can rely on at all times and uBlue offers me just that while remaining very close to vanilla Fedora Atomic.
You won’t have fedoras signatures anymore.
It depends if you have the luxury to rely on them in the first place.
If setting up your workflow (or whatever) requires you to get to the nitty gritty of things and change those parts of the system that strictly speaking isn’t well supported by just rpm-ostree, then -for almost a year now- your best bet would have been to (instead) experiment with (what’s been referred in Fedora’s Wiki as) Ostree Native Containers.
Finally, let’s not forget that uBlue is even endorsed by Fedora (or at least by whoever maintains its documentation). Heck, even the inception of uBlue was due to an interaction between Jorge Castro (one of uBlue’s maintainers) and Colin Walters (one of the masterminds behind the whole rpm-ostree-ecosystem).
P.S. If I hadn’t made it clear, it’s totally fine to continue to rely on Fedora Atomic directly without any interventions from third parties for system management or whatsoever. I just wanted to elaborate why I, personally, prefer to use images provided by uBlue.
So you convinced me, and not being a novice, I didn’t read the install instructions and just went for it. It wrecked my dual boot efi partition. No worries, been there done that before, spent all morning trying to get the eufi shell and grub sorted out. After a few hours of failing, I’m like hey I planned for this, I’ve got a USB recovery for windows, and my actual data is all backed up via syncthing (thanks to this community). Why am I bothering with this nonsense.
Omg… Recovering windows takes foreeeeever. So then I’m reading the kenoite instructions and it calls out that dual booting doesn’t work, here is a suggested partition scheme… Ffs… Anyway for anyone that doesn’t want to waste an entire day on this, rtfm.
FWIW, I’ve put some effort into explaining how a dual boot of Windows 10 and Fedora Atomic (read Silverblue/Kinoite/Sericea etc) can be achieved. While it’s far from exhaustive, it should be fine as long as your specific installation of Fedora Atomic doesn’t require special attention (which happens sometimes with owners of an Nvidia GPU*). After Fedora Atomic is successfully installed, proceed with following the instructions found on the following parts of uBlue’s documentation: here, here and finally pick whichever uBlue image you’d like to install from this list; specific instructions are found directly underneath the text boxes for each individual image, but ensure you’re installing the one with the correct Fedora version (37/38/39/stable/latest etc (which are accessed via tabs)). If you can’t decide on which version you’d like to install, then just go for 39.
Most likely they’re still working they’re just not mapped. If you have xenv (terminal command) installed it’ll show you key presses. If they don’t show up under xenv then they aren’t working or are already being captured by something. Otherwise you’ll want to find a way to map them which is probably dependent on your DE.
Not that I can think of except maybe that whatever program was managing those hotkeys may have changed. If they show up as the wrong thing in xenv then that means your keyboard layout is set incorrectly.
I’ve had a couple touchscreen portables that run Linux. I virtually NEVER use the touchscreen on the traditional notebook style portables, which are an Asus Zenbook from the mid-2010s and a Dell Latitude 7390 from 2017 or so. Both run Debian/XFCE. The desktop environment isn’t really designed for touch interaction, and the screens have pretty low resolution and terrible multitouch support. It works.for the odd button press, or to advance slides during presentations. It’s just not a great experience. Plus, both of those screens smudge like the Devil, and just collect fingerprints & dust.
The third portable is a Lenovo Carbon X1 slate, one of the generations from late 2019. It has a Wacom 3000x3000 touch display built in, and a multifunctional stylus. I run Mint Debian Edition with Cinnamon on that one. Its on Mint 18 or 19, so take the next bit as how it was a couple years ago: the touchscreen experience in Cinnamon is functional but a little.clunky. Touch interaction is responsive, accurate and smooth. Writing with the stylus takes some getting used to, but taking handwritten notes and diagrams in Xjournal or an app called Write was okay. I never got the hang of calling up the on-screen keyboard in fewer than a couple.of taps, but once it was up it worked fine. Its terrible for coding or commandline interactions because the special character layouts were more iThing-like.than Android but it did work, even if slowly.
One thing I did struggle with was screen rotation. I had to download and tweak a script that called some xrdb or xrandr commands when the orientation changed. Kludgy, but it did work and it got the job done.
I imagine newer versins of Cinnamon have improved on all this in the last few years. In fact, I was going to make a project this week of reinstalling that system on the latest LMDE to see if I couldn’t make better use of it now that we’re back in the office a few days a week. I was getting the hang of the digital notepad, and now I kind of miss it.
(Why reinstall? Dumb decisions on my.part when sizing the slices I used for boot and root. Gotta blow it all away to make it right.)
i feel like this would just be better served by having a phone and a camera. a good large camera will continue to be a good camera for years and years past the time the phone is too old to be useful for modern needs. my almost 20 year old DSLR still outperforms my phone camera, and my phone is quite recent.
Most nice modern cameras have either USB, bluetooth, or even wifi connectivity to connect to whatever you want. You could just have a normal phone and a normal camera and just copy the files off via whatever method you prefer.
Excluding some of the smaller point and shoots, which are still more volume than most phones, DSLRs and Mirrorless cameras are way bigger than phones for a reason. It's because that's what it takes to take actual high quality pictures without cheating heavily with processing.
my point is that you might as well just have the phone be separate at that point. instead of having to frankenstein them together just have two devices. also, last i checked the linux experience on a small handheld device is not something you’d want to subject yourself to daily. android is much more what you’d want.
I have an Thinkpad X380 Yoga running stock Fedora with GNOME and it works pretty damn well. The pen works and it recognises the buttons, the auto appearing keyboard works and so does the auto rotate. Basically very few problems at all, I don’t use it all that extensively outside of GIMP though.
Hm ok im not familiar with the 13. Tweaks on the 12 (and i think the 13 too) are needed only for the brightness keys.
Personally i would try a reinstall, as unfortunate as that sounds. Especially since it sounds like its a pretty fresh install.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.