HN2new | past | comments | ask | show | jobs | submit | curt15's commentslogin

What recourse does one have if Google simply revokes the permission it granted?

checksums + tarballs don't help with runtime integrity verification. You'll need additional technologies for that like dm-verity or fs-verity; see composefs.

Red Hat obviously wants to change people's vocabulary but "Dockerfile" is basically an industry-standard generic term by this point.

That is true, the same for "to google" if people mean "to search". It does bury the generality of the concept though. Like I said, a nitpick.

I think it's also worth noting that the Dockerfile format is still driven by Docker, and there have been zero extensions to the format by Podman folks, so Containerfile==Dockerfile.

It's a distraction only if people let themselves be distracted.

>Most of us are going to start transferring skills to more of a prompt programming and coordinator role.

Human code reviews and in-depth understanding of architecture remain important even for codebases with comprehensive test suites because treating a computer program solely as a black box does not allow one to reason precisely about the program when it encounters general inputs. Relying solely on black box testing simply offloads more QA to production users.

In a future world where humans rely entirely on machines to interpret their ambiguous instructions, who does the checking and what do the checks involve?


It's not the federal government's job to police ideology. That's the stuff of Communist China's cultural revolution. There's nothing stopping people from creating their own university teaching "correct" ideology. The US has no shortage of well-resourced individuals and organizations spanning the entire spectrum of political viewpoints.


That has been going since forever. McCarthy is just one blatant example, it happened in the 20s, and 30s, and 40s 50s and 60s and 70s and all the way to today.


Brew got one thing right that no Linux package manager seems to emulate: it doesn't require root for normal operations and even goes so far as to error out if running as root (https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad).


"let's allow any user process to modify my binaries" is not something to be proud of...



It needs world-writtable /opt/homebrew, so I guess a Linux equivalent would be Nix (which IIUC requires writable /nix).

For something that only uses your home folder, I recommend checking out mise https://mise.jdx.dev/


In multi-user mode, Nix uses dedicated build users to write to the store. There is also single-user mode, but that also doesn't require a world-writable store.


Or just homebrew on Linux?


Brew _is_ a linux package manager.

There is also conda/mamba/pixi/etc. (anything in the conda-forge ecosystem) that can be used without root. Then there are Guix and nix, which (mostly) require to be set up by someone with root privileges, but which then allow unprivileged users to install packages for themselves. I think I have even used emerge rootless-ly at some point a few years ago.


Brew is so full of Linux/OSS/GNU anti-patterns that I can't wrap my head how did it ever managed to receive so much adoption. I guess macOS people are way more ignorant about things that made Linux/OSS what it is.


It doesn't help that the project authors shut down any conversation about flaws.

They're so convinced that their way is right and essentially stick their fingers in their ears when anyone raises concerns.

Unfortunately cargo culting is a thing.

I say this as a macOS user.

Fortunately alternatives like MacPorts exist.


Absolutely this. I can't but think that brew is an extension of author(s) ego. Remember that essay about them failing to get a job at Apple?


Can you give some examples?


Updating all of your installed packages when you ask it to install a new one. This is so utterly ridiculous that it singlehandedly nade me stop using brew. I can't imagine what other bad decisions they make if this is what they thought was a good one.

Another fact is that it's basically like AUR, with little to no oversight. If AUR had malware then just imagine how much malware is there in brew recipes.

They also didn't use cryptographic signing for the longest time, they did get some shit for that.

There were more, can't remember now.

One other thing that seriously annoys me is the automated closure of reported issues after they get no response for a while. So I reported maybe 3 bugs and then I stopped altogether, because why would you waste your time on a project that doesn't respect it? All these bugs were actual full blown bug reports, well written and researched. I can't but think that projects that close issues like that are made to look better than they are.

Also, you guys remember when its author ranted about not having gotten a job at Apple? I always thought they cared about the prestige of that project more than the actual project, based on the level of security shortcomings. Brew has that serious amateurish taste to it.


>To many users, an app seems to be perceived as the blessed way to access the web. While on a mobile, they are mostly a way to organize symlinks or bookmarks. Except, off course a web browser does its best to protect the user while most apps don't.

That is an education problem. What do school computer courses teach these days? Do schools even have computer literacy classes anymore? Do they still teach students about the internet?


> At the end of the day, as long as the owner of the hardware gets to control the keys, this seems like fantastic tech.

The problem is that there are powerful corporate and government interests who would love nothing more than to prevent users from controlling the keys for their own computers, and they can make their dream come true simply by passing a law.

It may be the case that certain users want to ensure that their computers are only running their code. But the same technologies can also used to ensure that their computers are only running someone else's code, locking users out from their own devices.


That's like saying we shouldn't build anything that can be used for good if it can also be used for evil.

By that logic, we should just turn off the internet. Too much potential for evil there.

More seriously, the argument being presented seems to just be "attestation tech has been used for evil in the past, therefore all attestation tech is bad," which is obviously an unsound argument. A sound argument would have to show that attestation tech is _inherently_ bad, and I've already provided examples that I think effectively counter that. I can provide more if needed.

I get that we want to prevent attestation tech from being used for evil, but that's a regulatory problem, not a technical one. You make this point by framing the evil parties as "corporate and government interests."

Don't get me wrong, I am fully against anything that limits the freedoms of the person that owns the device. I just don't see how any of this is a valid argument that Amutable's mission is bad/immoral/invalid.

Or maybe another argument that's perhaps more aligned with the FOSS ideology: if I want e2e attestation of the software stack on my own devices, isn't this a good thing for me?


>if I want e2e attestation of the software stack on my own devices, isn't this a good thing for me?

The building blocks are already there for a sufficiently motivated user to build their own verified OS image. Google has been doing that with ChromeOS for years. The danger I see is that once there is a low-friction, turnkey solution for locking down general purpose systems, then the battle for control over users' devices reduces to control over the keys. That is much easier for well-heeled interests to dominate than outlawing Linux outright.

The status quo is a large population of unverified but fully user-configurable systems. While the ideal end state is a large population of verified and fully user-configurable systems, it is more likely that the tools for achieving that outcome will be co-opted by corporate and political interests to bend the population toward verified and un-configurable systems. That outcome would be far worse than the status quo.


Attestation tech is much more useful for evil than for good.


> The models we have in mind for attestation are very much based on users having full control of their keys.

If user control of keys becomes the linchpin for retaining full control over one's own computer, doesn't it become easy for a lobby or government to exert control by banning user-controlled keys? Today, such interest groups would need to ban Linux altogether to achieve such a result.


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

Search: