Shell scripts are a more evolved form of programming and nobody can change my mind on that. They require less work, they're easier to make, they're flexible, compatible, composable, portable, small, interpreted, and simple. You can do more with few characters and do complex things without the complexity of types, data structures, locks, scoping, etc. You don't write complex programs in it, but you use complex programs with it, in ways that would be over complicated, buggy and time consuming in a traditional language.
That said, it's a tool. Like any tool, it depends how you use it. People who aren't trained on the tool, or don't read the instruction manual, might get injured. I'd like to see a version of it that is safer and retains its utility without getting more complicated, but it would end up less useful in many cases. Maybe that's fine; maybe it needs to be split into multiple tools.
I agree with most of this, my biggest issue is how hard it is for me to recall any moderately complex shell syntax (or the slightly different Makefile syntax). LLMs largely solve that for me.
When people mention `bash` it's immediately a code smell. In order to write portable shell scripts, it must be only POSIX `sh`. If the need ever arises for a more complex data structure, typically I jump into AWK since it's also POSIX compliant.
Not every shell script has to be that portable. And even then, "POSIX compatible" shells vary in their "POSIXness". Sometimes using arrays is the right thing to do, or having a reliable indicator of the source script location, so you code to Bash 3. Sometimes associative arrays or something else is better, and your platform is known, so you code to Bash 4 or 5. Maybe all your users are Zsh users so you use that. So you can start by writing POSIX compatible scripts, but there's no sense in tying your hands if you don't need to.
The Bash manual also covers POSIX semantics, I just remember which is which. You're right that the Dash manual is a good place to check what is mostly POSIX (Dash isn't actually strictly POSIX). I would probably use Shellcheck with the correct shebang to double check what's compatible.
I've never been in a situation where I had to care. Bash is everywhere, it's a de facto standard of its own. Even a lot of buildroot and Alpine based Linux deployments, which don't come with bash by default, usually have bash added to them.
It doesn't come with bash pre-installed, but installing it is as simple as "pkg install bash", and that is the option that everyone working with FreeBSD will choose when they encounter a shell script that only works with bash. My point is that bash is already so ubiquitous that almost no one is going to care about an extra few megabytes for the bash executable in their OS image.
If you're installing packages anyway, then why not just write in Python, Go, or any other languages which have relatively less footguns and have more features? I'm sure at least some of those packages are also available on FreeBSD.
I have written a lot of bash. When you know what you're doing it's very productive. But it still feels like walking a tightrope, where some corner case in quoting, interpolation, comparison, etc will one day rm -rf / you.
What i really want is "python, but with really easy running of subcommands". Imagine extending python with a $ operator (prefix, applied to iterables) so that
files_iter = $('ls')
would run ls and put an iterator over its lines of output in that variable, throwing an exception if ls exits with an error status (i realise there is a rabbithole of subtleties here - getting those right would be part of this). Or
Backticks are going in the right direction, but not quite it. I want to operate on lists (or iterables etc), not strings, so i have all the usual safe and convenient facilities of the language available to build them. I want to get an object back that is extremely easy to get various kinds of results out of (Python's subprocess object isn't; i'm not familiar with Ruby's). I want more aggressive raise_for_status style error checking.
Thinking about it, this doesn't need to be an operator, and i could probably just write this myself and start trying it.
Interesting point about globbing. My feeling is that i don't actually use it a lot in scripts - the criteria for matching are usually complicated enough that i'm much more likely to use find. In a project with 1376 non-comment lines of shell script, i found eleven uses of globbing.
The big mental illness crisis of the 21st century is really the same one from the 20th: mass media consumerism. Social media is literally just mass media consumerism in a more efficient, evolved form. It's the car compared to the bicycle: more advanced, with more bad outcomes than before. If you want to cure social media mental illness you'll have to wrestle with the fundamental addiction all humans now have to mass media, which has a symbiotic relationship with consumerism. Since the global economy depends on consumerism, it's not going to be easy to dismantle.
Something can be both hype and useful. Paradigm shift, no, because there's no fundamental architectural difference from any other replicated sql database.
Sqlite only really works as a throwaway database. For that it's pretty great. Although a lot of the current use cases for sqlite could have just been a .ini file.
If we didn't have the web, all networking above OSI L4 on all operating systems would have been encrypted by default. A simple set of syscalls and kernel features could have enabled it. But since the web was there, and popularized a solution for secure communications (TLS + HTTP), everyone just jumped on that bandwagon, and built skyscrapers on top of a used books store.
The weird irony is it's the old "worse is better" winning again. HTTP and TLS are fairly bad protocols, in their own ways. But put them together and they're better than whatever else exists. It's just too bad we didn't keep them and ditch the browser.
Assuming you are talking about IPSEC, that uses a model that is very hard to deploy.
The problem is that applications typically use TCP connections, but IPSEC works at the IP level. Early on, the (BSD socket) kernel API was basically fixed at the IP level instead of associating it with a TCP socket.
So the whole thing became too complex (also for other reasons). So SSL and SSH were created to have simple things that worked.
SSL took many iterations to get any kind of security, so IPSEC had plenty of time to get it right and take over. But as far as I know, there just never happened. It also doesn't help that TLS is trivial to combine with NAT, and for IPSEC that is quite tricky.
Isn't the Linux kernel at least very unhappy with the idea of adding encryption logic inside, especially in a way where they expose this to user space?
Obviously it happens on planet earth and the visitors are hackers who live on planet earth. I don't think they care particularly if it's ironic, I think they just don't like the name and are looking for something to complain about. So let them complain.
I think people should stop using PyPI altogether. It's full of abandoned garbage and malware because there's really no filter on who can upload what. I don't even use it to search for packages anymore.
If Linux distro packaging worked the same way, Linux would be a hellscape of malware and weird random broken apps. I'd rather use old software than constantly worry about fat fingering a package name and ending up with a crypto miner on a thousand machines. Thank goodness for that culture of vetting packages.
Fun fact: Unix used to work in slightly this way. You’d see something neat on comp.sources.unix, download it, and if it was useful, deploy it on your site for your local users. A bit later, huge FTP sites with everything ever written for Unix were routinely used as package repositories are used today. Modern Linux (and other Unices) distributions, with maintainers, strict inspection, limits on what programs can do, etc. came as a reaction to the obvious problems with that. It always seems to me that language-specific ecosystems like PyPI (RIP Cheese Shop), NPM, crates.io, etc. have not yet learned this lesson.
Isn't this the case for most programming languages' package indices? crates.io for Rust, the NPM registry for Javascript, etc. They are all public in the sense that anyone can just create an account and upload a package.
Maven Central is notoriously fiddly to get an account for - it require a manual registration step and you have to GPG-sign all your packages. Seems like that barrier to entry may have been useful.
A public hearing isn't going to change anything. Look at...well, literally any powerful organization or individual brought before Congress for excoriation. The pound of flesh they want is press and votes, and you don't have to change anything to get that.
It's not like they're going to break up Boeing. They can't actually do anything to improve Boeing. All they can do is wag their finger. It's not like there's an alternative American company to give our billions of dollars to. And it's not like other companies will suddenly fear being brought forward to be gummed to death by whining bureaucrats.
You want real pain? Have them pass a law that says the entire executive leadership's bonuses are forfeit, retroactively, if the company fails to maintain an adequate safety record. Shit will change there real quick. (That law will never happen but it's funny to think of)
I think culture is underrated. Acting like he did should not be considered a dignified behavior and I think that will meaningfully constrict behavior even in the absence of new laws. Think about how business culture varies across jurisdictions: there's more than just profit-maximization at work.
Also, to be clear, Boeing's safety record is still good. The only recent deaths are associated with less-trained pilots in the earlier days of the 737 MAX. My frustration is they took this organization from an engineering leader to an organization that can't ship a plane. The 787, 737 MAX, and now 777X were/are insanely delayed.
The nightmare scenario of a US-China war and Boeing being unable to ship a plane honestly haunts me. Boeing is extremely important to the West, broadly defined and this jerk didn't uphold his commensurate responsibilities.
> Also, to be clear, Boeing's safety record is still good.
Two complete losses within a few months is a fucking terrible safety record. The carnage only stopped when regulators forcibly grounded all 737 Max globally, while Boeing criminally denied any issues with the airplane design.
> The only recent deaths are associated with less-trained pilots in the earlier days of the 737 MAX.
The recent deaths are associated with criminal management at Boeing. It was not a pilot training issue. Boeing intentionally and criminally withheld information about the MCAS system from all pilots, airlines, and regulators. Literally no one had a clue about MCAS outside of Boeing. Furthermore, the MCAS design was fundamentally broken, falling below minimum aircraft engineering standards.
> My frustration is they took this organization from an engineering leader to an organization that can't ship a plane. The 787, 737 MAX, and now 777X were/are insanely delayed.
Cutting corners and trying to ship planes quickly is partly what got them into this mess.
> Boeing's safety record is still good. The only recent deaths are associated with less-trained pilots in the earlier days of the 737 MAX.
This argument makes no sense. A repeatedly faulty plane that has crashed multiple times does not have a "good" safety record just because recoving from that fault is part of pilot training. In fact that's the definition of what I'd call a bad safety record.
Is there anything applicants can do to better provide what you're looking for? Obviously giving more complete answers, but anything else that would help you find the right person? And the other way round, is there anything you might change to get the right people to find you?
We'll probably just work our personal networks harder.
Personal networks didn't work as well during bubble/ZIRP times because everybody good was employed and either they already made more than what you were offering, or were holding out for a company that paid more.
Nowadays everybody knows someone good who has been laid off or is worried about being laid off. Or maybe they made major lifestyle changes during the pandemic and now they'd have to move a small family from Omaha back to the Bay Area.
As for screening questions, there's never going to be an automated way that detects AI or AI-influenced answers, for obvious reasons. There are countermeasures I have in mind but I'm not sharing them here.
