This is it right here. I've long thought about this one and whether I should bother with an AI agent that can do all of this stuff for me, but the reality is both what you said and I'm not rich enough.
Do I want the AI Agent to take my bank account and automatically pay some bill every month in full? What if you go a little over that month due to an emergency expense you weren't prepared for? And it's not a matter of "I don't have enough in my bank account for this one time charge", but it's "I don't have enough in my bank account for this charge and 3 others coming at the end of the month." type deal.
Agents aren't going to be very good at that. "Hey I paid $3,000 on your credit card in order to prevent you from incurring interest. Interest is really bad to carry on a credit card and you should minimize that as much as possible." Me: "Yeah but I needed that money for rent this month." Agent: "Oh, yeah! I should have taken that into account! It looks like we can't reverse the charge for the payment."
Worse than that - people will start tagging "this value is a Date" via comments, and you'll need to parse ad-hoc tags in the comments to decode the data. People already do tagging in-band, but at least it's in-band and you don't have to write a custom parser.
See also: postscript. The document structure extensions being comments always bothered me. I mean surely, surely in a turing complete language there is somewhere to fit document structure information. Adobe: nah, we will jam it in the comments.
"Use of the document structuring conventions... allows PostScript language programs to communicate their document structure and printing requirements to document managers in a way that does not affect the PostScript language page description"
The idea being that those document managers did not themselves have to be PostScript interpreters in order to do useful things with PostScript documents given to them. Much simpler.
For example, a page imposition program, which extracts pages from a document and places them effectively on a much larger sheet, arranged in the way they need to be for printing 8- or 16- or 32-up on a commercial printing press, can operate strictly on the basis of the DSC comments.
To it, each page of PostScript is essentially an opaque blob that it does not need to interpret or understand in the least. It is just a chunk of text between %%BeginPage and %%EndPage comments.
This is tremendously useful. A smaller scale of two-up printing is explicitly mentioned as an example on p. 9 of the spec.
> Could you imagine hitting a rest api and like 25% of the bytes are comments? lol
That's pretty much what already happens. Getting a numeric value like "120" by serializing it through JSON takes three bytes. Getting the same value through a less flagrantly wasteful format would take one.
I guess that's more than 25%. In the abstract ASCII integers are about 50% waste. ASCII labels for the values you're transferring are 100% waste; those labels literally are comments.
If you're worried about wasting bandwidth on comments, JSON shouldn't be a format you ever consider, for any purpose.
And both are poor interchange formats. When things stay in their lane, there is no "problem." When you try to make an interchange format using a language with too many features, or comments that people abuse to add parsable information (e.g. "type information") then there is a BIG problem.
It caused all kinds of problems, though those tend to be more directly traceable to the "be liberal in what you accept" ethos than to the format per se.
Likewise. I once got pulled over by the police because they insisted that my license plate had been turned in and I was driving without valid plates.
They called other officers, ran the plate, ran the VIN, ran the plate, ran the VIN. I dunno I think we sat there for almost an hour before they told me why they pulled me over and what was up.
While I'll make no judgment specifically on whether or not she is telling the truth, because the article itself isn't enough validation to say she is telling the truth here; I'll comment more on the comments in this thread.
At what point is automated enforcement a good or a bad thing for law breaking? We have yet to grapple with that as a society, and the short answer is there's no easy answer to this problem. Both for precisely the reason this article calls out (that overnight location of car is not a 100% accurate representation of residency, and fixing it seems like a mess); but also because people ARE inherently selfish and REALLY do not like the rules applying to them equally.
A great many people in the United States, particularly white (sorry, I'm going to bring race into this because it's important) enjoy some level of flexibility on what laws they follow and when. Certainly more flexibility than the average black experience. In fact, this problem is so bad that states like California have had to institute policies that allow things like license plate lights being out to exist because the profiling is so catastrophically bad that it's completely unfair.
So now, we have an automated system that at least tries to provide some level of fair enforcement. At least for now, things like speed cameras, red light cameras, license plate readers, etc. don't appear to openly consider racial bias in the immediate decision making process on whether the law is enforced or not. (There are other biases, of course, and even indirect bias with regards to where these things are placed, but I'll digress a bit here).
But even aside from the racial divide, the class divide on enforcement is a problem. And the upper classes have generally enjoyed a level of insulation from complying with laws, which just continues to go up the higher you climb (See: Epstein files). But that's on the more extreme end.
At any rate, better enforcement of laws that are now crossing the lower to middle class divide because automation allows us to do so is certainly an interesting social problem.
Is putting a bunch of red light cameras in a black neighborhood to catch and fine red-light runners an anti-black policy because it imposes automatic punishment on black drivers who are running red lights? Or pro-black because it helps secure the safety of black pedestrians who deserve not to have people breaking traffic laws around them? What if it turns out that even though the neighborhood is black the car traffic on that street has a greater percentage of non-black drivers than the neighborhood population? What if it turns out that black people run red lights at a rate much higher than other races everywhere in the country, so no matter where you put up red light cameras it will always catch and fine a disproportionate number of black drivers?
Regardless of whether you approve or disapprove of automatic red light cameras, you can construct an argument that either having them or not having them is the policy that is actually racist against blacks.
More generally, whether automated law enforcement is good or bad depends highly on how good or bad the law is, which people legitimately disagree about; and also how reliable the automatic enforcement is.
To be fair, the first point is a good point. But I'd argue that you should deploy them everywhere in order to not be racist since we already generally know that the red light cameras are revenue generating devices. Is there some data on whether they increase safety? Preferably unbiased (probably not). Unsure.
Nonetheless, a fair point that deserves analysis. (My vote, to be fair, is ask the community what they want and put it up to a vote. With honest information on safety data versus revenue generation)
What are the boundaries of the community that votes? What if the racial demographics of that community have changed recently, in ways that affect how the vote turns out? What if some people in that community are aware of these voting patterns and explicitly bring up race when engaging in public discussion about the merits or demerits of the red-light-camera-policy, because it's important? What if they try to change the boundaries of the voting district in order to include/exclude more people who they think will vote with/against them on the red-light-camera issue, in ways that highly correlate with race?
I hadn't considered this so eloquently with LLM text output, but you're right. "LLMs make everything sound profound" and "well-written bullshit".
This has severe ramifications for internet communications in general on forums like HN and others, where it seems LLM-written comments are sneaking in pretty much everywhere.
It's also very, very dangerous :/ Because the structure of the writing falsely implies authority and trust where there shouldn't be, or where it's not applicable.
> I don't care about glibc or compatibility with /etc/nsswitch.conf.
So what do you do when you need to resolve system users? I sure hope you don't parse /etc/passwd, since plenty of users (me included) use other user databases (e.g. sssd or systemd-userdbd).
That's a fair point, and shelling out to id is probably a good solution.
I guess what bothers me is the software authors who don't think this through, leaving applications non-functional in these situations.
At least with Go, if you do CGO_ENABLED=0, and you use the stdlib functions to resolve user information, you end up with parsed /etc/passwd instead of shelling out to id. The Go stdlib should maybe shell out to id instead, but it doesn't. And it's understandable that software developers use the stdlib functions without thinking all too much about it. But in the end, simply advocating for CGO_ENABLED=0 results in software that is broken around the edges.
On the other hand, the NSS modules are broken beyond fixing. So promoting ecosystems that don't use them might finally spur the development of alternatives.
Could be interesting. What do you see as the main problems with NSS? I've never needed to use it directly myself. It seems quite crusty of course, but presumably there's more that your referencing.
Moving from linking stuff in-process to IPC (such as systemd-userdbd is promoting) _seems_ to me like a natural thing to do, given the nastiness that can happen when you bring something complex into your own address space (via C semantics nonetheless). But I'm not very knowledgeable here and would be interested to hear your overall take.
NSS/PAM modules have to work inside arbitrary environments. And vice versa, environments have to be ready for arbitrary NSS modules.
For example, you technically can't sandbox any app with NSS/PAM modules, because a module might want to send an email (yes, I saw that in real life) or use a USB device.
NSS/PAM need to be replaced with IPC-based solutions. systemd is evolving a replacement for PAM.
And for NSS modules in particular, we even have a standard solution: NSCD. It's even supported by musl libc, but for some reason nobody even _knows_ that it exists. Porting the NSCD protocol to Go is like 20 minutes of work. I looked at doing that more than once, but got discouraged by the other 99% of complexity in getting something like this into the core Go code.
Why are you excited for this? They’re not going to give YOU those peoples’ salaries. You will get none of it. In fact, it will drag your salary through the floor because of all the available talent.
I’m excited as a computer scientist to see it happening in my life time. I am not excited for the consequences once it’s played out. Hence my comment about retiring, and empathy for everyone who is still around once I do. I never got into this for the money - when I started engineers made about as much as accountants. It’s only post 1997 or so that it became “cool” and well paid. I am doing this because I love technology and what it can do and the science of computing. So in that regard it’s an amazing time to be here. But I am also sad to see the black box cover the beauty of it all.
I'm very confused about this. Salary is only one portion of your total compensation. The vast majority of tech companies offer equity in a company. The two ways to increase the FMV of your equity is: increase your equity stake or increase the value of the total equity available. Hitting the same goals with fewer people means your run rate is lower, which increases the value of your equity (the FMV prices in lower COGS for the same revenue.) Also, keeping on staff often means you want to offer them increased equity stakes as an employment package. Letting staff go means more of that available equity pool is available to distribute to remaining employees.
We aren't fungible workers in a low skill industry. And if you find yourself working in a tech company without equity: just don't, leave. Either find a new tech company or do something else altogether.
Equity is negotiable just like salary, and if supply of developer labor increases with the same or less demand, you'll get less equity just like you will get less salary.
I can't believe the person you replied to thinks that they're going to get some magical more amount of equity because you can hopefully do more with fewer people. That's assuming the entire business landscape doesn't also change with AI, disincentivizing so much investment in companies in the first place because someone else with AI can create a competitor in a shorter amount of time...
In the last three startups I worked at I didn’t bother exercising my vested equity - even a successful exit would at best triple the price of those shares - not worth the risk. One of those three startups already failed.
No, it's a solved problem for ad blockers, a very specific problem case that extensions have traditionally solved. But the entire concept of extensions is far greater than just "ad blockers", although that's the use case for which 99.9% of people have used them for.
I mean on iOS you do have a raw home storage path you can save arbitrary binary data stuff to, although Apple generally just has the option of "Save to Files"--but you have at least some basic folder structure there you can use and have full access to.
It's just not commonly used for the reason the other person mentioned (share buttons between apps that are file type aware)
Do I want the AI Agent to take my bank account and automatically pay some bill every month in full? What if you go a little over that month due to an emergency expense you weren't prepared for? And it's not a matter of "I don't have enough in my bank account for this one time charge", but it's "I don't have enough in my bank account for this charge and 3 others coming at the end of the month." type deal.
Agents aren't going to be very good at that. "Hey I paid $3,000 on your credit card in order to prevent you from incurring interest. Interest is really bad to carry on a credit card and you should minimize that as much as possible." Me: "Yeah but I needed that money for rent this month." Agent: "Oh, yeah! I should have taken that into account! It looks like we can't reverse the charge for the payment."
Yeah, no fucking thank you LOL.
reply