What do you mean when you say "men who pretend to be women"?
I understand this is a fraught question, and I'm not trying to be snide or score points. Given the specifics of the post you're replying to, I think that's a germane thing to clarify here.
6,028 karma · joined June 30, 2017
he/him
github.com/zbentley
blog.zacbentley.com
I understand this is a fraught question, and I'm not trying to be snide or score points. Given the specifics of the post you're replying to, I think that's a germane thing to clarify here.
You'll note that all those things are still there, and their competitors are either not there or not significantly bolstered by people disgruntled by those changes.
I think well north of 90% of people in software engineering have job expectations that, when assisted/automated with AI, boil down to exactly that.
It's a pain in the ass to work at such a job and find challenges or things to master--your superiors don't want you to do that, there's not enough time in the day, and you're tired from LGTM-now-make-this work.
That's most software jobs, because that's what most software companies want.
Very true, I’ve procrastinated on fixing that for too long.
> I don’t want to live in such a society.
You kind of already do, but kind of don’t. Coercive politics still rule, but countries with strong civil liberties protections allow less harmful forms of coercion. Under strongman rule, coercion looks like the threat of murder. Under a liberal democracy, coercion looks like blocking traffic. That’s a big improvement.
Positive incentives (bribery and upside) also play a role opposite coercion. But “dialogue” absent self interested or dominance-oriented goals is a much less significant influence—unless you loosen the definition of dialogue to include things like “I convince you that it’s in your interests to vote for X so that protestors stop blocking traffic”, at which point there’s no distinction between the concepts.
There are good examples out there for minimal, straightforward blog design. This ain’t it.
I worry that the availability of this path will be extremely unevenly distributed, amplifying existing educational gaps along class, race, and language-proficiency lines.
That might be better than a forced average denominator, but the social effects of further amplifying those gaps are pretty severe and don’t take that long to happen. Combine that with the fact that education isn’t like new miracle drugs, where improvements inevitably tend to become more and more widely available to different groups, and I’m not as optimistic about the future.
“Ow, the gas pedal is actually a bear trap.”
“Why are you complaining? It’s free!”
Why did interest rates matter to Apple, a company famously averse to extended or significant borrowing?
Also, as we’ve seen in the case of DHH and others (https://drewdevault.com/weird-guys should not be taken as gospel, but it’s certainly a reasonable place to start), public figures have a tendency to move their “personal” business more towards their professional/public platform.
The SEC exists. As do many other mechanisms by which the government regulates direct and brokered securities trades and sales. You can make the case that some of those controls are poorly/ineffectively implemented, but you can’t claim that it’s not something the government routinely regulates, intervenes in, and sometimes prohibits outright.
But "racist state officials did voter suppression" is a different failure mode of the system than "data system corrupted registrations and now they're scrambling to fix the damage".
The malicious-officials problem has fixes like "vote people out" and "decommission harmful programs" and "restore cut funding".
The busted-data-system problem has fixes like "national ID card system" or "remove regulations preventing effective data sharing" or "hold system implementors responsible for failures".
If you see the disenfranchisement/conspiracy of the former in the bureaucratic/tech debt of the latter, you'll fix the wrong problems in the wrong ways, and make things worse.
I have trouble believing that, given that the "design", such as it is, took place over many decades of inter-agency regulatory/technical wrangling and organic growth.
At different times and points, the people that built what we think of as "the voting system" had totally different goals. Sometimes those goals were "make sure everyone eligible can vote as easily as possible"--and that's laudable! But more often the goals were "build $niche_system_component to comply with $specific_regulation". The number of times, during the design phase, where the people planning actually wanted to suppress votes and were empowered to make a part of the system actually do that was probably a rounding error compared to times when people fully accidentally moved the system in that direction due to bureaucratic myopia and shitty implementation.
I'm all for blaming political actors for things they intentionally do that are bad! Defunding the EPA? Bad! Getting into stupid wars? Bad! Banning mail-in voting? Bad! People with power and pre-meditated goals did those things, and many more, and should be opposed for it.
But "voting system is broken due to bureaucratic inter-operation failures, and state government staff have to do a postmortem and data recovery (ballot reprocessing)" isn't one of those times.
And plenty of that headwind is not coming from the "party of small government"! The refrain of "the government should not have centralized data it can use to infringe on my rights" often transcends party, depending on what issue is at hand. That's sometimes a reasonable position to hold, but it definitely has a cost, especially when taken to extremes, or when make-citizen-services-work-better initiatives are framed as spying or whatnot.
No. There's a lot more nuance there than you'd think, in the "broken regulatory and technical processes" domain, not political issues.
Example questions with unsatisfactory (not "impossible to do well", just "broken due to decades of technical and regulatory debt") answers: what government agencies, plural, are the authority of who is a citizen? Do they all agree? Do they provide ways for different agencies to check identities against their registries? If so, how do they match information in a citizenship-check request against their internal systems? By name? If so, how do they handle different name spellings (marriages, name changes, present/omitted middle names, non-ASCII)? By some other identifier? If so, how do they validate uniqueness of that identifier (SSNs are not secure/are widely leaked for tens of millions of people, addresses change and can have multiple residents, not everyone has a passport number, state-issued IDs/drivers licenses aren't stored centrally by the federal government)? If a check-requested identifier is invalid, can they tell whoever requested the check why it's invalid? Do these validation requests happen in real time/one at a time, or periodically in batches? Do the people sending the validation requests have any contact at all with the people providing information about why unsuccessful requests failed?
I've worked on these systems--human and technical. It's hard even for a functioning, outcome-focused, centralized government. In this problem domain, the US federal government is none of those things, and has not been for many decades (or ever, in some areas).
Sure, some of the issues are politically-caused (one party has an incentive to not fix problems that privilege their agenda), but most of them are accumulated failures with no malicious agenda as the cause.
Possible, but I doubt it. I've worked on the systems that do things like ID correlation/verification on the backend. They're ... imagine the most broken possible implementation you've ever worked on, then imagine it worse, then imagine that it's maintained by entirely different contractors than the ones that built it, with minimal incentive for improvement.
That's most of government IT implementations, and has been for decades.
Even when specific systems in this area are implemented well, the regulatory/bureaucratic complexity of the government prevents them from being more than marginally useful at best. I expanded more on some of the concerns/issues in this area in an adjacent comment here: https://news.ycombinator.com/item?id=49832393
Then again, that begs the question of what you’re heavily using exit-node-routed internet links for that Tailscale’s battery draw is noticeable. Most network-intensive internet tasks draw way more power to drive whatever the application is, such that VPN overhead is a rounding error.
Additionally, OOM inside a low level routine can be a troublesome attack, since OOM handling in many applications does questionable (nee vulnerable) things when crashes occur in not-known-to-be-memory-intensive code. Sure, that’s sloppy engineering, but it’s common.
WINE is … well, most directly it’s just an implementation of an API (the Windows APIs). In webdev parlance it might be called a “polyfill”. Perhaps a “compatibility shim”?
If you removed JNA/JNI/CGo, plenty of people would complain…but the vast majority of uses of those languages would still work, unaltered, because most common tasks on the JVM and Go runtime don’t require external native deps.
It's a fairly common pattern in non-video contexts to preallocate arenas of different sizes for different workload pools (e.g. different routes for a server).
It's also fairly common to allocate per-work-item (e.g. request/session/batch job) arenas for "general-purpose" scratch allocations that are small (your header parsing, auth context retrieval, etc.) and then default to a global manual/refcounting allocator for one-off large data actions like your holiday change. Since most business applications are returning summary/small aggregates over the large data action (in this example, something like "holiday updated successfully", not the entire history of the PTO table or the database connection's internal state), the copy cost of moving data between the global dynamic allocator and the arena for result transmission tends to be small.
That's not a terrible approach in some situations. If the large majority of code only needs the scratch arena and/or some per-handle allocators stored on e.g. the database connection pool, it can work well. But if, over time, the amount of bookkeeping required to maintain data tagging/movement between arenas/allocators becomes severe, it's worth stopping, stepping back, and considering that you've kind of walked backwards into inventing a shitty generational GC.
How do you compensate someone who's dead?
This isn't hypothetical: https://www.politico.com/news/2022/12/28/cyberattacks-u-s-ho...
If we extend the metaphor, this would be like making a copy of your keys and handing those out every time someone other than you needed access to your house. Dinner guest? Key copy. Neighbor dropping off a borrowed tool? Key copy. Relative from out of town visiting? Key copy.
In the same way that I think most homeowners would look askance at passing out so many copies of their keys, delegated digital auth is troublesome. Nontechnical users are unlikely to pay attention to "what clients are using delegated credentials for which actions" dashboards. Revocation, while technically easy, isn't something that I think most casual users will be mindful of, resulting in endless growth in the list of principals with access to a resource (just like the "sharing passwords" scenario we have now). Time-based auto-revocation will be an annoyance for delegates who only need to access a resource rarely, resulting in exasperated administrators rubber-stamping new-delegate-credentials requests.
I don't know if there's a good solve here. Shared passwords might be the local maximum of convenience and security, but that feels pretty bad.
Yes, but I think there are incentives to not do this for many LLM providers. Doing prior-work research is slow (web searches aren't fast, LLMs are rate-limited or blocked from plenty of pages, etc.), and sometimes contradictory which annoys LLM users, many of whom like faster gratification cycles from the agent slot machine handle.
Also, writing a bunch of bespoke code instead of leveraging prior art makes a lot of users feel like they own something novel/big/important, and also poses a larger maintenance surface for the LLM to make future changes (which costs tokens).
I don't think there's, like, a conspiracy at LLM providers to set up system prompts/RAG/etc. to discourage research-and-use-prior-art-by-default approaches. Rather, OpenAI/Anthropic/Google/etc. are optimizing for real but sometimes misleading success metrics which often lead away from a research-first approach.