Kitty for both X and Wayland - I like the customization (as in I already have the config file that I have backed up and can just plop it in), it works perfectly on any VM (used it on sway, hyprland, i3, awesomewm), though honestly I don’t see much of a difference between the terminal emulators. There’s literally no wrong choice or meaningful difference in my experience at least, but admittedly I just use a terminal emulator to run commands, neovim and system file editing.
Yeah same here, at some point I ended up settling on Kitty and now I’m used to it and there’s no reason to change, but pretty much any terminal emulator will do the job just fine.
The fact that I don’t have to deal with lib32-gst-plugins-ugly/bad/ect is amazing, but I’ll have to keep 32 bit libraries for Team Fortress 2 and other online Source games.
Use openSUSE Tumbleweed. It’s a rolling release distribution with the best a great KDE Plasma implementation.
Now, your specific question boils down to choosing between Arch and Fedora, since, arguably, Endeavour OS is actually Arch Linux. Now, as you’re willing to use a Qt-based DE, specifically Plasma, I’d say none of your options are ideal. That’s why I mentioned openSUSE Tumbleweed, but, for you, I’d say Arch Linux, however, you currently use Arch Linux, hence, you should just switch to the Plasma DE.
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.
How about this then. While your neighbors are using wine, it attracts more commercial attention to develop the open source projects that you do actually use. It’s so impactful that you measurably benefit directly from its contributions, like optimizations to the Linux kernel.
You don’t have to agree with it, but you cannot deny the increased investment in open source projects it causes.
For a painfully blatant example see: Steam Deck.
Also for the binary blob purists, how do you feel about all that closed source firmware underpinning your pure world? Isn’t it practically impossible to get completely open source firmware down to the silicon? And even then, do you trust the silicon? Are you running everything on FPGAs?
Hi! “Binary blob purist” here! Yes, it bothers us that so much firmware is proprietary, but we are working to fix that :).
It is possible to have fully free firmware on certain select devices.
The silicon is unchangeable, much like a chair is unchangeable. So being concerned about changing it isn’t really productive. But, RISCV looks promising and a good remedy to the issue of not knowing what it does.
FPGAs would be nice but they aren’t powerful enough yet.
But, at the same time, unless the silicon can make outside connections itself or modify behaviour (a la Intel ME), or has been updated with what is essentially software baked into it that can change it’s behaviour on the fly, I’d say it can be trusted to do the computing you tell it to do and nothing more (again, excluding those processors where we know that it doesn’t like those with the ME).
You don’t have to clean your ~/.cache every now and then. You have to figure out which program eats so much space there, ensure that it is not misconfigured and file a bugreport.
<span style="color:#323232;">% du -sh ~/.cache
</span><span style="color:#323232;">1,6G /home/bizdelnick/.cache
</span>
I don’t remember if I ever cleaned it up. Probably a couple years ago when I moved my old HDD to new PC with freshly installed OS. It does not grow accidentally. Only in some very rare cases. As well as some other dirs under ~ and var. If it is a critical system, set up monitoring of free filesystem space. If not, you will notice if it becomes full (I can’t remember when this happened to me last time, maybe ~15 years ago when some log file started to grow because of endless error messages).
Because some users experienced accidential grows like OP had 160 Gbyte. So general advice for linux users can be stated as: Check your ~/.cache every now and then
Critical systems/servers shall better be monitored as you suggest.
Some users experienced accidential growth of /var/log. Some users experienced accidential growth of /var/cache. Some users experienced accidential growth of /var/lib. Some users experienced accidential growth of ~/.xsession-errors. Shall I continue?
Does every user need to begin his day checking all that places? No, he does not. It is waste of time. Such situations are extremely rare. If you are paranoid, check df to see if you have enough free space, and only if it unpredictably shrinked begin to ivestigate which directory has grown.
I don’t get your point. Why should somebody do this every day?
As the experience from other users in this thread, it seems not extremely rare to have an overgrown ~/.cache/ folder. So checking it from time to time is a good advice. If we all do this for a time, and create bug tickets for software which is not cleaning up. Then this problem will hopefully go away with future software releases.
I worked with mosh for years to connect to servers on other continents. It was impossible to work otherwise. It only has two small warts: forwarding, and jump hosts.
The second is fixable/ish with an overlay network, but that isn’t always an option if you don’t control the network. I tried to solve this with socat but wasn’t able to configure it correctly - something about the socket reuse flag was very unhappy.
Yeah. I spend a majority of my working time on a slightly-unreliable Wifi network, and getting irritated that my keystrokes are lagging by some seconds and making it hard to e.g., edit the line I'm editing, is a daily occurrence. I literally had never heard of mosh before today, and when I tried it it was like the heavens opened up.
I still remember the professor in my networks class explaining how TCP worked, and then saying more or less:
Why doesn't it send a detailed mapping of which sections of the stream have been received and which haven't, allowing retransmission of only the dropped packets instead of what it does which is just backing up and blasting a whole new window's worth every time a single packet is dropped? Well, I don't know. It'd be a little more complex but the improvement in functionality would be so obviously worth it that it should. Don't know what to tell you. Anyway, this is how it works...
Fedora is indeed a pretty solid option its very stable and you are still up to date when it comes to packages.
One distro that I personally use and I’m going to shill is void. Its bleeding edge but its surprisingly stable. If you don’t mind reading documentation and researching similarly to arch you shouldn’t have a problem (since you are accustomed to endeavourOS).
I absolutely love void. Second to that I would say endeavour, it’s just arch with zfs, a wm and an installer.
If you’re interested in learning more try , I use oddlama’s installer. With binary packages, distrobox and flatpak, the small amount of compile time is a much smaller issue.
Alternatively, if you’re thinking about Fedora maybe play with Silverblue, it forces you to learn a bit of containerisation which is handy
So the “terminal” is the basic CLI that you use in the single-user, text-based mode. Terminal emulators are graphical programs that run in multi-user, graphics-based mode, and they hook into the terminal and allow you to access it inside graphical sessions. Some examples would be alacritty, kitty, urxvt, konsole, or terminator
Every “terminal app” is a terminal emulator, because non-emulated terminals are physical pieces of hardware.
So you are already using a terminal emulator, I’d guess Gnome Terminal, and it’s a fairly full featured modern terminal emulator (in my opinion at least).
That’s exactly what they are, but instead of connecting to a VAX at the other end of a modem they talk to a shell attached to a pseudo terminal device on the same machine.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.