downsplat

Which LLM hallucinated this monstrosity? Just use a regex, it's a one-liner!

Been flying with Audacious and deadbeef for ages. Minimalistic but quick and effective.

I guess one thing we can agree with the author is that YAML is technically a piece of crap.

It still works well in the appropriate settings. LibreOffice (nee OpenOffice) uses ODF, an XML format, for its document files, and it has been working nicely enough for a long time.

> XML grew from SGML (like HTML did), and it brought from it a bunch of things that are useless outside a markup language. Attributes were a bad idea.

That's exactly what I wanted to say. The author talks as if XML was well designed to represent structured data, but it was not, it grew out of the idea of marking up text, which is a completely different problem. The hilarious part is that he doesn't recognize the problem when he gives his example of "or with attributes".

The other thing, is that the JSON model doesn't just give you a free parser/serializer in JavaScript. It actually maps to the basic data model of the entire generation of dynamic languages that the Web grew on: perl, Python, JS, PHP and Ruby. Arrays and maps are the basic way to represent structured data in these languages, and JSON just serializes that. Which means that getting data in and out of your language is just a single line.

The author seems to think that XML maps a proper conceptual model and JSON doesn't, but the model of "nodes with attributes and content" is a worse match for structured data than JSON's model of "arrays and maps of values".

Other than that, it's really a question of how much tooling you want to use. Both JSON and XML grew entire ecosystems of it, and nowadays if you want to read your JSON according to a schema into typed objects, you can, and for any good-sized project, you probably should.

Also: > There are cases where other formats are appropriate: small data transfers between cooperating services and scenarios where schema validation would be overkill.

That's actually most of the cases for your average web dev!

I do that when I need to make a simple SPA. Plain Vue plus a few tiny add-ons of my own.

I definitely complain about this one. I can read a few languages, and rarely if ever browse a page in a language I don't understand, so popups with "do you want to translate this" are unwelcome here. It doesn't help that in the first iterations Firefox didn't offer a quick way to turn the whole thing off.

That sounds like the worst of possible worlds! At $WORK we're also on mysql, but I don't know what I would do without engine-specific queries. For one, on complex JOINs, mysql sometimes gets the query plan spectacularly wrong, and even if it doesn't now, you can't be sure it won't in the future. So for many important queries I put the tables in the intended order and add a STRAIGHT_JOIN to future-proof it and skip query planner complexity.

Not a ruby shop here so it's not directly comparable, but I'm very happy with beanstalkd as a minimalistic job queue. We're on mysql for historical reasons, and it didn't support SKIP LOCKED at the time, so we had to add another tool.

I guess the point is that you're already doing it for postgres. You alrrady need persistent storage for your app, and the same engine can handle your queuing needs.

I've used Xfce exclusively since Gnome jumped the shark many years ago. It's fast, does the job nicely, and stays out of your way. I do hope they get stable on Wayland sometime soon, because X11 seems to have lost its momentum, and I would probably like to enable fractional scaling on my next laptop.

Did you read the article? An unclosed <p> is not a mistake that the browser is tolerating, it's 100% well-defined html5 according to spec. If your tooling can't handle the language as defined, maybe the problem is with the tooling.

You do you in terms of taste, but the article explains very clearly that there's nothing wrong about not closing them, as they are reliably auto-closed by a well-defined standard.

It goes much further than that.. a single moderately sized VPS web server can handle millions of hard-to-cache requests per day, all hitting the db.

Most will want to use a managed db, but for a real basic setup you can just run postgres or mysql on the same box. And running your own db on a separate VPS is not hard either.

Yeah at $WORK we use various LLM APIs to analyze text; it's not heavy usage in terms of tokens but maybe 10K calls per day. We've found that response times vary a lot, sometimes going over a minute for simple tasks, and random fails happen. Retry logic is definitely mandatory, and it's good to have multiple providers ready. We're abstracting calls across three different APIs (openai, gemini and mistral, btw we're getting pretty good results with mistral!) so we can switch workloads quickly if needed.

You can turn that off. If you're using LLMs for technical or real world questions, it's nicer for each chat to be a blank slate.

There's more than one thing that "killed perl" (I still use it almost every day.)

But I think the main thing that made it long term non competitive were a series of bad design choices all the way back to perl 4 or even 1.

Namely:

- the need for sigils

- weird sigil rules where the 0 element of @x is $x[0] not @x[0]

- auto flattening, ex. (@a, @b), and hence the need for manual reference management, as in (\@a, [1,2,3])

- lack of a native object system, and widespread repurposing of hashrefs as objects, with awkward field syntax $x->{foo}

- awkward function argument syntax: my ($x, $y) = @_;

These things add up, and both JS and python showed that all those can be done much more smoothly.

Another thing that counted at the time, is that PHP came out with a slightly worse language, but a super beginner-friendly approach to html templating and request lifecycle: you can just mix php and html in the same file, and the entire runtime environment is nuked at each request. The result was that php replaced perl for an entire generation of web devs in the early 2000s.

I'm sure there are plenty of problems with the open web, and that Google is not entirely a stranger to them... but removing an ancient language that basically failed to get traction is not one of them. No matter how elegant and advanced a certain class of nostalgic XML programmers find it.

And no, XSLT doesn't have much to do with how much RSS thrives or not. RSS is basically consumed by RSS reader backends, not directly by users on their browser.

One of the web platform's problems, is that it accumulates untold cruft from every failed experiment. The entire XHTML exercise turned out to be an expensive mistake, but we can't remove that because too many pages depend on it, and it ended up in a whole lot of places, including the EPUB definition. But at least XSLT could get removed. Yay for that.

Calls to action seem to be specific to chatgpt's online chat interface. I use it mostly through a "bring your API key" client, and get none of that.

You can entirely turn off memory, I did that the moment they added it. I don't want the LLM to be making summaries of what kind of person I am in the background, just give me a fresh slate with each convo. If I want to give it global instructions I can just set a system prompt.

> that doesn't address the discovery problem.

The real problem is the expectation of immediate discovery. People have gotten used to "give me something new now", and the algorithm complies but then quality is low.

Slow, organic discovery is where it's at. Seed your feed by following people you already know, then slowly add other people you come across. If your feed is half empty for weeks, that's a feature, not a bug.

What's wrong with Substack? It's just the cool blogging platform of the day, you don't have to engage with paying subscriptions if you don't want.

My first computer was one of those cheap Amstrad pc clones, and it came with GEM on top of MS-DOS. GEM looked good but took a while to load from 5"1/4 floppy, and once loaded there were no useful graphical applications to speak of. I quickly stopped loading it and learned the DOS command line... Which came useful later to transition to Linux!

Some positive padding, offset by the same negative margin, will do just that, i.e capture clicks near the link or button. It has some problems, but I've seen it used to make footnote links easier to click on mobile.

Ex: a.fn-link { padding:10px 18px; margin:-10px -18px; }

With the huge usage that LLM APIs are getting in all sorts of industries, they cannot be going away, and they're cheap.

If consumer AI chatbots get enshittified, you can just grab some open source bring-your-api-keys front-end, and chat away for peanuts without ads or anything anti-user.

I use https://github.com/sigoden/aichat , but there are GUIs too.

Plus, anyone enterprising can just write a web front-end and sell it as "the ad-free AI chatbot, only $10/mo, usage limits apply".

Yes. Especially on Android, FF with uBlock Origin is the superpower.

For this particular issue: Three dots > Extensions > uBlock Origin > Open dashboard > Filter list > Privacy, enable "Block Outsider Intrusion into LAN".

You can create a work profile on Android and install Whatsapp in it, this way it won't have access to your main environment and contacts. For the f-droid loving crowd, try the Shelter app to set up the separate area.

My question is, will they block sites when some e.g Greek or Spanish authority tells them too? One thing I appreciate about Cloudflare or Google's dns-over-https servers, on top of the encryption, is that they don't block sites like Anna's Archive, whereas my local ISP sometimes does.

Yeah, I mean paid API access. You put a credit card in, and it's peanuts at the end of the month. Sorry I didn't specify. Good reminder that with free services you are the product!

Same here. Since I started using LLMs a bit more, the killer step for me was to set up API access to a variety of providers (Mistral, Anthropic, Gemini, OpenAI), and use a unified client to access them. I'm usually coding at the CLI, so I installed 'aichat' from github and it does an amazing job. Switch models on the fly, switch between one-shot and session mode, log everything locally for later access, and ask casual questions with a single quick command.

I think all providers guarantee that they will not use your API inputs for training, it's meant as the pro version after all.

Plus it's dirt cheap, I query them several times per day, with access to high end thinking models, and pay just a few € per month.