Debian got me through grad school.
Not the latest and greatest (if you run stable), but if you need the latest e.g. Julia, it’s not too bad to compile it.
Debian got me through grad school.
Not the latest and greatest (if you run stable), but if you need the latest e.g. Julia, it’s not too bad to compile it.
I think the 1st-party device support is a little trickier on Linux than on Windows, which IMHO hampers the widespread adoption of Linux on the desktop.
The reason it’s trickier is that the Linux kernel has no stable API or ABI — which is ultimately a good thing ( https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst ), but for closed source drivers presents a problem.
On my Mac running yabai it sometimes gets into this weird state where the mouse does this as it toggles rapidly back and forth between some windows. No idea what causes it…
On Linux I run i3 which kinda negates the need for the mouse finder since it will move the cursor to the active window.
I guess I didn’t remotely answer you question though!
Is the dotfile overhead of a DE substantially more than any other program? Is there a particular conflict that you’re thinking of?
For a multiuser system it can be great to have multiple DEs or WMs.
I think the advice should be taken to heart here — you’re dealing with a userspace problem but you’re trying to get the kernel to make it all better.
You’ve already mentioned the two big things, compressed RAM and swap; optimizing userspace (or paying for more RAM) may be the only option at some point.
If you want to get creative, is there a reason you can’t use a local computer for some of these services? An old raspberry pi or similar could potentially run some of your services. You could run some containers on your home server and call it a day. Quick search turned up this https://www.linuxserver.io/blog/routing-docker-host-and-container-traffic-through-wireguard
One practical thing I like about Linux is that you can control the GUI/window manager independently of the rest of the system. So I can use i3wm, a tiling window manager, and my interface to the computer will be the same — I can upgrade my computer, I can install a new distro, whatever, and I’ll always have the UI I want.
I have a similar vintage Air, 4GB. I run Debian+i3, though that’s not everyone’s cup of tea. Machine feels quick, except for bloated websites.
ETA: In case you’re not familiar, i3wm is a lightweight, tiling window manager that is very keyboard-driven. I love it, and you might too! But it takes a little getting used to and definitely isn’t a Windows-esque experience.
Looks awesome! I’d put a big emphasis on piping/IO redirection (maybe move it further up the curriculum?). I find this video, when Kernighan explains some basics, just amazing: https://youtu.be/tc4ROCJYbm0?si=3l48F_Ci9FYDkNEi
I’d also maybe move shell script basics up a bit — like the really basic stuff. I think it really hammers home the point that the command line and a script are doing the same thing — telling the computer what to do!
I could be wrong but I thought that there are only two channels (left, right), and that the output device (speakers, headphones) are a separate concept, meaning you can’t have different audio. Similar to most cars — left right are different, but front and back always mirror each other.
Surround sound/multichannel audio sounds like it might be what you want?
I could be wrong about this of course.
I’ve had way more plug-and-play success with USB-serial devices under Linux than Windows. Maybe just me though…
I think an issue is that people tend to think of Linux as meaning “all distributions.” So if something is compatible with X distro version yy.zz, the general idea is “it’s compatible with Linux.” This, in my experience, is one of the things that leads to mandatory command-line usage — it definitely is possible to get it to work under a different flavor of Linux, but it’s not necessarily easy if you’re uncomfortable with a command line.
Another is drivers — if it’s mainlined, it will Just Work, but if it’s not…well, it may work, but you might have to jump through hoops and get busy with the command line.
In short: if you view your distro the same way you view a particular Windows release, then I really don’t think you need the command line for desktop Linux. But you need to accept that some software isn’t “compatible,” in the above, user-friendly sense of the word.
My favorite systemd moment was when my (headless) box hung at boot…because I didn’t have a USB drive plugged in. The drive was listed in fstab, which was never an issue before. But without nofail
, it was suddenly worth stopping the boot process.
I see kernel panics at shutdown most often on Arch-based distros after updating system packages.
When I tried Arch, upgrading kernel would delete the kernel modules of the running kernel — somewhat unimpressive upgrade process.
Yeah, good point — I just copy-paste this from my response to another post where OP wanted tips am migrating to a CLI-centric workflow. Different question from this OP.
First thing I’d do is ditch the GUI file manager: get comfortable with cd, ls, mv, rm, etc.
After that, maybe start with basic text manipulation, like grep, awk, sort, uniq, etc. This ties in nicely with IO redirection, which is essential for a “CLI based workflow.” Get comfortable with pipes and file redirection, it’s extremely powerful!
Writing shell scripts is another super useful exercise: any time you find yourself running the same set of commands multiple times, think about making it a shell script. You may end up with some really useful little custom tools that way.
Is this useful?
https://github.com/rodlie/powerkit
Not affiliated and haven’t used it, but its tagline of “Desktop Independent Power Manager” seems like it fits the bill.