Are we reading the same article?
You assume they've read the article 😬
Wayland is trash and the fact that we are fourteen years into its life (YES, FOURTEEN) and still can't get it working right is a good indication that we need to abandon it.
lol, I don't get why people keep using this argument...
All of these developers, companies, toolkits, DEs and various other projects have decided that it's easier to literally rewrite the entire Linux desktop than to continue hacking Xorg.
In fact they don't want to touch Xorg so much that they're willing to spend 14 years (and counting) replacing it.
And you see this as indication that Wayland is trash?
Yes, you can. Seriously, people act like Xorg is some immutable black box no one can touch. IT'S FREE (AS IN FREEDOM) SOFTWARE. FIX IT.
Go right ahead. Start by adding per monitor refresh rate.
There's a bug open for Firefox and you can change VSCode's behavior by putting this in your keybindings.json:
{
"key": "shift+insert",
"command": "editor.action.selectionClipboardPaste",
"when": "textInputFocus && !editorReadonly"
}
Not sure why either of them are messing with a "standard" shortcut...
If you want a more system-wide solution there are utilities that let you sync the PRIMARY (on selection) and CLIPBOARD (Ctrl+c) buffers mentioned in the Arch Wiki entry.
Yeah no way, the 90s were something like 10 years ago and... wait now we're in...
Ohh... Ohh no...
- "Screensaver" isn't a feature of X - it's functionality provided by XScreenSaver which uses X mechanisms to detect user inactivity, lock the screen and display an animation.
Equivalent mechanisms exist in Wayland, but XScreenSaver doesn't have logic to interact with them. This can be solved by either teaching XScreenSaver how to talk to these new mechanisms (difficult as it was developed for X from the ground up) or implementing something new. - Network transparency already exists (and has for some time) in the form of waypipe.
- xset isn't a feature of X - it's a utility to control it. Since Wayland compositors aren't X, it makes sense for them to be controlled differently.
Right so just installed xscreensaver - automatic blanking and locking is indeed broken BUT it does display all the pretty animations just fine! (at least on Sway)
Don't really have time to mess around with it but maybe try figuring out which mechanism is used for screen locking in your environment (in Sway's case it's swayidle) and get it to start xscreensaver right before calling the real locker program?
BTW you can get xscreensaver-settings to come up by unsetting the WAYLAND_DISPLAY variable:
env --unset=WAYLAND_DISPLAY xscreensaver-settings
Philosophical BS: I don't think it's correct to say that Wayland doesn't support screen savers, but rather that it doesn't support XScreenSaver, or, more accurately, the mechanisms it uses for screen locking and idle-detection.
As others have pointed out, equivalent functionality has already been implemented and is used by various screen lockers. What appears to be missing is something to take this functionality, and display an animation instead of just locking the screen.
I noticed that all of XScreenSaver's animations are actually separate binaries in /usr/lib/screensaver/ so we basically need a locker that speaks Wayland's locking protocol, but also takes and runs those binaries in full screen mode.
Or maybe XScreenSaver's dev can be convinced to add support once the protocols are stable?
Ads on a computer??
He got his monitor mixed up with a TV screen or something lol
Might sound kinda dumb, but try dumping a bucket of (ice) cold water on your head.
The trick is to dump all the water at once and not gradually to get your body into a "I'm being attacked by lions!" state.
This is for instant relief. For gradual improvement try increasing your daily water intake - set reminders to drink a glass or two during the day and drink right before going to sleep and right after waking up.
Source: inherited migraines from my grandma and started getting them regularly around my teens.
Doing the above has made me nearly migraine-free except for when there's drastic weather changes (when I get them with auras and everything 😵💫).
Good luck!
Maybe rebuilding the ramdisk failed during the original upgrade?
One of the post-install stages after upgrading the kernel is rebuilding the initramfs - a tiny environment for bootstrapping the main OS.
If you trigger it manually with mkinitcpio --allpresets you'll notice it has fancy colorful output, with clearly visible warnings/errors.
However when invoked as part of an upgrade this coloring is removed, making errors difficult to spot.
I had this stage randomly fail a few times, resulting in an unbootable system like you described - solution was to just trigger a manual rebuild or reinstall the kernel with pacman -U.
It's possible that this is what actually fixed things when you downgraded the kernel.
feral_hedgehog
joined 1 year ago
Correct ^_^
Tank was likely captured in Egypt in the 50s or 60s, and transported to a military workshop next to the city - probably to study Soviet armour.
Years later the city was expanding, so they decided to move the base someplace else and someone decided to just burry the thing instead of transporting it again.
At least, that's the official, "logical" explanation that we got that conveniently ignores the possibility of secret Soviet space-time travel experiments!