I’ve been pretty happy with taking a Terramsater F4-425 Plus and putting Linux on it.
I feel like the mini ITX market for motherboards is just too niche. If you want something small, buy an off the shelf NAS. If size is not an issue, buy a case that can hold a full sized motherboard and lots of disks.
Tesla has its problems (between 2019 and 2024 the auto headlights and auto wipers were borderline unusable, now they are merely tolerable, and autopilot is a whole story on it's own), but maintenance is not one of Tesla's issues.
Useable, human-readable errors in the app/touch screen (the car self diagnosed it's 12V battery problem and told me to call a tech) and mobile service is just an awesome experience.
Yeah people love to hate on Tesla and always point out the maintenance issues. But from the reports I have seen, Tesla is indeed one of the companies with the worst record in terms of number of incidents requiring maintenance, but among the cheapest, if not the cheapest in cumulative amount spent on maintenance.
I feel like if these report included the price and severity instead of just the frequency of the maintenance it would paint quite a different picture.
Except if a car was reliable it shouldn’t have errors at least until at least being 10 years old (the 12V battery is an exception because it has a smaller lifespan than the car). I never had a check engine light on my previous car during 10 years of ownership, I’m worried about consumers getting used to a new normal of low quality.
> Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly.
Strong agree on this one, usually embedded systems are designed to "fail safe" on crash - the watchdog will trip, and hardware reset will put everything in a deterministic, known safe state.
What you want, above all else, is not to fall into undefined behavior. That's the beauty of `unsafe`, it bounds UB into small boxes you know to test the hell out of.
My personal experience (YMMV): Rust code takes 2x or 3x longer to write than what came before it (C in my case), but in the end you usually get something much more likely to work, so overall it's kind of a wash, and the product you get is better for customers - you basically front load the cost of development.
This is terrible for people working in commercial projects that are obsessed with time to market.
Rust developers on commercial projects are under incredible schedule pressure from day 0, where they are compared to expectations from their previous projects, and are strongly motivated to pull in anything and everything they can to save time, because re-rolling anything themselves is so damn expensive.
I think they were using "writing Rust" in the most strict sense: the part of the development cycle that involves typing the majority of the code, before you really start debugging in earnest and really make things work.
But their point is that "developing Rust" (as in, the entire process) ends up being a similar total effort to C, only with more up front "writing" and less work on the debugging phase.
Thank you for the clarification, that's exactly what I was trying to say :).
Perhaps another way to phrase this: in Rust, you spend more time telling the compiler how your code is expected to work (making the borrow checker happy, adding sync traits on objects you "know" are thread safe because of how you use them or assurances the underlying hardware provides, etc etc etc). In return, the compiler does a lot of work to make sure the code will actually work how you think it's going to work.
A good example is a simple producer-consumer problem. Make a ring buffer. Push the current sys clk tick count register to the ring buffer every time there's a rising edge interrupt on a GPIO (e.x. hook up a button or something to it). Poll the ring buffer in another thread and as soon as there is a timestamp in the buffer, pop it and log it to a UART.
Compare writing this in C vs Rust. In the text book implementation of a producer-consumer ring buffer, you don't need locks.
In C, this is a problem I'd expect a senior-level candidate to be able to knock out in a 60 minute interview.
(aside: I'd never actually ask a question like this in an interview, because it heavily favors people who just happen to be familiar with the algorithm, which doesn't give me enough signal about the candidate. This is borderline like asking someone to implement a sort algorithm in an interview - it just tells you they know how to google or memorize things. /aside).
(aside 2: If I did ask this, I'd be more interested how they design the thing - I'd be looking for questions like "how many events per second? How should I size the ring buffer? Wait, you want me to hook up an IRQ to a button? Is there a risk of interrupt storm from bounce or someone being malicious? Do you want me to add a cooldown timer between events? If we overflow the ring buffer, what should the behavior be? How fast can the UART go on this system - can it even keep up with the input?" - I'd be far more interested in that conversation than actually seeing them write code for this. /aside2).
In Rust, it's a bit more tricky. You'll need to give the compiler hints (in the form of Sync traits that are no-ops) to tell it you know what you're doing is thread safe. It's not rocket science, but the syntax is kind of weird and it will take some putzing around or aid from your favorite AI to get it right.
All of Rust ends up like this - you must be more verbose telling the compiler your intent. In exchange, it verifies the code matches your intent. So the up front cost is higher.
I suspect a lot of people will just pull a ring buffer off crates.io instead of figuring out the right incantations to make the compiler happy.
¯\_(ツ)_/¯ I'd like to lean into that "YMMV" in my post, I'm coming from low level C that interacts with hardware, can't really speak to higher-level C++.
Some things in Rust just don't translate to the way you'd do them in C - e.x. using different types to say if a GPIO pin is input or output adds a ton of boiler plate, but lets the compiler assure you don't mistakenly try and use a pin configured as an input for output.
In general, the whole zero sized types paradigm in Rust leads to way more lines of code to accomplish the same thing (it all ends up compiled out in the end though).
For embedded, I'll stand by what I said: it takes longer to write idiomatic Rust but you are more likely to get functionally correct code in the end.
ZSTs are a choice, if you're not benefiting from them in development time or correctness, why are you making that choice?
Rust isn't just C++ with static analysis. The safety is only about 1/3 of what makes me enjoy working with it. Even if I just consider the effort taken before I present something to a compiler, the trait system means I don't spend anywhere near as much time writing copy/copy assignment/move/move assignment constructors.
Some of that 2/3 will be me making choices like ZSTs, but I believe that's a result of it being necessary to grok the whole language and style and the idioms. If I just try to write C in Rust, it will be bad Rust and I'll have a bad time - but the same goes for just writing C++ as C with classes. I deliberately didn't say 'C/C++' in my ancestor post, because I think it's terminology that undermines claims of authority.
I do happen to have embedded experience, but avoid drawing conclusions from it because it is so different to more 'standard' systems development. If you can forgive a tangent: I avoid the whole domain now, because it feels like a ghetto. Standards are poor, tools are poor, pay is seriously poor. If you want to write embedded software, you probably have to work for a hardware company with hardware company's engineering culture and revenue model. That's a pretty crap place to write software in the west. I can't comment on comparing what like to do embedded development in Rust. Frankly, I hope I never can.
Good on you for recognizing what you enjoy and going for it.
I like hardware, always have :).
FWIW, I’ve done embedded at multiple mag 7 companies, and if levels.fyi is to be believed I’m getting paid the same as my peers doing other types of software. There are certainly places that don’t do this though (I hear the defense industry is notorious for this).
The point about the tooling being ghetto is spot on though, that’s part of why Rust is so exciting for us. A package manager?! What is this magic!!!
My experience in low-level stuff has been a mirror of the Linux kernel trying to take up Rust. Some people love it and fight hard for it, some hate it and fight hard against it, but most just see it as another tool in the toolbox and don't have strong feelings.
As someone who works with hardware, hard to repo bugs can take months to track down. Your code, the compiler, or the hardware itself (which is often a complex ball of IP from dozens of manufacturers held together with a NoC) could all be a problem. The extra fun bugs are when a bug is due to problems in two or three of them combining together in the perfect storm to make a mega bug that is impossible to reproduce in isolation.
Random example: I once worked on a debug where you were not allowed to send zero length packets due to a known HW bug. Okay fine, work around in SW. Turns out there was an HW eviction timer that was disabled. It was connected to a counter that counted sys clk ticks. Turns out it was not disabled entirely properly due to SW bug, so once every 2^32 ticks, it would trigger an evection, and if the queue happened to be empty, it would send a ZLP, which triggered the first bug (hard hang the system in a way that breaks the debugger). There were dozens of ways that could hard hang the system, this was just one. Good luck debugging that in two days.
We had one where data, interpreted as address (simple C typo before static analysis was common) fell into an unmapped memory region and the PCI controller stalled trying to get a response, thereby also halting the internal debugging logic and JTAG just stopped forever (PPC603 core). Each time you'd hit the bug, the debugger was thrown off.
That's unfortunate, perhaps your particular macbook is having a hardware problem?
As a point of comparison, I daily two ARM macs (work M4 14 + personal M3 14), and I get far better battery life than that (at least 8 hours of "normal" active use on both). Also, antidotally, the legion of engineers at my office with macs are not seeing battery life issues either.
That said, I have yet to encounter anyone who is in love with macOS Tahoe and it's version of Liquid Glass.
The current issue is iOS 26.1’s wallpaper renderer crashes in a tight loop if the default wallpaper isn’t installed. It isn’t under Xcode.
I have macos crash reporting turned off, but crashreport pins the CPU for a few minutes on each ios wallpaper renderer crash. I always have the iOS simulator open, so two hours battery, max.
I killed crashreport and it spun the cpu on some other thing.
In macos 25, there’s no throttle for mds (spotlight), and running builds at a normal developer pace produces about 10x more indexing churn than the Apple silicon can handle.
To those not familiar with LA or the USA, here’s a cultural time capsule from 2Pac circa 1996:
“ It's the, City of Angels and constant danger
South Central L.A., can't get no stranger
Full of drama like a soap opera, on the curb
Watchin' the ghetto bird helicopters, I observe”
Well the danger part has decreased a lot. It peaked at almost 100 per 10k people in the 90s, and now it's closer to 25. Still very high, but a lot of progress.
Remember the movie Minority Report? Where a central plot point was the main character being tracked (by their retina in that case), and how to defeat the tracking? Vibes.
Illegal immigration is a crime. So is jay walking and software piracy and murder. There’s a lot of nuance to be had here in how big of a deal it is and how people who do the deed are treated.
It’s always felt weird though that it’s become taboo to call it a crime, but maybe that’s just me.
The issue is that it is illegal AND a nontrivial part of the electorate wants it enforced.
The “let’s all step back and consider my side’s view of this” isn’t really relevant after our side loses elections. If the will of the people is to start enforcing jay-walking, for better or worse, we’re going to see a lot of jay-walking enforcement.
The vast majority of undocumented immigrants arrived legally and are visa overstays, which is NOT a criminal violation but rather a civil violation.
For most of America's history it wasn't even illegal to enter the US without prior authorization. The law that made it a crime to enter the US without authorization (8 U.S.C. § 1325) was specifically created in the 20's to restrict immigration by race. And the violent enforcement of this law has really only ramped up in the last few decades.
It is very strange to see many people in the US (and in this thread) accept the current enforcement framework as simply a set of static rules that just happen to be here, and not a relatively recent phenomenon that was enacted and enforced for a project of racial prejudice.
I think it's more that something being a crime doesn't make it immoral, and something being a crime doesn't mean it should continue to be.
I do not think most illegal immigration should be considered a crime. That's my position. Moralizing about it by saying "well these people are CRIMINALS" because they crossed an imaginary line on a map is odious to me.
I guess I don’t have a huge association with calling someone a CRIMINAL as a big deal. Like I speed on the highway every day, I’m a criminal too. I don’t really feel like I’m doing anything wrong if I drive safe and there’s no traffic near me. If I got a ticket though I did the deed and so be it. It’s not some black and white, “you’re a criminal so you’re evil” thing for me at all. The punishment should fit the crime.
I feel like the mini ITX market for motherboards is just too niche. If you want something small, buy an off the shelf NAS. If size is not an issue, buy a case that can hold a full sized motherboard and lots of disks.
reply