It’s here, it’s there, it’s everywhere. The problem with replacing things that work with something “better” is that “better” is subjective, so you end up with a new “better” way every few years, and maintaining existing systems becomes a god awful slog. See the JavaScript ecosystem.
The bash I wrote 10 years ago still works today, and it will still work in 10 more years. The same bash will very likely work on your computer, on a remote server, etc. This is the power of not chasing “better” all the time.
Try running a Ruby or Node program from 10 years ago today on your computer. Now, try running it on a random Linux server.
Please do not take this as a slight against Ruby or Node, or any other high level programming language. Bash compared to those is simply apples and oranges, they are not the same thing.
By all means, if you have a project that requires a Ruby runtime anyway, write operational scripts with Ruby, run them with Rake, etc.
Want a portable script that doesn’t depend on a complex runtime? Use bash.
If bash is too limiting, use Perl. No, seriously. Perl is fine. It is about as ubiquitously available as bash, and the standard library likely has what you need to get the job done. People blindly dismiss Perl because some blog post told them to, usually in the context of writing application code. You’re not writing application code, you’re writing scripts. Would you write an application with bash? No.
Let’s see here. We’re talking about a thirty-plus-year-old language that was deliberately written as a superset of sh from 1979. Its main purpose is to glue together other command-line programs on 'NIXish systems to automate complex procedures for sysadmins. Using it as a general-purpose programming language, while not impossible, is kinda dumb if you have any other options. Within its original niche, it ain’t broke, so there’s no need to fix it.
It’s a contemporary of Tcl and Perl, not of Python and Java (and sh is from the era where microcomputers mostly used BASIC dialects). Unlike Perl, it didn’t bolt on object orientation or other more modern features afterwards—and really, Perl was intended as just the kind of “shell script killer” you seem to be thinking of in your introduction. However, it never completely displaced the shell built-in scripting languages even in the days before it fell out of favour itself. Might be that there’s a reason for that.
Alma and Rocky have been around for a while already. Most people I know moved over to those after Centos went EOL. Not sure what Suse will do that these don’t already do.
Interesting. The place I work at mostly use RHEL, with Rocky as an option for customers not wanting to pay for RHEL support. Will look into Suse’s offering once it arrives.
I’ve ripped the entire 10 seasons of the show “friends” using makeMKV. Just make sure you give it a couple of trial and error runs so you can understand what you’re getting. Some blurays have many options that you may or may not need.
That said gives such a confidence on their promises that they have to add this statement at the end
"Forward-Looking Statements
Any statements in this press release about future expectations, plans and prospects for the company, including statements containing the words “aims,” “targets,” “will,” “believes,” “anticipates,” “plans,” “expects,” and similar expressions, may constitute forward-looking statements and should be read with caution. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including competitive landscape, development of customer deals, reliance upon customer relationships, management of growth and acquisitions, the possibility of undetected software issues, the risks of impacts of the Covid-19 pandemic and economic downturns, pricing pressures and the viability of the Internet. In addition, any forward-looking statements included herein represent views as of the date of this press release and these views could change. The Company does not have any obligation to update its forward-looking statements. These forward-looking statements are subject to change and should not be relied upon as representing the Company’s views as of any date other than the date of this press release"
Hmm i hope, especially with them mentioning cov19, that this is only the standard boilerplate legal defense stuff. It would make sense to not have the whole company going down if this side project fails
They do have exactly the same on their other news posts.
You aren’t. Even if you want to stick with bash, you can run scripts written in other languages. I have a few Ruby scripts. I can run them just like I do bash scripts.
I haven’t done this yet because I didn’t need it, but I think you have the option to install newer packages by creating a nixpkgs overlay. If the build process didn’t change between versions, it should be pretty straightforward. See nixos.wiki/wiki/Overlays, section “Overriding a version” for an example. Better yet create an issue on the nixpkgs bugtracker, or even better file a pull request for the updated package.
Edit: you could even define a new updated package just for the package that depends on it and then pass that new package as a normal override. No need to update the package systemwide.
Most derivations are pretty flexible; the ones that aren’t, however, will require you to write your own overlay to fix them. Or just fork them entirely. This is one of the advantages in Nix in that you can create reproducibility at any granularity. Writing and using your own derivation is complex though. Most packages provide more than enough knobs to change their configuration on their own in my experience though — my current Nix build uses no derivations I had to write myself.
Home Manager and Nix itself are versioned so I don’t understand your complaint about config changing. If you’re happy with how your system works just don’t update it to a newer version. If you do, as in any other software, you risk breakage. The advantage of Nix in this scenario obviously is that rolling back in the case of an upgrade going wrong is incredibly trivial.
I could’ve worded the configuration part a bit better. My gripe wasn’t necessarily with that, but more with “If I ever had to make my own package from scratch including dependencies, this would be practically impossible” Nix’s derivations and other packaging information is crazy complex and keeping track of versioning, etc. is a nightmare. I think often about doomsday scenarios for systems. It happens, just look at CentOS and all that, so my main thing was if something like that happened, could I maintain the packages I use manually, and the answer was no. Of course I’m not in a doomsday situation, so I’m fine with it as it is. It’s just a thought I had, and that was my conclusion.
Derivations are kinda complicated but you can definitely get them if you try! There’s nothing super magical about them. As opposed to the rest of Nix which can feel extremely and unfortunately magical…
Gotcha I’ll start playing around with derivations. I also just came to the realization that because of the magic of Nix, I can try these things, and if it breaks it, I can just roll back.
It's not as hard as you think, since you can just copy some other package for a skeleton and substitute your own files. There are just a few files to do a basic package
NixOS packaging is really not complex. The ease and speed of creating a Nix package is a large part of the reason for why there are so many packages. I regularly make packages myself and for the most part it is very simple.
I used testing for ages, it is really stable. Only the phase after a feature freeze for the release of a stable version can be a bit shaky. For some weeks I just change my repos to the stable version.
Bash isn’t the only shell. Most systems can use zsh or fish or tcsh or whatever shell you prefer, if you like that better than bash. You’re gonna have to run a shell if you want to use the terminal, though, you understand that?
Shell scripts are very good for specific tasks. Don’t use them for tasks that are unsuitable. Use python or go or node or c if those are better for your needs. Use the right tool for the job. But also, learn to understand why the industry has been using shell scripts for decades.
As a shell, tcsh was OK if only because it included GNU Readline (or something like it) and, despite being a couple of years younger, kind of beat bash to the punch for that user-friendliness on account of being a largely unchanged drop-in replacement for its predecessor.
Bash isn’t the only shell. Most systems can use zsh or fish or tcsh or whatever shell you prefer, if you like that better than bash. You’re gonna have to run a shell if you want to use the terminal, though, you understand that?
Defaults matter. There are a lot of situations where you aren't allowed to install whatever you want. It would be less of an issue if other shells or language run-times came preinstalled. The problem isn't really Bash itself. It's the fact that it's often the only dependable option. But thankfully that's starting to change and you can usually find python preinstalled at minimum.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.