Many people do not have a choice to not use it at their jobs due to internal mandates. Regardless of their own use, many people are subjected to externalized cost of AI proliferation (data centers, layoffs, electrical bills, etc).

One cannot choose to not be affected by it. But even if one were personally not at all affected by it, it is still reasonable for someone to push back against what they see as a negative effect on society, even if it's not hitting them personally. Climate change's effect on me personally is pretty minimal, and I still deeply care about it.

Data centers and their side effects (higher electricity prices, etc) and job layoffs attributed to AI; plus a bunch of industry specific objections (like say, how it's currently destroying the educational system).

> Most people know use AI for basic applications and seem to enjoy it

Not sure what crowd you're running with. Myself and coworkers use AI and are generally positive about its effect on our productivity. But I don't think they'd say they 'enjoy' it, and we're probably the _best_ case. Who in the world 'enjoys' using AI?

They can try to 'hide' behind that, but if I see you wearing them, I 100% am assuming the worst case intent. I suspect I am not the only one.

I think this gets at only half of the problem. Not only can meta not be trusted, even if I trust _you_ if you were friend, I wouldn't trust any _other_ random user of such a product. As such, better to not have such a product around.

Also, I really, really hope you take them off when using the shared bathrooms at such an event. And you know, keep them off. Permanently.

What is _your_ default assumption re: use case? I honestly can't think of any use cases (outside of very niche a11y uses) that are not in some way offensive, though perhaps not 'perverted'.

This product is absolutely toxic, and I can't imagine myself or anyone I know being willing to associate or socialize with someone wearing them (again, excluding some very specific a11y use).

Comments URL: https://news.ycombinator.com/item?id=49124281

Points: 5

# Comments: 1

I think I have a fundamental objection to the idea that Fielding and Fielding alone got to decide what REST is. While there hasn't been any kind of formal counterproposal, in some sense REST is what we make of it. Re: http 400 codes, I think many of us really liked the general principle of "use http semantics!" and applied that to error codes as well. That's agreeing with the principle and extending it in new ways that we like and are "truer" to the principle, even if it wasn't intended.

In my mind this is sort of analogous to talking about the relationship between linux and unix. Linux is clearly not a genetic or copyright unix, but I've seen it said before that linux is the culmination of unix principles, in some cases extended beyond what was originally envisioned in ways that are innovative and genuine improvements (io_uring perhaps?).

The REST we have today - http semantics, specific error codes, etc - may be significantly different from what Fielding may have wanted, but IMO it implements the parts that really distinguish it from the RPC world of API architecture, and I think we're generally happy with that.

The example given in this section... is there actually a commonly used REST api that uses that particular key/structure? I wouldn't be _surprised_ if I came across that in some random API's documentation, but I hardly think it's the 'usual' thing to do.

The article later claims that that style is from https://stateless.co/hal_specification.html , which I think is a consultancy company whose major partners are all casinos (am I totally off on this?). The article also references (https://github.com/kevinswiber/siren which adds detail re: http methods embedded in the _links structure, but I'm not sure why that repo should be considered authoritative. 1300 stars for a just a spec is actually not bad though I think, so maybe.

Overall this article seems like slop produces from some kind of ai crawler that managed to dig up a couple of random links.

I am glad that it mentions rfc9457 though.

People shit on the node/npm ecosystem relentlessly for the typical inauditable deep dependency graph, and bun makes substantial improvements to that situation.

Edit: bun recently added an inbuilt api for manipulating images (resize, change formats, etc). Another good example of them adding native/faster functionality that replaces significant dependencies (in this case, likely sharp: https://www.npmjs.com/package/sharp?activeTab=versions)

EU regs forced apple to move to type-c. They appear to be moving towards either requiring replaceable batteries, or requiring a higher quality batter (larger % of original charge after 1000 cycles). Those both seem valuable to consumers, and coming from a position of regulatory strength.

Yes. But why would they provide that to their competitors? The winning move here is to allow gemini, but forbid everyone else. That's not a bad moat.

- offering to pay some nominal subsidy for all households electricity bills in the region.

- committing to only closed loop cooling

- if the location is amenable, then providing free heating to neighboring buildings.

- only building in blighted locations with no current economic value

Other random ideas: I wonder if anyone is considering building server racks directly into offshore windfarms. Replacing failed hardware is annoying, but surely more economical than in space where IIUC, there _is_ no plan to ever maintain hardware at all, just deorbit and replace. All the water is right there for cooling (though I'm sure saltwater has its own problems with corrosion). While the current US administration is clearly anti windmill, that might work nicely in Europe.

Unless they manage to build such a model, then their plan looks like they intend to be an AI _infrastructure_ company. Which is probably viable and healthy business! One with lots of competition and low margins that is completely misaligned with their current valuation.