There are forks and they are still accessible. So decentralization works.

Maybe he’s the right tool for the job

A “do everything” app is overkill. I am not a fan of many features Discord implemented over time. But the initial offering of having text chat, voice chat, video chat in one app makes sense. It’s just super convenient to switch the communication type depending on what you are currently doing, without having to onboard and switch between tools.

It’s also hard to draw a line, if you want to go “do one thing well”. Mumble also includes text chat, and user management, ACLs, etc. … for text chat one could use IRC, for user management there are IdPs, and so on. XMPP also doesn’t just do “one thing”. The “X” (= extensible) is heavily used and there are extensions for all kinds of things. Some of the big messengers out there are (or were) using XMPP under the hood (just without federation).

But then it’s not chat anymore. Or screenshare.

There are many good tools that solve individual issues. But Discord solved many of these issues in one tool, and that also has its charme.

You would have another browser engine at your fingertips; with all its upsides and downsides. Outside of the Apple world there are no really usable webkit based browsers (even though it originated from Linux).

To be fair, it is not sponsorship. Kagi pays for a service they use. And since this is just one of many sources, this is likely also a relatively small amount of money. If they would deliberately pay more than what they use to “do something good” for handed, then sure, it would be a much bigger issue.

The only seriously usable webkit based browsers are on OSX or iOS. So far this looks like a best shot at having a cross platform browser with all necessary features to become mainstream and which is based on webkit.

If that helps erode the chromium monopoly, it’s a win.

Yes, experience matters a lot. I think the comparison of an coding agent being like a trainee is somewhat appropriate. Leave them to their own devices, and you likely don’t get something you should be shipping to production. But guide them appropriately, and they are helpful. The difference obviously is, that a trainee learns, an agent not so much. At least not on an abstract level. Of course the more code you have, the more patterns they can then copy. But if your baseline rots, so will the code the agent derives from that baseline.

It’s not a tool, it’s a chaos generator.

Just like humans. Bullshit code and bad developers existed before agents helped make them.

Aside from fundamentalists the usage of LLMs and coding agents will increase. It’s a tool in the toolbox now and many devs do or will play around with it. Some will have to learn to not overdo it; but that’s nothing new and a lot of fancy technologies or frameworks along the way caused some disruptions because people jumped on the hype train without applying some caution or critical thinking; but that evens out after a while.

Might be we see a big drop in usage when costs increase, but it’s also very very possible that the many technological advances we currently make (hardware to run models becoming more streamlined and the models themselves being tuned more and more) will mean, that we indeed reach a point where this can be done comparatively cheap and maybe even local (to some degree) without having to take out a loan.

I wouldn’t say “managed by LLM” though, just because you spot (partially) agent written commits. It’s hard to judge from the outside how much knowledge the maintainer puts into it. There a big band between vibe coding and fully manual coding. And if we are honest, even “fully manual” is a flexible term (does code completion count? does looking at stack overflow count? does looking at other implementations count? using a search engine?).

The world is changing, for better or worse. But cut devs some slack and let them get used to the tools. (And to re-iterate that: bad quality and bugs were a thing before agents as well. It just took longer.)

Drawing attention

The machines I use regularly are all some form of ArchLinux (currently mostly CachyOS). Machines I use rarely I stick to LTS distros with few updates. Machines I don’t maintain myself I try to stick to immutable distros that just update themselves every once in a while (less chance of breakage).

Security is always applied in layers. The more the better. There’s a reason “encryption at rest” is a requirement in many audits.

Why full disk encryption is important: what happens when you switch servers or providers: can you be sure the disk gets wiped properly?

Or when your disk dies and gets replaced, what happens to the old disk? Will they physically destroy it or just throw it in the bin?

When encrypted, it doesn’t matter; no one will get data off of them. That’s why you encrypt servers.

From an acceptance point of view there is no difference in forcing providers to implement an API to talk to your device or forcing providers to talk to a central service (or at least any service implementing a certain interface).

If the goal was for more surveillance, they could have immediately gone for that route.

They could also have kept the current “ask the user” approach and mandated website providers to store these information. That would have been a much smaller step and would have brought them closer to big brother as well.

Now they went for an approach that takes a step away from what we already have, making it more privacy friendly. Websites don’t have to ask (and potentially store) your birthday anymore and can still stay compliant.

The US bills I have read also don’t enforce any real age (how could they). They require the birthday to be stored on the device for the device to reply with the info if the user is within a certain age bracket. But nowhere did I see anything that would force users to store their truthful birthday. All that it would do is making the already existing age checks much more convenient and giving parents the opportunity to make them slightly more secure.

Isn’t that level already socially normalized? Every second website asks me for my birthday to derive my age for as long as I can think. Many of them ask me basically every time I use them (even Steam, where I am logged in and my payment history alone should imply that I am old enough).

Beautiful. Will keep an eye on it. Thank you!

How would the current approach help?

Its not invasive yet (no third party, no ID, no verification; its basically just another user controlled date field that is not even exposed). So it is not lowering any barrier in that regard.

It’s also not a helpful intermediary step for harder measures, because as soon as you want a third party to do attestation, storing that on a user controlled device is just unnecessary complexity and risk of circumvention. It would be easier and safer (for those introducing it) to just let the attesting party talk to the providers directly.

The comment you answered to said not all software has to implement age checks; only those who actually deal with age relevant content. You said it would be a foot in the door. So… who’s foot to do what?