HackerTrans
TopNewTrendsCommentsPastAskShowJobs

GeneralMayhem

no profile record

comments

GeneralMayhem
·hace 28 días·discuss
Is your argument that anyone saying "there should be laws about this" should spell out "and we mean actual laws, not arbitrary misapplication of existing law by one petulant executive"? I don't know how they could have been more clear - they've suggested industry-wide regulation and even what shape that could take.
GeneralMayhem
·hace 2 meses·discuss
Accepting your dichotomy for the sake of argument, I'm in camp 1, but camp 2 could still be humane and comprehensible. Many countries have strict immigration rules, and while I disagree with that philosophy, it's not necessarily objectionable in the same way.

The Trump administration is not in camp 2.

The Trump administration, as this rule clearly illustrates, is in camp 3: Those who believe that the people who are not currently citizens of your country should never be able to become so, and should be punished for even trying.

The problem is not that the system is "strict" in the sense of holding an incredibly high bar. The problem is that the system is arbitrary - there is no process you can follow that will give you a high degree of confidence that you'll be allowed to enter, or even that a decision _will be made at all_ in a fair manner, no matter who you are (unless you're a personal friend of the administration) - as opposed to you being randomly arrested by ICE halfway through waiting for a decision. And even if there were such a process, you would have no confidence that it wouldn't change retroactively in another week.

It is laughably naive to believe that they are doing this in good faith out of any sense of strictly filtering immigrants. There's exactly one explanation that isn't transparently pretextual, and you and I both know what it is.
GeneralMayhem
·hace 2 meses·discuss
Oh... that's embarrassing. Honest mistake, I swear.
GeneralMayhem
·hace 2 meses·discuss
In FY25, according to their budget [1], TriMet - the Portland public transit authority - spent $19M on bus services.

In that same budget, PDOT spent $56M on streets, signs and streetlights, before you even consider the $242M spent on "asset management" - which appears to generally be capital improvements; i.e., rebuilding roads [2, page 509].

I don't care what fraction of that wear and tear is due to buses, it's not remotely close. And in any case, by the same fourth-power law, private 18-wheelers do astronomically more damage than buses.

And yes, PDOT makes revenue back from some of those things, so it's not all straight from the city general fund, but it doesn't matter in any practical way. They don't have revenues broken down as far as I'd like on that budget - there's one big $89M line item for "charges for services", which appears to include parking meters as well as tram fare - but the vast majority of their budget still comes from taxes plus "intergovernmental" sources (aka state and federal money, aka taxes).

[1] https://www.gpmetro.org/wp-content/uploads/2025/01/2025-Oper... [2] https://www.portland.gov/budget/documents/fy-2025-26-city-po...
GeneralMayhem
·hace 2 meses·discuss
If you only wanted to run buses, you would not build nearly as many roads as we do.
GeneralMayhem
·hace 2 meses·discuss
> by simple virtue of being a car

State and local governments spend a truly obscene amount of money building and repairing roads, and set aside a nauseating amount of publicly owned land to serve as roads, street parking, and parking lots. Those of us who don't frequently drive get some benefit from the roads, sure, because of the efficiencies of shops needing deliveries and whatnot, but not anything close to proportional to what drivers get out of it. And we accept this as the default way that things should be, whereas we assume that public transit needs to "pay for itself".
GeneralMayhem
·hace 3 meses·discuss
Right, but the impressive part is finding addresses that are actually on different memory channels.
GeneralMayhem
·hace 5 meses·discuss
> My current thinking is that queues don’t increase average throughput. Instead, they act as buffers that absorb short-term bursts and timing differences between senders and receivers

Absorbing bursts is one purpose for a queue, but often not the only or even most important one. Other reasons include:

Correctness reasons:

* Providing a durable history of requests that were sent

* Creating at-least-once semantics for important (e.g. financial) data

Scaling reasons:

* Allowing a shuffle between producer and consumer to change shard/key affinity (can be done with direct RPCs, but would need extra library support)

* Pipelining variable-cost requests so that consumers can self-rate-limit and stay optimally loaded
GeneralMayhem
·hace 6 meses·discuss
Do you take down all of your projects and then bring them back up at the new version? If not, then you have times at which the change is only partially complete.
GeneralMayhem
·hace 7 meses·discuss
Same here. I've worked on one project that used code generation to implement a DSL, but that would have been the same in any implementation language, it was basically transpiring. And protobufs, of course, but again, that's true in all languages.

The only thing I can think of that Go uses a lot of generation for that other languages have other solutions for is mocks. But in many languages the solution is "write the mocks by hand", so that's hardly fair.
GeneralMayhem
·hace 7 meses·discuss
Really only prefixes, without a significant loss in accuracy. The point is that because later tokens can't influence earlier ones, the post-attention embeddings for those first tokens can't change. But the post-attention embeddings for "and then tell me what" would be wildly different for every prompt, because the embeddings for those tokens are affected by what came earlier.

My favorite not-super-accurate mental model of what's going on with attention is that the model is sort of compressing the whole preceding context into each token. So the word "tell" would include a representation not just of the concept of telling, but also of what it is that's supposed to be told. That's explicitly what you don't want to cache.

> So if I were running a provider I would be caching popular prefixes for questions across all users

Unless you're injecting user context before the question. You can have a pre baked cache with the base system prompt, but not beyond that. Imagine that the prompt always starts with "SYSTEM: You are ChatGPT, a helpful assistant. The time is 6:51 ET on December 19, 2025. The user's name is John Smith. USER: Hi, I was wondering..." You can't cache the "Hi, I was wondering" part because it comes after a high-entropy component (timestamp and user name).
GeneralMayhem
·hace 7 meses·discuss
Go with Bazel gives you a couple options:

* You can use gazelle to auto-generate Bazel rules across many modules - I think the most up to date usage guide is https://github.com/bazel-contrib/rules_go/blob/master/docs/g....

* In addition, you can make your life a lot easier by just making the whole repo a single Go module. Having done the alternate path - trying to keep go.mod and Bazel build files in sync - I would definitely recommend only one module per repo unless you have a very high pain tolerance or actually need to be able to import pieces of the repo with standard Go tooling.

> a beefy VM to host CI

Unless you really need to self-host, Github Actions or GCP Cloud Build can be set up to reference a shared Bazel cache server, which lets builds be quite snappy since it doesn't have to rebuild any leaves that haven't changed.
GeneralMayhem
·hace 7 meses·discuss
> if updating that shared library automatically updates everyone and isn’t backward compatible you’re doing it wrong that library should be published as a v2 or dependents should pin to a specific version

...but why? You're begging the question.

If you can automatically update everyone including running their tests and making any necessary changes to their code, then persisting two versions forever is a waste of time. If it's because you can't be certain from testing that it's actually a safe change, then fine, but note that that option is still available to you by copy/pasting to a v2/ or adding a feature flag. Going to a monorepo gives you strictly more options in how to deal with changes.

> You literally wouldn’t be able to keep track of your BOM in version control as it obtains a time component based on when you built the service

This is true regardless of deployment pattern. The artifact that you publish needs to have pointers back to all changes that went into it/what commit it was built at. Mono vs. multi-repo doesn't materially change that, although I would argue it's slightly easier with a monorepo since you can look at the single history of the repository, rather than having to go an extra hop to find out what version 1.0.837 of your dependency included.

> the version that was published in the registry

Maybe I'm misunderstanding what you're getting at, but monorepo dependencies typically don't have a registry - you just have the commit history. If a binary is built at commit X, then all commits before X across all dependencies are included. That's kind of the point.
GeneralMayhem
·hace 7 meses·discuss
Internal and external have wildly different requirements. Google internally can't update a library unless the update is either backward-compatible for all current users or part of the same change that updates all those users, and that's enforced by the build/test harness. That was an explicit choice, and I think an excellent one, for that scenario: it's more important to be certain that you're done when you move forward, so that it's obvious when a feature no longer needs support, than it is to enable moving faster in "isolation" when you all work for the same company anyway.

But also, you're conflating code and services. There's a huge difference between libraries that are deployed as part of various binaries and those that are used as remote APIs. If you want to update a utility library that's used by importing code, then you don't need simultaneous deployment, but you would like to update everywhere to get it done with - that's only really possible with a monorepo. If you want to update a remote API without downtime, then you need a multi-phase rollout where you introduce a backward-compatibility mode... but that's true whether you store the code in one place or two.
GeneralMayhem
·hace 7 meses·discuss
I worked on building this at $PREV_EMPLOYER. We used a single repo for many services, so that you could run tests on all affected binaries/downstream libraries when a library changed.

We used Bazel to maintain the dependency tree, and then triggered builds based on a custom Github Actions hook that would use `bazel query` to find the transitive closure of affected targets. Then, if anything in a directory was affected, we'd trigger the set of tests defined in a config file in that directory (defaulting to :...), each as its own workflow run that would block PR submission. That worked really well, with the only real limiting factor being the ultimate upper limit of a repo in Github, but of course took a fair amount (a few SWE-months) to build all the tooling.
GeneralMayhem
·hace 8 meses·discuss
"Ignoring the code entirely and only prompting" is the only definition of vibe-coding I'm aware of. It's from a Karpathy tweet (https://x.com/karpathy/status/1886192184808149383):

> There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists... I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension.

It specifically doesn't mean "using an LLM as a code assistant". It definitely doesn't mean asking the LLM questions about code which you'll then use to write your own code. Those are LLM-assisted activities, and it's totally fine if you're using the LLM that way. But it's not what the term "vibe coding" means. "Vibe coding" is giving up on any pretense that you're in control, and letting the LLM take the wheel. It's fun for getting quick projects done, but it's also now becoming a distressingly common practice for people who literally do not know how to program in order to get a "product" to market.
GeneralMayhem
·hace 8 meses·discuss
Turning around a track definitely dissipates some heat energy through increased friction with the rails. Imagine taking a semicircle turn and making it tighter and tighter. At the limit, the train is basically hitting a solid wall and rebounding in the other direction, which would certainly transfer some energy.

The energy question is this: going from a 100kmh-due-north momentum to a 100kmh-due-south momentum via slowing, stopping, and accelerating again clearly takes energy. You can also switch the momentum vector by driving in a semicircle. Turning around a semicircle takes some energy, but how much - and where does it come from? Does it depend on how tight the circle is - or does that just spread it out over a wider time/distance? If you had an electric train with zero loss from battery to wheels, and you needed to get it from going north to going south, what would be the most efficient way to do it?
GeneralMayhem
·hace 9 meses·discuss
I like natural keys... if you can prove that they're actually immutable and unique for the thing they're representing. Credit card number is a decent natural key for a table of payment instruments, not for users. Even for a natural-key-believer, users pretty much always need a synthetic ID, because anything you might possibly believe to be constant about humans turns out not to be.
GeneralMayhem
·hace 10 meses·discuss
I hadn't thought about GitHub -I'm guessing the authors of the bill didn't either - but you're right, that is somewhat concerning. Still, I don't think it's the end of the world...

> The requirement is also that developers will request the signal. No scoping to developers that have a reason to care?

I don't see that requirement. Here's the sum total of the developer's responsibilities (emphasis added):

> A developer with actual knowledge that a user is a child via receipt of a signal regarding a user’s age shall, to the extent technically feasible, provide readily available features for parents to support a child user with respect to the child user’s use of the service and as appropriate given the risks that arise from use of the application, including features to do all of the following:

> (A) Help manage which accounts are affirmatively linked to the user under 18 years of age.

> (B) Manage the delivery of age-appropriate content.

> (C) Limit the amount of time that the user who is 18 years of age spends daily on application.

It would be nice if it had specific carve outs for things that aren't expected to interact with this system, but it seems like they're leaving it up to court judgment instead, with just enough wiggle room in the phrasing to make that possible.

If your application doesn't have a concept of "accounts", then A is obviously moot. If you don't deliver age-inappropriate content, then B is moot. The only thing that can matter is C, but I'd expect that (a) nobody is going to complain about the amount of time their kids are spending on Vim and (b) the OS would just provide that control at a higher level.
GeneralMayhem
·hace 10 meses·discuss
It's always possible that they'll say it, but it would be a lie based on my reading of this bill. Sideloaded apps can choose whether or not to respect the OS's advice about the age of the user, it's not on the OS or device to enforce them being honest.