It’s more important to make the swap in the first place than it is to pick the right distro, unless you dive straight into LFS or Gentoo or something. You’ll eventually find what you want and can swap easily enough, or you’ll find that you’re happy with what you have!
Indeed it won’t modify rar archives. What do you need those for?
The typical flow for rar archives is to unpack them and then either leave the files on disk as plain files or put them into a better archive format such as 7z.
My initial goal (before learning what a headache rar is) was to preserve the original file format. Now my plan is to convert them. I have to confer with my friend to see what format they’d prefer for the files. Probably end up using regular old zip.
X is old and works for the most part but fixing stuff or adding features is hard.
Wayland is new and is supposed to be a successor to X, do what it couldn’t do and don’t repeat the mistakes from it. It should be a drop-in replacement like pipewire but isn’t. Features take long time to develop as devs are engrossed thinking of the best solution to make it happen. A lot of proposed solutions are dismissed as well.
I think the drama around Wayland can be explained by the sentence “it should be a drop-in replacement like pipewire but isn’t”.
Without taking a side on that issue, I will point out that this was not a goal for the Wayland designers ( in their own words - I do not have time to go find a quote but have read this sentiment many times ). Wayland detractors agree with your sentence and, given that expectation, are legitimately upset and even confused that Wayland continues to gain mind and market share against X11.
If you feel that Wayland needs to be a drop-in replacement for X11, it is not ready and may never be. By that metric, some people see Wayland as a failed technology and perceive Wayland users as shills and zealots.
If you are interested in a display server that addresses some of the core design problems in X11 and do not mind moving to something new, Wayland is starting to look ready for prime-time.
If you are non-technical and / or unopinionated the debate is probably irrelevant. Wayland will most likely become the default on whatever Linux distribution you use sometime in 2024 or 2025. You will be a Wayland user. Maybe you already are.
If you are willing to step outside the mainstream, using X11 without Wayland is going to be possible for at least another decade. That said, I am saying “outside the mainstream” because not only will popular Linux distributions and desktop environments start to become Wayland only but the innovation is all going to move to Wayland. There will be many Wayland-only compositors, apps, and features. 5 years from now, not using Wayland is going to really limit the desktop experience. I expect some toolkits ( GTK, Qt, and maybe even WINE ) to drop X11 support at some point ( maybe not soon but sooner than 10 years maybe ). 5 - 10 years may seem like a long time but it will likely come faster than X11 stalwarts expect.
You could give this a try instead. It’s a reverse engineered iCue driver which probably supports your keyboard and any other Corsair peripherals you may have.
Well, that’s unfortunate. I have all razer peripherals that work great with openrazer for a back end and polychromatic for a gui front end. I don’t have any corsair devices anymore so I can be much help. Good luck.
My situation is remarkably similar to yours down to the language, and I happen to have been considering a US keyboard as well so that’s disheartening to hear. I have nothing to add right now but will let you know if I come across anything helpful!
I love US keyboards for coding, it really improves the experience. Typing in portuguese, however, is not a good experience. The default american layout has the ~ key in a really bad spot. Typing à or ã is REALLY uncomfortable/weird. Fortunately, my keyboard has that key on the right side of the keyboard instead of the left, which greatly improves the experience.
The .XCompose file I linked in the main post is perfect and works great on X11. If you’re not yet on Wayland you can use it and have a great experience.
Right, that all makes sense. I’ll definitely keep that .XCompose file in mind, wasn’t aware it even was a thing before your post. Also, do you mind sharing the specific keyboard you’re using for reference?
Side note, I’ve started using vim/helix a few months ago and the pt layout makes things a lot more awkward than I expected, that’s half the reason I’m considering a US keyboard lol
I’m using an Happy Hacking Keyboard Professional 2. Not most people’s cup of tea but I’ve grown used to it and it’s hard for me to swap to anything else now :P
I can see why it’d be divisive with topre keys, no key markings and a pretty non standard layout but man does it look nice. Really appreciate what they’re going for there.
Anyway, thanks and hope you find a solution, I’ll drop by if I come across anything useful!
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.
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.
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.
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.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.