Is Nix really appropriate for building a complete rootfs? Could I start from scratch and write a nix build script or whatever and end up with a rootfs I could run on some aarch64 SBC or SoM?
And how is the Nix story for going from a rootfs to a bootable image? On e.g Rockchip you need to make an image where there's some firmware blob in one are of the flash which jumps to a uBoot in another area which loads the kernel/initramfs/devicetree, how does that look in Nix land?
How does it handle building vendor kernels or carrying kernel patches instead of mainline?
I don't really like Nix but it's probably fine for this - you have files that come in, a build step, and output files. Your derivations (build recipes) are functions that can take arguments to e.g. provide a set of patches to apply. There are recipes for building a kernel in nixpkgs already which you could fork.
The main annoyance I'd have in your case is probably the number of file copies of large images it may do to keep things isolated, but most hermetic build systems will do something similar.
Yes, most of this is all supported. There is a existing recipe for building an image that you just dd to and SD card and can boot in a Raspberry Pi (and other devices supported by mainline kernel + u-boot).
Kernel is a package just like another; so you just write your own recipe. Patching kernel recipe works just like patching any Nix recipe.
Not sure about the rockchip-proprietary boot parts; you may be on your own.
I mean that's probably a perfectly nice solution too, it doesn't all have to be as physical controls on a center console. It just needs to be easily accessible physical controls which I can interact with through feel without taking my eyes off the road. As long as it's not on a touch screen and not those shitty haptic capacitive buttons I don't care whether it's on a steering wheel or on a center console
That's the entire modern, Tesla-inspired design ethos: remove all knobs, remove all buttons, remove all levers, remove the PRNDL, remove all the gauges, replace it all with controls on a big iPad in the center, and call the spartan interior "high-tech"
It's not even "concept car from 2035", it's "concept car from 2015 trying to look like a car from a sci-fi story set in 2035"
And I agree. People like normal cars, people like normal door handles, people like A/C and heater knobs, people like PRNDL levers. None of that has changed just because the drivetrain uses a different kind of engine. Why is it so hard to make that, but electric? Why does "electric motor" somehow mean "all controls must be on the iPad"?
I hope it's just a phase that's about to reverse. Maybe they felt the need to go all futuristic design to cash in on how electric drivetrains used to feel futuristic. Maybe, as electric drivetrains just become "normal, boring" technology, we get options with normal designs too.
We're in a situation where it's already "too late". We can't go back 100 years. How do you propose we fix it, assuming time machines won't get invented soon?
You don't think MercadoLibre has job postings open all the time just to replace the people who are leaving? They're around 120 000 people, is each of those people hand-picked for a particular position and not just hired because they know they need to replace some percentage of workers who'll leave?
Company's own website job listings are likely actually in an applicant tracking system (ATS) like Greenhouse or Ashby because they need to manage the pipeline, not just list the job.
> At a large enough company you continuously lose people for natural reasons, like retirement, moving for a spouse, moving to be closer to family. Past a tipping point you're just always hiring.
As an analogy it's kinda like hard drives: when one of my hard drives dies, it's An Event which I need to deal with specifically; I need to order a replacement for that specific drive. At Google's server farms, hard drives dying is just a statistic, you continuously buy hard drives just because you know existing drives are gonna die at some semi-predictable rate.
It's not really an analogy, it's just facts of life. In a large enough company or over a long enough time period at a job or in your career, realistically people actually will eventually die and cause vacancies. I've had two coworkers die, one because of illness, the other because of an auto accident. I stopped using the "bus factor of one" phrase as a result even and use "redundancy or succession planning" since it's not outside the realm of possibility that someone might get hit by a vehicle.
I don't think "bug" is the correct term. They put a feature behind a feature flag, and feature flags don't work if you turn them off (via telemetry). That's "Working As Designed™".
It's clearly an unintended interaction. Nobody intended for the telemetry switch to control whether it reads AGENTS.md (hence mpoteat's apologetic response). Whether you consider that to be a "bug" or not really wasn't the point of my message.
Clearly not Claude-speak, see the rest of the message. "Rollout artifact" just means "an artifact of how we rolled this change out" which maybe isn't proper English but the message was obviously not written by Claude. Upgrade your Claudish detection
Developer comms are very important. I've often "fixed" something that was working exactly as the designer made it. It certainly wasn't a bug in my work though. I've worked in places where we call this a "design omission" ;)
Feels pretty normal to me, IDK. "Rollout" is definitely what was happening here, and this leftover problem can be described as an "artifact" most generally - I guess otherwise it'd be a... just "problem" or "mistake"? Cause "bug" doesn't really fit. Plus, the Claudism here would definitely involve "soak", and possibly even "wall-time" lol
IMHO it's worth keeping in mind that Anthropic employees are some of the least likely to casually pass off artificial prose as authentic, given the company's ethos/brand/cover story (depending on how cynical you are). To them this is all getting pretty high stakes pretty damn quickly; based on my usage of full strength Opus 5.5 today, I can't even imagine what working with their full internal stack must feel like. If they were willing to let the machines speak for them, they'd all be melancholically lounging around home by now instead of coming in to work!
...I am refusing to consider the fact that they probably are still WFH because of Salesforce forcing their shared security contractor to strike. Call that a mental health ignorance on my part :)
And how is the Nix story for going from a rootfs to a bootable image? On e.g Rockchip you need to make an image where there's some firmware blob in one are of the flash which jumps to a uBoot in another area which loads the kernel/initramfs/devicetree, how does that look in Nix land?
How does it handle building vendor kernels or carrying kernel patches instead of mainline?
reply