In windows, save the recovery key (to an external USB key for instance), it is a text file. Then in Linux double click the partition in Thunar or your file manager and it will ask you for the key.
At 80 I would urge you to consider wired again or save up. Otherwise I would look for the cheapest amazon / ali headset you can find a decent review online (off amazon) for.
I’ve been using Wayland daily for a few years (2020 at least?) on intel and AMD graphics and have had few complaints:
Some games didn’t work right a few years ago. (Under Proton or otherwise. Haven’t had issues for a while)
RenderDoc, a vital bit of graphics debugging software, works poorly on Wayland. (Easy fix is to force X11 for QT via QT_QPA_PLATFORM=xcb)
Had some issues with mixed integrated/NVidia graphics on a laptop I was using for a demo once.
Covering or otherwise hiding a Wayland window blocks a program’s graphics thread. This is sometimes problematic.
VR development had issues a while ago? (This was for work. It just… stopped working at some point. Dunno if it was a Linux, SteamVR, or Unity3D issue. My work machine mostly runs Windows 10 now as a result. Oh well.)
Screen recording didn’t work well a while ago… (continued)
Overall, it’s just worked great though!
My anti-complaints:
Mixed refresh rates on monitors “just works” now. (I have a 1080@144 for gaming, and a 4k@60 for work)
Video frames don’t have half drawn content. (ex: when resizing windows), except on XWayland stuff
Video tearing has basically disappeared.
Video timing issues seem to be improved.
Input handling for keyboard layouts has improved.
Screen recording in Wayland is way better than it ever was on X11 now. I do this a lot to share gamedev stuff I’m working on.
“that thing you used to do is now impossible to do consistently across different implementations, if at all. But it’s all ok, because we have decided it’s not our responsibility!”
That is not what users want to hear. From a user’s point of view, it is broken.
I see what you’re getting at. It’s a matter of perspective, I guess.
If you presented someone with a list of features from two similar but different pieces of software, they wouldn’t say software b is broken because it’s featureset is different from software a, right? But I acknowledge it’s not that straightforward. It’s more like telling them software b is going to replace software a that you’re currently using, get ready to say goodbye to some features.
I still don’t consider wayland broken, but I understand argument that it is.
yes, if i combare kicad with blender, neither is broken because they have different features. But also, nobody is telling users that kicad’s days are over and it should be replaced by blender. If they did, and a user wanted to design a circuit board, the user is out of luck. The user is told that it is a replacement. From the user’s point of view it most definitely is not.
The probeem isn’t just that wayland doesn’t do everything x does. But that users are told that it will replace x, deal with it and quit complaining.
We have to keep in mind that the fact that we know what wayland is in the first place puts us squarely into the “technical user” category, not regular users. Regular users are the ones who don’t even know (nor should they have to care) what wayland even is
I will conveniently avoid any dbus talk, because the why is not so interesting as the how and direct you to this path /var/run/wpa_supplicant. You would probably send SCAN_RESULTS on the socket, you could also initiate a SCAN first to include the strength of stations you’re not connected to. If you want deeper access to wireless, you use netlink to communicate with the kernel (see /usr/include/linux/nl80211.h) and poke some NL80211_STA_INFOs… or the other direction (everything is a file) you just parse /proc/net/wireless without any special permissions for the current signal strength.
Oh… and btw dbus has a simple binary protocol underneath all the XML/interface fluff and uses a UNIX socket.
Yes, of course, the sockets are the answer to everything (and BTW, d-bus uses sockets as well, e.g. /run/dbus/system_bus_socket on my current system), but the problem is no standard for the communication over these sockets (or where is the socket located). For example, X11 developed one system of communicating over their socket, but it was used just by few X11 programs, and everybody else had their other system of communication. And even if an app found some socket, there was absolutely no standard how exactly should programs communicate over it. How to send more than just plain ASCII strings? Each program had to write their own serialization/deserialization code, their own format for marshalling binary data, etc. Now there is just one standard for those protocols, and even libraries with the standard (and well tested) code for it.
Not vim necessarily, but I would really suggest thinking about a plain text editor of your choice and some of those lightweight markup languages (Markdown itself, reStructuredText, ASCIIDoc … I prefer rST, but they are mostly the same). Exactly because it allows me to concentrate on the content and ignore formatting. Besides, formatting, do you write for print or as everybody else these days for HTML? Why do you need a large word processor which is build primarily for preparing documents for print? Every serious text editor has some kind of plugins with spellcheckers, grammar checkers, dictionaries, etc.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.