I've run into a similar issue in Rust with SIGPIPE. The compiler adds the call to signal() to ignore SIGPIPEs when a Rust program starts. Apparently this was to stop a listening server from exiting when a client closed their connection. But in my book I'm teaching Rust by rewriting a classic BSD utility (cat, head, wc, ...) in Rust and none of those utilities have to care about broken pipes because they don't ignore the signal and the OS silently kills the process. Instead, if a Rust program doesn't handle a write failing with a EPIPE error then the process panics and exits with a backtrace. The worst part is that Rust standard library doesn't include a module for handling signals so it's not possible to undo the signal() call ignoring SIGPIPEs without using another crate.
In the end it's fine and you just have to handle broken pipes but it adds a lot of boilerplate to small CLI programs that in C just work as expected. Another twist (and possible further subtle bug) is that most shells set the exit status of a program that exits from a broken pipe to 141 (128 + the signal number, in this case 13). So when you catch the pipe you can exit the process with a status of 141, but that's the shell's behaviour and there's no safe way to fake an exit status.
Unix was "designed" (if you can call it that) a long time before it was possible to move a running system between timezones. So many of these decisions were made in completely different circumstances (I almost said environment) and are laying around like old WWII bombs just waiting for someone to dig one up.
OpenBSD replaced sudo with doas (with a vastly reduced feature set) several years ago, and without breaking everything. Sure there are use cases where you absolutely need some feature of sudo, but you can always install it.
Every time I see an update from Justine I get so excited. It's like watching the future of computing unfold in real time. It makes me wish we could send them back in time - all of the pieces to make this work have been in place for a long long time but nobody connected all the dots. The funniest part of this post are the instructions to integrate it with autoconf. All of that autotools nonsense wouldn't have had to exist if this had been around!
Just rustup update. The most frustrating part of the whole experience is the rate at which the clap argument parsing crate makes breaking changes. I've had to pin a specific version because they start deprecating features as soon as they make a release. So in my experience the crate ecosystem moves much faster and is less concerned with backwards compatibility than the compiler/core language. And compared to most languages the Rust standard library is fairly sparse (which I think was a smart move).
That hasn't been my experience with Rust over the past 5+ years. Maybe I haven't been poking into obscure features. When the language is as old as Perl I imagine the pace of change will slow but already it's been very slow moving and stable. There's a huge emphasis on backwards compatibility (editions are such a great concept).
"Rust From the Ground Up". I've been releasing it chapter by chapter on Leanpub - the first 220 pages are out and I'm finishing up another chapter ('cut'), hopefully by the end of the year.
I'm publishing a book which teaches Rust CLI programming by rewriting a BSD Unix utility in each chapter. I'm using the 4.4 release from 1992 but looking at the contemporary source from modern BSDs (Free/Open) they're totally recognisable and often basically unchanged. It's also amazing that some bugs persisted for 10-20 years before being fixed. I'm sure there are a few still to be discovered...
I've seen this over and over with cloud projects. People absolutely get promoted/raises based on optimising/cutting cloud budget. So there's no incentive in doing things efficiently from the start. You're much better off to build a vastly (but maybe not obviously) inefficient first version and then go back later and show how you "saved" the company tons of money by turning off a bunch of unused services etc. It's harder to hide racks of powered off servers which is why this is so prevalent in the cloud.
What does "reputable" mean in this case when these universities are handing diplomas to graduates who can't code? Somehow we've gotten ourselves into the situation where we force someone with a CS degree from Stanford write some leetcode, even when the people on the hiring panel themselves have degrees from Stanford. Do they still not trust their own university?
And yet, when scanning resumes, people often look for prestigious/"reputable" universities as a filter. Is the assumption that if they have a degree from Stanford and can reverse a string then that is a positive signal, but if they can't reverse a string that is somehow a personal failing and not a failure of the university to educate (and then evaluate) the candidate?
And no liquid restrictions. They have special trays for the x-ray machines so you can bring in your coffee without spilling. And you can come back from France with a box of 12 wine bottles no problem.
Well yeah that's the difference, it doesn't generate the state machine for you so you "just" need to implement it yourself. For v3, rpcgen spits out a working function that you link into your program and you're done (on the client side anyway). Much easier.
It's widely implemented but not adopted. Most vendors implemented v4 to tick a box for some RFQ. I don't think any of the commercial fileserver vendors publish numbers but I used to work in that space and internally customer adoption of v4 was always a single digit percent. When I was on the customer side in HPC none of the supercomputer clusters were using v4 (I'm sure there are exceptions that I wasn't aware of).
NFSv4 is a completely different protocol and basically doesn't share anything with v2/v3. While technically it's still implemented using Sun RPC, it only has two procedures: NULL and COMPOUND. Version 3 is actually an RPC protocol, with a different procedure for each filesystem operation (READ, WRITE, CREATE, ...). One of the genius moves that Sun made with NFS was to distribute the protocol files (rpcgen) which autogenerate stubs (in C) making it easy to implement servers and clients. Nothing like that exists for v4.
We're in the process of designing a house in a rural/mountain region and friends and family keep telling us to put in fireplaces/logburners in case the power goes out. But we don't like the idea of all of those particles in the house (plus the external pollution). However we're predicting that we'll have at least one 60kWh+ portable battery parked in the garage, plus solar panels (which aren't great in winter but still help) and possibly a battery like the Powerwall (another 14kWh+). So it feels like the days of worrying about losing electricity are coming to an end.
As an American I had the same expectation trying to buy dry ice in New Zealand - couldn't find it in supermarkets or petrol stations. I wanted to get some for our outdoor/off grid wedding to keep the beverages cold for several days. Eventually I called BOC (who supply industry and hospitals) and they agreed to sell us some but when I showed up with a cooler (chilly bin) they laughed at the tiny amount I wanted and filled it up. I don't think they'd ever sold it like that to a private buyer.
No migration of this magnitude is blocked because of engineers not "bothering" to start the process. Imagine how many approvals you'd need, plus getting budget from who-knows how many government departments. Someone is paying for your time as an engineer and they decide what you work on. I'm glad we live in a world where engineers can't just decide to rewrite a life or death system because it's written in an old(er) programming language. (Not that there is any evidence that this specific system is written in anything older than C++ or maybe Ada.)
Linus's biggest contribution to software engineering is git but it took writing a kernel first to give him the idea. I'd argue that git has had a bigger impact on the world than Linux.
The Linux kernel is an amazing piece of software but especially in the beginning wasn't especially innovative. The Solaris kernel was a much better implementation of the Unix lineage. The Mach kernel was interesting from a research perspective, and lives on in MacOS and iOS. HURD was a worthy experiment, as was Plan 9. But git was really head and shoulders above anything that came before.
Sure, but the question was specifically looking for the "minimum effort" solution. I almost brought up thiserror but that just makes things more complicated. If you're writing a Rust application and just want to propagate errors, anyhow is currently the most popular way to do that.
This post really highlights how much of the development in London is infill into already existing Victorian (or earlier) neighbourhoods and how the city is growing without sprawling outwards. The Victorians built the Metropolitan line out almost all the way to Aylesbury anticipating that the city would follow but it really hasn't. When you take the tube to zone 9 you start to go past horses and cows in fields. There are some really nice walks in the Chiltern hills starting from Chesham and Amersham and you don't feel like you're in London at all. We always wonder if people living there even consider themselves as Londoners.
I would also assume so but then I suppose that it's basically impossible at this point to avoid a leetcode interview where you have to prove that you can solve Fizzbuzz, even if you've literally written a book on the language. But my goal wasn't to get a job writing Rust in the first place.
I started writing a book to teach myself Rust but ended up teaching myself how to write. I've found that I have a much deeper understanding of the language now because I have to actually explain things in detail, and not just get the program to compile and move on. But I would say that the biggest side effect has been learning to write well. That has turned out to be much more impactful to my career than learning Rust.