Hacker News new | past | comments | ask | show | jobs | submit | Scramblejams's comments login

Since you brought him up: Stalin was also motivated by a truckload of paranoia, though, right? Hard to make rational decisions about who is dissenting if you think they’re all out to get you. The flimsiest accusations related by the least reliable people could be enough.

He executed and imprisoned a bunch of his best aircraft designers. Look what he did to Andrei Tupolev and his design bureau; they designed a whole aircraft in the Gulag: https://vvsairwar.com/2016/10/20/aviation-design-in-the-gula...


A classic feature of authoritarian governments: when their dumb plans fail, it's because of enemies of the state. Bonus points when the enemies of the state are the ones that warned of the negative effects that would happen (obviously they must have been saboteurs)

Cool project, good luck with it!

If I may surface one use case: Several years ago I had to manage a bunch of Macs for CI jobs. The build process (Unreal's UAT) didn't support running more than one build process at a time, and Docker was really slow, so I'd hoped to use different user accounts to bypass that and get some parallelization gains. Homebrew made that very difficult with its penchant for system-wide installs. So a feature request: I'd love to see a competitive package manager that limits itself to operating somewhere (overridable) in the user's home directory.


Initial idea for this really came from my dayjob too, we have macs but no way to centrally manage them. The client / server part for the declarative system manager I want to build on top of this is quite far out yet though. At least several months


IIRC the main reason here is that brew path is hardcoded during the build process of packages, which means that you wouldn't be able to use bottles.

I didn't check, but there is a chance that path is also hardcoded in (some) formulae, so even building from the source might not help here.


You could run the build process with chroot or inside Docker, so that the hardcoded paths actually resolve to a designated subdirectory.


Incidentally, that’s what is usually done in Nixpkgs in similar situations when there’s no better alternative, see buildFHSEnv et al.


In many cases the build output also has hardcoded paths unfortunately

so doing `brew install` inside a container with the proper volumes it’s not sufficient to fix the issue. Everything would have to run from within the container as well.


Nix effectively has per-user packages, but it’s hard to read into your full use case from your comment.


oh, I guess this is why the nix installer creates 32 macOS users called _nixbld$N



Not an aesthetic issue for bikes.


Well. Bike tires would also get replaced. So some puncture proof metal option would fix the problem.


I too look forward to my 200lbs puncture proof bike.


All those times I've seen managers pooh-pooh RAM upgrades for machines used by people whose salaries might be 250-500x the machine...


Signal has "message requests". iMessage doesn't have "message requests", and receives messages in a unique path which goes through the kernel.

Signal's message request, notably, also shows me the requester's avatar image. I don't know if that hits the kernel but it certainly hits code that as a category has suffered lots of security issues over the years. Which is to say: There's room for improvement all over!


That avatar thing is exploitable on discord, at least. Don't recall the specifics, just keywords.


You might be thinking of the minor Cloudflare exploit where the attacker can send you a message, then see on which Cloudflare PoP their profile image got cached.


I’d read that blog post!


Thanks for the suggestion, I may do that next month if I can remember enough of the details!


What’s that like? Fun? Annoying? Interesting? Boring?


All of the above; being a mid-career IC/TL with visibility into actual outcomes in prod has organically matured a deep respect for boring technology---warts and all---especially when cumulative NRE is well into 10-digit territory.

I'll be glad when legacy support hits EOL though, if only for the indirect consequence of unambiguously seperating wheat from chaff as we embrace a new tech stack approaching stability. Although it isn't the case, it sure has felt like we've been operating like cost center baggage these past few years.


Love what you're doing, I'm in batch 4!

Feedback: That 4x slot looks like it's closed on the end. Can we get an open-ended slot there instead so we can choose to install cards with longer interfaces? That's often a useful fallback.


I believe it tops out at 128, of which 96 can be used as GPU VRAM. Hoping AMD will open the memory floodgates on the next rev.


110 with Linux, but 256gb/s memory bandwidth.

The M3 Ultra seems strictly better but is also significantly more expensive.


110! Good to know, thanks for the info.


I've often heard embedded is a nightmare of slapdashery. Any tips for finding shops that do it right?


It's not foolproof, but I've found there's a strong correlation between product margin and the sanity of the dev experience.


There is inherent complexity and self-inflicted complexity, they tend to go hand in hand but self-inflicted complexity can be exacerbated in bad projects. A lot of embedded software is just inherent complex, cars for example.


A lot of times it is, but it's not your fault. It's the fault of vendors and/or third party code you have to use.


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: