71–80 of 92 posts
Earlier quoted context omitted.
Learn about the file system, permissions, processes, signals, threads, the scheduler, standard input and output, networking, etc.
Yeah, I just haven't seen a single book/resource that does this - maybe I'm not looking hard enough. "the linux command line" from nostarch press was good but, of course, focused on commands
Earlier quoted context omitted.
To be sorta serious about editors for a min. I think console editors should definitely be in there because a lot of Linux access takes place over ssh without a GUI.
And Vi/Vim is present everywhere, so it is a must for sysadmins.
What's the best way to run software on an old Ubuntu system that I don't want to upgrade or run apt-get on, and I don't want to run stuff inside a Virtual Machine, and snap is broken, and docker as well? Compiling stuff seems too much trouble because of all the dependencies. I was hoping for Nix to save me here, but it only compiles for a specific libc version.
So, in years past, I lamented that people didn’t know basic sysadmin skills and therefore invented complex solutions to what are rather simple problems of configuration within common Linux software. They’d write entirely new pieces of software to deal with something I saw as trivial, and they did this because they didn’t know a solution existed. These days, I don’t lament this at all. As I see it, people wanted to ma…
I've seen that quote a thousand times and I disagree with it profusely. After 30 years of it now on my part, I know we can and should do better. And that does mean reinventing it, not being resigned to the status quo.
What usually happens is that people reinvent functionality from layer 3 at layer 47.
Earlier quoted context omitted.
This is as it should be. Emacs is about enlightenment; enlightenment is a path to be walked not a destination; it is a journey you must choose. Along the way, you might accidentally edit text files. That's not the point. Anyway, makes sense to me why it's not default included.
Surely we can all agree that nano (pico) is a toy compared to either.
What's the best way to run software on an old Ubuntu system that I don't want to upgrade or run apt-get on, and I don't want to run stuff inside a Virtual Machine, and snap is broken, and docker as well? Compiling stuff seems too much trouble because of all the dependencies. I was hoping for Nix to save me here, but it only compiles for a specific libc version.
What's wrong with Nix in this situation? A Nix package's closure will come with its own new-enough glibc, right?
Earlier quoted context omitted.
What's wrong with Nix in this situation? A Nix package's closure will come with its own new-enough glibc, right?
Yes, but an external glibc puts extra constraints on the nvidia driver versions I can use. The driver I have now works fine.
I know that GPU stuff is an area that requires some impurity on foreign Linux with Nix. I didn't realize that had implications for libc versions. :(
Earlier quoted context omitted.
Yes, but an external glibc puts extra constraints on the nvidia driver versions I can use. The driver I have now works fine.
I see how that's a problem. I know that GPU stuff is an area that requires some impurity on foreign Linux with Nix. I didn't realize that had implications for libc versions. :(
Earlier quoted context omitted.
I've seen that quote a thousand times and I disagree with it profusely. After 30 years of it now on my part, I know we can and should do better. And that does mean reinventing it, not being resigned to the status quo.
Care to give some examples? I am still too young in Unix years to be wise enough to judge what is good and what is bad.
1. Constant weak reparsing of formats in shell pipelines.
2. Completely dangerous and unsafe API and principal programming language.
3. Trying to remember several different domain specific languages.
Earlier quoted context omitted.
Care to give some examples? I am still too young in Unix years to be wise enough to judge what is good and what is bad.
Top three bits of pain from me: 1. Constant weak reparsing of formats in shell pipelines. 2. Completely dangerous and unsafe API and principal programming language. 3. Trying to remember several different domain specific languages.
Apart from the fact that these days you can hardly call C principal (yes, it's still used for the Linux and BSD kernels, but quite rarely for any new userland project at all), what are your main gripes with the API? It is well understood, stable, most people know its limitations, it's being used by most servers and clients on the Internet, so I'm curious why you call it "completely dangerous and unsafe".