jchw

29,512 karmajoined hace 11 años

Opinions are my own and not the views of my employer.

comments

hace 20 minutosdiscuss

Even Valve has its sins with questionable monetization, alleged anti-competitive practices, and of course DRM, it's just, for their size it's challenging to find companies that aren't much worse for these bullet points.

Still, a rare exception of a company that seems worth the openness of one's mind. It's pretty shameful that this alone is worthy of praise, even forgetting the things Valve does that are just generally positive.

hace 18 horasdiscuss

We need to stomp out this immediately: yes the style and patterns of your writing matter, not just the content. That would be true even if we weren't drowning in a flood of low effort crap, which we are. Writing is not just a set of facts devoid of any context in a vacuum. If your writing style sucks that absolutely takes away from any point you might wish to make.

But the specific problem with LLMs is that they waste your time: they appear to have substance and effort put in in a way that a bullshitting human could simply never accomplish because it would take too much effort to do so, defeating the point of not just putting in effort. For example, using an LLM to triage a production issue, it chugs through logs and stacktraces and outputs a completely wrong explanation, which gets copied and pasted into an issue. It's got everything that would indicate effort was put in: an explanation of exactly what is happening and why, with plenty of supporting information. The only problem is, it's made up and full of assertions that are false. Claude Fable just told me moments ago that a problem I was debugging was due to virtio-GPU giving back bad timestamps, confidently with an explanation of why. It wasn't and it isn't known to. Fine: I knew what I was getting. If someone copies and pastes an LLM explanation without context, I don't know what I'm getting, and LLM writing tells are the only way I can avoid shortening my lifespan spending time on things I should have been more skeptical about but my human senses failed to flag as suspicious.

When someone posts an article or github issue or PR and it's undisclosed LLM slop, then we have a problem. Again. These PRs, issues, articles look completely legit. Like this one:

https://github.com/KhronosGroup/MoltenVK/pull/2724

No bad intentions involved: the person just simply couldn't tell when the LLM was bullshitting it, and his PR passed the sniff test just enough to get merged and cause regressions.

So if something outright smells like LLM slop from the writing style, that's a bad sign. The author has probably not written most of the sentences as they are presented, which is hard to distinguish from them not having written them at all. If they had proofread the article, they would have hopefully also noticed the repetitive, annoying LLM writing style and fixed it. When they don't, it tells me one of two things:

1. They didn't really put that much effort in, OR

2. They seriously lack taste.

Neither option is really super good.

It's not good that we're allowing people to think this isn't an issue. It definitely is an issue. It will become a worse issue once someone figures out how to fix the LLM slop writing style in post training, because then we will no longer have any good signal that human effort was put in to any prose at all.

I'll leave my opinion about this specific article out of it because it's really not specifically about this article. I can only think of one reason for people to make these bad faith arguments in favor of ignoring the glowing red "I DID NOT PUT ANY EFFORT INTO THIS" signs LLMs currently leave all over your work, and that is hoping that the pathway stays open for yourself to use.

anteayerdiscuss

I have noticed that sometimes in lists I have had the "The ... Solution: ..." sort of repetition. It is probably pre-existing but now that LLMs overuse it I actually am trying to adapt my speech patterns to not, because patterns LLMs overuse quickly become very grating to me.

hace 3 díasdiscuss

The main reason I assumed you didn't is because you linked to Hanlon's Razor and explained it in a way that made it seem like you didn't think the other person knew.

I think it's true to some extent that a lot of the backdoors really are just stupidity, like debugging tools put into prod for convenience. Rather than suggesting that it is genuine malice, maybe the right thing to say is that for security, it doesn't matter whether or not it is malice for most purposes. If it did, it would give more incentive to do as much as possible to disguise malicious backdoors as mistakes.

hace 3 díasdiscuss

If you're using Kryoflux or a similar controller solution (and they mention several) it should bypass this problem since then the drive doesn't show up as a normal floppy drive at all. So in this case it shouldn't matter.

hace 3 díasdiscuss

Pretty sure the point was to invert it. :)

hace 5 díasdiscuss

You have now created four accounts to make basically this post, but the point is unclear. All of the highly automated theorem provers have some limitations to what they can guarantee, some of which comically strict. You are not really explaining how this operating on MIR makes it so distinctly useless/"fraudulent".

hace 5 díasdiscuss

First of all, can you just simply not speak in gotchas? I don't even like engaging with this sort of thing. It's a valid question to ask how VCS is the source of truth in this case, but the way you're responding suggests you're not interested in discussing it productively, just a shit-flinging where we argue semantics about what it means for something to be a source of truth, without regards to what the actual important implications are supposed to be. I'm going to try to interpret this in good faith but I feel like I'm probably wasting my time doing so.

Yes, the VCS is still the source of truth, ultimately nothing in the cache or sumdb exists without having existed in the VCS source first. The sumdb is an integrity mechanism bolted on top, and then the module proxy cache is an availability mechanism bolted on top.

Consider the following: let's say Kubernetes depends on some library you have Git access to. So you, being evil, rewrite the tag Kubernetes currently uses to contain malware. There are two possible scenarios:

- By default: the user is using a module cache, so changing a tag that already existed is no different than a Git host being pulled offline from the perspective of the user. The cache continues to serve the original source code, no malware delivered.

- The decentralized case: a user disables both sumdb and the module cache. Guess what? The pull fails. The pull fails because the project has a go.sum file and your tag doesn't match it.

Let's say someone compromised Google's sumdb or module proxy cache. Same basic thing: the go get will fail, because of the local integrity checks.

See, it really changes nothing. The module proxy cache essentially just ensures that a module source code that was once available remains available indefinitely so that you can continue to build old software exactly and securely.

The only place where behavior ever changes meaningfully (as in, not just "available or unavailable") is when go getting a new package or package update. If you have GOPROXY=direct, the poisoned fetch will fail because of global sumdb. If you disable that too, it may still fail because of local sumdb. But if not, you may get someone to pull your mutated tag. (And then the resulting go.sum would fail for other people.)

If you knew for absolute certain that nobody had ever pulled the package before, then theoretically mutating an existing tag would be safe. However, I call shenanigans on this: if you knew for sure nobody had ever pulled it, how in the world did it end up in the sumdb and module proxy cache? Granted, it may have been because of your own CI or something, but still, it stands to reason that this mechanism is introducing a highly desirable property. If a given tag was available once with a given source code I would want to be able to pull it again later and know it isn't tampered with.

In general, I have never seen it interpreted that the possibility of a stale cache changes what the canonical source of truth is. I've also never seen anyone argue that a lockfile changes the canonical source of truth. The Go sumdb being a global integrity mechanism does make it fairly unique, but I don't see it as being categorically different than the integrity checks from lockfiles, it's just that but across multiple users.

Even if you don't like Go's implementation particularly, I still think it is highly worth copying. You can always change a few things. Like for example, you could make module fetch operations not backed by a local checksum skip the global module proxy cache as a safeguard against the proxy itself, only allowing it to be trusted once you already have evidence that the sumdb and canonical source currently agree by virtue of already having a sum.

Sorry I have dropped another text wall, I don't have time to make it shorter. It will happen again.

(I realize that I have ranted in two directions here, but my intention was to 1. Argue that the properties introduced by the design are actually important and desirable, 2. Then argue semantics about whether it changes what one would consider to be the canonical source of truth, second mainly because I consider this to be unimportant. I mean it could be discussed further but, there really should be a point to it other than just semantics.)

hace 5 díasdiscuss

What's unique about Go is the lack of a centralized package repo. You are saying "I could point NPM to another registry". I am saying, Go doesn't have a registry and you can't really point it to one. I hope it is apparent that these are two extremely different statements. The fact that it is pinning source to source is just the approach that they take to get there.

And again, if you just bolted a solution onto the side of an existing ecosystem it wouldn't accomplish as much. "Technically this could be done elsewhere" is true, but I hope you know I know that. The point is that Go deployed a mostly decentralized package management solution to the entire ecosystem as the primary and essentially only way to manage packages with Go. You actually could approximate what Go does using NPM, sans the caching module proxy part, using VCS URLs as dependencies, but the "approximate" and "sans caching module proxy part" is doing some heavy lifting.

There isn't really anything that does what Go does exactly. The closest example to me is OCI images. Like Go modules, their identity is essentially a sort of URI. However, it isn't a language package manager and has fairly different challenges, and doesn't really seem to need the caching proxy stuff due to the relatively few registries (and running it would be very expensive due to image sizes.) So I stand by with my belief that what Go does here is pretty unique.

hace 5 díasdiscuss

To be honest with you, I don't know what you are suggesting. Piper is a more scalable Perforce clone. That's cool and all, but I don't see how it solves the problem that hosts can be unreliable and that data fetched from the internet can be changed later. Doesn't seem to me like there's anything a VCS itself can do to change this.

You maybe could invent a fully decentralized peer-to-peer VCS hosting system that uses Blockchain(TM) technology to ensure integrity, or something. But... You'd probably still want a cache, perhaps even moreso than before, for performance reasons, even if you really truly did solve the availability and integrity problems.

hace 5 díasdiscuss

Sure, you can tell your other package managers to pull a module from VCS, usually with some limitations and negative side effects. The Go module syste is not the same model. You can, for example, run an NPM proxy that caches locally, but what you're missing is that with Go, the proxy part is the centralized part. There is no NPM. There is no crates.io, no PyPI, no RubyGems, no Packigist, no PECL, no CPAN. The proxy's entire job is just to stand in for requests that would be made to individual VCSes using their original source repositories. The sumdb's entire job is to ensure that whether proxied or not, the source code you get isn't tampered with. The source of truth remains decentralized, in the individual VCSes.

With NPM, uv, composer, Cargo, etc. you can indeed choose to make your dependencies pull from VCS, but:

- Not having universal module proxies with caching means you will run into the usual problems. Repos can disappear, history can be rewritten, hosts can go down. Even if you invented an equivalent caching service, without making it an ecosystem default it won't achieve the same effectiveness as Go because less would be in the cache.

- Because it isn't an ecosystem standard, dependencies you pull would then still reference dependencies from centralized repos anyways, more or less defeating the point. You'd have to go and override every recursive dependency to really make it decentralized.

(And again, it usually comes with other downsides depending on the specific ecosystem. Performance is a big one, the module cache definitely helps make fetching dependencies in Go faster.)

Not having centralized package repos comes with its ups and downs, but the lack of one existing means there are a limited number of interesting attacks you can really pull in the Go ecosystem and they are heavily tamper-evident. You can try to poison the module cache with a given revision for a dependency with malicious code then overwrite it with an inoccuous commit, but this will probably be detected when someone (possibly in Nixpkgs or another packaging system) runs GOPROXY=direct and the sumdb doesn't line up. So the least noticeable thing you can really do is just leave your malicious code in the repo. Go also has the kind of nice property that fetching and building modules is supposed to be safe with untrusted code. That's pretty good, it would be hard to do better than that.

It also means there really isn't any central namespace to poison. You can still trick someone into downloading and using malicious software but you're mostly limited to doing it the old fashioned way. Again, hard to do much better than that.

While everyone has been losing their minds over supply chain issues, the Go ecosystem has been concerned but less so. It's still a huge risk still, dependencies can get compromised still, but attackers have no real central target to go after and get a bunch of damage at once. Nothing realistical, anyway. So, it's back to just trying to pwn individual GitHub repos.

hace 5 díasdiscuss

People keep replying seeming to miss what makes Go's solution so good. I think it deserves more attention.

In many cases I think it's impossible to avoid the pain that comes with decentralization without defeating the point. It's challenging because certain things are hard to do decentralized so it's easier to just give up and rely on central authorities and components.

When you install Go, it does just that, to some approximation; it will try to fetch from the module proxy first and fall back after that fails. But what makes Go different and more interesting is that you can just turn that off with no consequence. As long as all of the Git hosts are up, you can still use Go just fine with no proxy. I'm pretty sure Nix builds do this by default with Go so I believe most dependencies are usually online. That means the proxy approach and the decentralized approach are both fully redundant with eachother, while allowing the decentralized VCS hosts to remain the source of truth.

Go also separately has the sumdb to enforce immutability, so you can know that when you go grab a specific package that the tag name corresponds to one and only one exact source code. This is also optional, and even without it you get the benefit of local sum checking via your own cache and go.sum files in source checkouts. But having this be separate is great because it also means you could use another third party module proxy or a third party sumdb, or use just the sumdb and no proxy. It gives you many options to not have to rely on a single party while still getting some of the benefits of centralization.

Systems like this are rare. Many systems try very hard to have the cake and eat it too, but it usually fails somewhere. For me Go's approach works, and that is worth some attention.

hace 6 díasdiscuss

IMO a lot of these problems come down to the same root cause: we are not fully enumerating and reasoning about failure cases.

Let's say you want to retry a network request. It's... A bit more complex than it seems, right?

Firstly, you need to know exactly what type of error you ran into. Some errors aren't really recoverable. Maybe a programming issue occurred and you are constructing an invalid URL and the HTTP client is yelling at you. No sense in retrying that 20 times. Maybe it's a network error, that seems like a good candidate to retry. Maybe, the request succeeded and we have a response, but it is a 500 error, again, seems like a good candidate.

Secondly, you need to know if it is safe to retry. If the request is essentially idempotent, like a read-only GET request, then surely it is safe, right? But, what if it isn't safe? Forget about solutions like idempotency tokens; let's assume you don't control that. Now you need to figure out how you can know if the request had side effects. If a well-known 4xx error is returned you might know, but if you get a network error or a 5xx error it's much harder. Did the request fail during a buffered response after the side effects were already applied? Maybe you can check to see if the request applied with another request. Now you have two network requests, and both need error handling.

Finally, and probably most obviously, you have to make sure you don't hammer the server when it is under load. To avoid the thundering herd problem, you'll probably want to use an exponential backoff with some jitter.

What sucks about all of this is that while there are reusable components here, the concerns effortlessly cut through different layers, making them a pain in the ass to deal with. It isn't that it is impossible for a library to handle all of these problems (I anticipate an excited evangelist may reply explaining how their favorite library does it all in one package if this post gets enough visibility) it's just that this is hard and these problems repeat in different forms, in a way that makes it difficult to fully eliminate the repetition. And this is just the most obvious basics, whereas in reality there are almost always case-specific complexities.

You can, for example, encapsulate a reasonable exponential backoff with deadline implementation and apply that as appropriate for different things, but you can't really cheat your way out of having to think about all of these things, especially if you don't control all of the network APIs you might have to interface with.

This is one part of why I don't like try/catch exceptions. They are an appropriate mechanism to use as a failure isolation boundary due to their stack unwinding capability: it would still be bad in most cases if a logic error or upstream error not being handled properly in a single network request handler were able to crash an entire network server, so being able to blanket catch everything that bubbles up an log it is good. But then using this for normal error handling, it makes doing the wrong thing perhaps just a bit too easy. I don't think you should have to self-flaggelate in order to say "just crash if this errors", but I do think that you should have to say it. Try/catch exceptions are backwards by default, just write normal looking control flow and no errors are handled and it's hard to tell if there even are any. Checked exceptions try to fix this but somehow this feels even worse; now you have a flattened list of exceptions that may occur at various different layers of depth, in some cases the same exception can occur at different layers of depth, you may literally need to read source code and map out the call stack in your head to be sure. (Hope it doesn't change later.)

The Result or Expected type concept seems like the way to go in the frame of modern programming languages. Go's error passing also works OK though it has papercuts (that a linter can help you with, at least.) To me it makes more sense to make stack unwinding error handling a more niche feature used for isolating error domains, rather than use them for all error handling.

But even that! Even that doesn't solve the problem. You still have to sit there and think about the types of errors that can occur and their consequences. At best, explicit error handling with value types just encourages you to confront it and makes it visible, even in cases where you still say "OK, pass to caller".

hace 6 díasdiscuss

Knowledge should be free, but that can't be treated too literally. Not a unique case of this kind of phrase. If we're doing capitalism people have to be paid somehow, and when people say "free" they don't mean "absolutely". I mean, speaking of open source, consider "free" software.

Open source licenses are almost entirely unrelated. They're strictly a hack around the copyright system, and not only that, they literally do nothing other than grant you rights you wouldn't otherwise have. Talking about open source is mostly a distraction. When people say knowledge is free they almost always mean access to knowledge. Open source grants people access and more.

People are not mad that they can't just steal things, they're mad that access to things is tied behind massive gatekeepers (essentially indefinitely...) that essentially exist to continue to enrich themselves while somehow almost none of the money makes it back to the authors, and is sometimes completely untethered from where the money comes from that funds the works to begin with. You can't just freely navigate, search through and consume information, it's all tied up behind various pay walls and monetization schemes while authors starve anyways.

We could have a more equitable and reasonable system that allows broad access to knowledge while providing some approach to monetization that is reasonable for both people seeking it out and people consuming it. There's little point in trying to enumerate the number of ways it could be done. We already have a system for taxes, we already have seen commercial schemes like Spotify, you could slice it thousands of different ways. Plenty of pros and cons. I'm just saying it could be done and we know it could be done.

But it can never work if all media and knowledge dominated by rent seeking gatekeepers standing in the middle whose primary purpose will always be to enrich themselves first and foremost. They will always want to get more and give less, because that is more or less their fiduciary duty.

hace 9 díasdiscuss

There will always be more suspend/resume bugs to work through. It varies a lot per device. I feel it's necessary to paint the picture for people who are curious what it means for it to be a crapshoot, so indulge me while I share my experiences.

For work I have a ThinkPad T16 Gen 4 with the newer AMD gfx1151 iGPU. Works great. I have yet to witness any issues with suspend/resume. I suspect this is the case because it is running Ubuntu with Lenovo's own support package. Theoretically, from firmware to kernel, this is all tested and validated by Lenovo, like what certainly happens with every Windows laptop and all of the components that go into them.

I also have a gen 1 Framework 16. I have seen it crash on suspend, but it is pretty rare, so I've just shrugged it off for now. It would be hard to debug, I don't see it every month despite using the thing every day.

All of my desktops currently have perfectly reliable suspend resume, you can slam it all day and all night. The last time I ran into issues was a use-after-free issue in AMDGPU. Pretty alarming, although to be clear it never hit any LTS or vendor kernels that I am aware of. I hit it because I prefer to run the latest kernel on my personal machines.

I have certainly owned laptops where suspend basically didn't work, or it would not stay suspended. I think this mainly went away when I started specifically picking laptops for Linux support.

For Intel iGPUs and dGPUs, the track record has been flawless for me. I have a few of the new Battlemage cards that default to the xe kernel driver and those have been working very well as expected. So that's nice.

I don't think this situation will be fixed until more hardware vendors are taking part in validating their stuff on desktop Linux and keeping track of the kernels. The current Linux model seems to be just dealing with whatever the vendors crap out for Windows, often full of weird ACPI behaviors and buggy firmware. It's not to say that the fault of the problems don't often lie with code in the Linux kernel, but they do not seem to wish to be bug-compatible with Windows and I think that is perfectly reasonable, so for problems that come from essentially broken firmware, it simply is going to need vendors to actually fix their shit.

(And that includes AMD. The drivers are good in some regards, but it's hard to ignore AMD's stability issues even still. At this rate, more of the long outstanding AMD driver issues will get resolved by Claude than AMD engineers... Like with Panel Self Refresh on 7040 iGPU, apparently.)

hace 9 díasdiscuss

I think that article is rather a copy of the original Google Doc, judging by the included go link.

hace 10 díasdiscuss

Unfortunately, it would seem the majority of dems are just jealous that they don't have the chutzpah to be so flagrantly, blatantly corrupt, and stick to less lucrative and more established corrupt practices.

See, discussions like this go nowhere productive, but it's not because the people are incapable of productive discussion, or because the subject matter is incapable of being discussed productively. It's just that there's literally nothing productive to say about this complete and utter fuck show. We live in a world where the most accurate prediction of the world 10 years from now is current-day satire. There is nothing sensible to be said about the state of affairs of politics.

hace 11 díasdiscuss

American AI company status: We are now bragging about how bad our models are unironically.

Okay.

hace 12 díasdiscuss

Sure research rigor and reproducibility are known issues but if we're gonna complain about the study design it may as well actually take into account the study design. Seems like the biggest complaint W.R.T. study design is just the lack of a good control. Seems like it makes the case for something to do with gut health but then fails to definitively stomp out the placebo effect.

hace 12 díasdiscuss

Should be close enough, at most a few milligrams IIRC, certainly less than a can of coke. Does coffee actually contain any other stimulant in more than trace amounts?