> [T]he war on general computing and computer ownership [...] It is exhausting to see the hatred some have for people just owning their hardware.
The integrity of a system being verified/verifiable doesn't imply that the owner of the system doesn't get to control it.
This sort of e2e attestation seems really useful for enterprise or public infrastructure. Like, it'd be great to know that the ATMs or transit systems in my city had this level of system integrity.
You argument correctly points out that attestation tech can be used to restrict software freedom, but it also assumes that this company is actively pursuing those use cases. I don't think that is a given.
At the end of the day, as long as the owner of the hardware gets to control the keys, this seems like fantastic tech.
> You argument correctly points out that attestation tech can be used to restrict software freedom, but it also assumes that this company is actively pursuing those use cases. I don't think that is a given.
Once it's out there and normalized, the individual engineers don't get to control how it is used. They never do.
You want PCIe-6? Cool well that only runs on Asus G-series with AI, and is locked to attested devices because the performance is so high that bad code can literally destroy it. So for safety, we only run trusted drivers and because they must be signed, you have to use Redhat Premium at a monthly cost of $129. But you get automatic updates.
Do you want the control systems of the subway to get modified by a malicious actor? What about damn releases? Heat pumps in apartment buildings? Robotaxis? Payroll systems? Banks?
Amutability is a huge security feature, with tons of real world applications for good.
The fact that mega corps can abuse consumers is a separate issue. We should solve that with regulation. Don't forsake all the good that this tech can do just because Asus or Google want to infringe on your software freedoms. Frankly, these mega corps are going to infringe on your rights regardlessly, whether or not Amutable exists as a business.
System integrity also ends at the border of the system. The entire ecosystem of ATM skimmers demonstrates this-- the software and hardware are still 100% sanctioned, they're just hidden beneath a shim in the card slot and a stick-on keypad module.
I generally agree with the concept of "if you want me to use a pre-approved terminal, you supply it." I'd think this opens up a world of better possibilities. Right now, the app-centric bank/media company/whatever has to build apps that are compatible with 82 bazillion different devices, and then deal with the attestation tech support issues. Conversely, if they provide a custom terminal, it might only need to deal with a handful of devices, and they could design it to function optimally for the single use case.
> 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.
> Please just let me end rules with a trailing comma instead of a period, I'm begging you.
The reason Prolog doesn't support trailing commas is exactly the same reason JSON doesn't support trailing commas: the language is designed to be parsed by an operator precedence parser, and the comma is an infix operator.
The fact that Prolog is a purely operator precedence syntax, with a dynamic operator table, allows you to build DSLs embedded in Prolog. CLP(FD) uses this to create the #= operator.
Generally speaking, Prolog syntax is ridiculously simple and uniform. Its pattern matching is the most universal of any programming language partly because of this.
As I understand it, if the metadata is lost then the whole filesystem is lost.
I think this is a common failure mode in filesystems. For example, in ZFS, if you store your metadata on a separate device and that device is destroyed, the whole pool is useless.
It's not really different than downloading a .msi or .exe installer on Windows and running it. Or downloading a .pkg installer on macOS and running it (or running a program supplied in a .dmg). Or downloading a .deb or .rpm on Linux and running it.
It's all whether or not you trust the entity supplying the installer, be it your package manager or a third party.
At least with shell scripts, you have the opportunity to read it first if you want to.
It is genuine human artwork, designed to look like generative AI. The retweet by the Apple TV account clearly ties the artwork to the show Pluribus, whose themes are relevant to the current societal discussions around gen AI.
All of this has clearly gone over Gruber's head.
It is quite funny that Gruber has enough of an opinion about this artwork to make a blog post about it, while at the same time completely missing the point.
> It is genuine human artwork, designed to look like generative AI.
That would be stupid and disrespectful. Stupid because no one is asking for real art to have subtle mistakes to look like AI, that’s a market segment which does not exist. Disrespectful because Vince Gilligan (creator of Pluribus) is outspoken on his disdain for the current crop of AI, and each episode of the show ends with “this show was made by humans”.
It's funny hearing someone talk about "market segment" in art.
Blurring the line between gen AI and human painting definitely seems in line with the show. Especially since only a human can actually produce art with intent.
It doesn't look like AI because the artist wants to promote gen AI. It looks like gen AI because that's a way for the artist to comment on these issues. Being explicitly made by a human is an important part of that.
I don't see how that's at odds with Gilligan's disdain for gen AI. If anything, I see the piece as being well aligned with that.
> It's funny hearing someone talk about "market segment" in art.
Why? Art has a long tradition of being coupled with commerce. Michelangelo didn’t paint the Sistine Chapel for free. Social media is still full of artists open for commissions. Even Patreon creators have specific markets, the people who are interested in their work. There’s nothing odd or incongruent about it.
> It looks like gen AI because that's a way for the artist to comment on these issues.
I think you’re reading too much into it and inventing the symbolism. We don’t even know who the supposed artist is (we have a name but zero links for confirmation). The mistakes that let us know its AI are too subtle (package referencing incompatible types of milk, maze which goes nowhere) to communicate those ideas. Given the current climate and Gilligan’s outspokenness, I think it’d be doubly stupid if the alleged artist had tried to make that statement in such a way.
All that said, we all have the incomplete history, so it’s at least possible that you’re correct (though I firmly believe you’re not) and we can’t know for sure without more information. I want to make it absolutely clear that when I use the word “stupid”, I’m referencing the actions of the people who would’ve followed the actions you describe, in no way is it pointed at you directly.
There are tons of test suites so if the tests pass then that provides a reasonable guarantee of correctness. Although it would be nice if there was also proof of correctness for the compilation from CUDA to AMD.
Same algorithm in Rust finds 2172315626468283465 in about 3 seconds on my M1 Pro.
$ time cargo run --release
Finished `release` profile [optimized] target(s) in 0.02s
Running `target/release/p45`
0
1
40755
1533776805
57722156241751
2172315626468283465
cargo run --release 2.95s user 0.04s system 98% cpu 3.029 total
Changing the Integer to Int in the Haskell program (use machine integers instead of bignums) speeds the 6 minutes to 35 seconds, fwiw. But that was only ok to do after knowing that the result would fit in a machine int. This is on an i5-3570 which is a bit over half the speed of the M1 Pro (Passmark score 2042 vs 3799). So it scales to around 18 sec on similar hardware. Not too bad given the list-based implementation, I guess.
Neat! I translated my code to Rust line-for-line and the iterator approach significantly outperforms it.
Rust newbie q - why use `x.wrapping_sub()` instead of regular old `x - 1`? Seems like we're never going to underflow `usize` for any of the 3 formulae?
I don't use Rust at all, but if compiler warnings are set to maximum, I'd want subtracting anything from a usize to give a warning unless the compiler can verify that the result is a valid usize. BTW, OEIS A014979 gives a linear recurrence for triangular-pentagonal numbers, so filtering for hexagonals gives a much faster way to do this problem. There may be a recurrence that does all three at once, not sure.
Free software is a value prop, not a law. And it is counter to the value prop that one entity is entirely responsible for all of the software (even if Apple doesn’t write every line of code, they are responsible for every bit that ships).
Not everyone cares about the bits. It’s true that the vast majority of consumers prefer having a single supplier to having freedom to run their own bits.
By that same logic consumers can't replace the os on PCs so consumers don't own PCs either. Customizing things manually is not always easy and user friendly. Easy customization is another feature products can offer.
The integrity of a system being verified/verifiable doesn't imply that the owner of the system doesn't get to control it.
This sort of e2e attestation seems really useful for enterprise or public infrastructure. Like, it'd be great to know that the ATMs or transit systems in my city had this level of system integrity.
You argument correctly points out that attestation tech can be used to restrict software freedom, but it also assumes that this company is actively pursuing those use cases. I don't think that is a given.
At the end of the day, as long as the owner of the hardware gets to control the keys, this seems like fantastic tech.
reply