Because it’s not as maintainable as separating them by application or some other separation. Would not want to fill up my bashrc with single-application specific code.
You could break it out into other files if you really got that much going on. But if you really have hundreds or more env vars, maybe you should re-think using env vars at all.
Hard to give a rec without more detail, so I don’t really get it.
It is nice to install much normally harder to install crap, but there are so little trusted devs on there, that i rather not install something than getting it from a untrusted source.
It is nice to play around, but i also switched from Windows to have a more secure platform
Seriously, I realize this every time I have to install something on my server (running AlmaLinux). Now I’ve manually set up a personal LURE repo for some software that I use.
Just replace command in your script with /usr/bin/command or whatever. It’s generally good practice to full path anything run from a script anyway just to remove any unintended environment dependencies.
Good point. But then if both the script and the command have the same filename, it will be important to make sure the script has a higher precedence in the PATH. Adding it to the end of .bashrc should be enough I think.
Switched to Manjaro after running vanilla Arch for several years and haven’t looked back. I appreciate the slightly less bleeding edge updates and extra added stability around it.
Easy installs are probably less of a big deal nowadays after Arch overhauled their installation process.
Is this a use case where you can use dotenv? (folder specific environment variables?)
If it’s not, aliases are the best you can do, or bash functions that are equivalent to them. The thing is that those only run in bash, so if you are expecting to run the commands outside of a shell, you will need to wrap them in bash -c or have a wrapper script.
This is just the broad strokes so if you have any questions please follow up.
That’s a good idea, but it only makes the problem a little better. I still wouldn’t want one large aliases.sh file with environment variables for every application I customized. Would rather have them separate somehow without gobbling up a file
It still blows my mind that with nixos, setting up and continuously renewing an ssl cert is literally just two lines in the config file. I use nixos on my homeserver, thinking about switching my laptop to it too (currently Void linux).
Hmmm never used xubuntu per se, but XFCE already seems like a good option for a low-spec computer. You could probably chip away at the resource usage some more by building your own desktop environment around a bare window manager, but honestly at this point the gain is negligible. If anything, you might want to look into tiling window managers just because they can offer a much more fluid and customizeable desktop experience as opposed to floating WMs. I’m using BSPWM right now, but considering switching to wayland with hyprland or qtile.
As for choice of distro: Not sure if NixOS would run well on your machine – my homeserver is also a pretty low-spec computer (dual-core Intel Atom), and nixos-rebuild switch takes ages to run. Otherwise, go for Debian Testing if you want stability, Void if you want to not have systemd. There’s also Devuan, which is basically Debian without systemd, but iirc it’s not as popular as Void. But honestly if xubuntu works for you, then it’s fine.
Also, some miscellaneous tweaks for improved performance:
IF YOU BOOT FROM A HARD DRIVE REPLACE IT WITH AN SSD! Solid-state drives are pretty cheap nowadays, and the upgrade from hdd to sdd is the single biggest performance improvement you can do for an old laptop
If on x11, disable compositing. On XFCE, there should be an option for it somewhere in the settings. If on a bare window manager, simply don’t install any compositing manager (picom, xcompmgr, etc.). The downside is screen tearing and no proper window transparency, but it does put less strain on the CPU.
Consider looking into a custom linux kernel? I boot linux-tkg on my main laptop and it gives some pretty good performance improvements. But I’m not so sure whether it would translate well to a low-spec system.
Again, not exactly a performance tip, but consider formatting your boot partition as btrfs. Apart from all of the other cool features that you get with BTRFS, transparent file compression can, in some cases, be a win-win-win situation: less disk usage, faster file access, and longer SSD longevity. On low end system tho it may actually be the case that the CPU is the bottleneck as opposed to the disk, so transparent file compression may actually slow things down. Here are the settings I use for btrfs on my laptop (thinkpad with a core i7-5600U, mSATA solid state drive): lazytime,noatime,autodefrag,compress=zstd:3,discard=async,space_cache=v2,ssd. Again, not sure how well these translate to a low-end system, you should do your research.
If your system supports uefi, consider using EFISTUB as opposed to Grub. Much faster boot times. Another option is to add two efi entries: one for EFISTUB (and have that be the default), and a second one for Grub, for when you need to change boot options or boot into recovery mode.
I think you misunderstood. I want to know what requirements you have, that are not met with wezterm. I understand, that some people like different software, but this is a huge github repo for a terminal written with electron. Just confuses me
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.