HN user
Cool article, but the one it acknowledges and riffs off of, at https://lr0.org/blog/p/arabic/ , is much more informative, and tells all about how we got decent Arabic script rendering on our browers and OSs, but still notably imperfect.
Which makes me think: come on, in the age of Claude, the gap between "we know what to do" and "here is the working code" is narrower than ever.
Who will be the one to pick up the job? Has to be an Arabic speaker I guess!
The point is not about what it means exactly to "own" something, you'll get plenty of noise discussion around that one.
But if I care about some piece of digital art enough to pay for it, I sure want a non-DRM copy to sit on my hd at the end of the transaction. If the store won't supply, the pirate sites will.
Redis is a great piece of tech but it suffers from trying to be good at two different jobs (persistent data structures, volatile cache) which should not be combined. And indeed in Redis itself they don't combine well - persistence is globally on or off.
Personally I'd use memcached or some equivalent for strictly cacheing, and then bring on Redis with persistence if you need its data structures for e.g scoreboards.
At $WORK we never imported either, our cache layer for slow operations keeps its data in both the filesystem and a db table (used as a k/v store). The database helps coordinate thundering herd problems - this operation is being calculated by another thread, so just wait for it. Reads from the same server just hit the filesystem, and reads from another server hit the db once and then keep it in the filesystem. We could change the fs layer to memcached but so far it's working great.
Search around, there's surely a way to break the drm. When theres no better way that's what I do too: pay for the book, convert to plain epub.
The publishing industry never got its head out of... some dark place. We've been able to buy mp3s without drm for ages, but somehow books are different.
Yep, if you haven't lost the will to put a bit of curation work upfront, RSS never stopped being the right answer. Substack has been a pretty good addition to the landscape, bringing lots of people into blogging (without calling it that). But for the skimming/reading interface, RSS beats the app.
I've been using Claude to work on a medium-sized (100+kLoc) codebase, and it's a great productivity multiplier. Putting hours into creating a good AGENTS file is more improved results a lot. I find that over time it picks up the codebase quite well. Tedious tasks that would take a day are now a matter of a few prompts.
Still... I'm not ready to give it more autonomy. Even as it gets high-level things quite well, I still look at the code, give feedback, and have 3-4 rounds of tweaks until I'm happy with it, and also happy that I stil feel I have a good handle on the codebase.
I basically skipped React. I went from jquery to Vue3, and use even that sparingly. When React got really popular, I read the docs and played with it, but I prefer the Vue model where the component runs once and sets up its reactive tree. Why would you want to recreate the component's inner functions every time it renders? And manually declare dependencies, when every other framework is doing them automatically?
My favourite front-end architecture is MPA actually mostly server-rendered, with Vue only on the pages that need high interactivity, and vanilla JS on the others.
If postgres is too heavyweight for you but you still want client-server, I'd consider MySql. It's an old classic, pretty fast and scalable, and has much better mainstream support and a bigger ecosystem than Firebird.
I'm not really sure what Firebird is for at this point in life really. It was pretty exciting when it was open sourced in the early 2000s, before postgres became the mature beast it is, before mysql acquired something as basic as transactions, and before sqlite became the default embedded db. But then it never really went anywhere.
Well-researched article on the relative safety of acetaminophen and ibuprofen.
It's called euthanasia. You can ask the medical system for an assisted suicide if your life situation is extra painful with no hope for recovery.
This case got heaps of media popularity because the christian right wing latched on it, and the father tried as hard as he could to impede the euthanasia. Ultimately got told that the lady unequivocally wants it and qualifies, and he can't override that.
What kind of context has you deploying into old systems that don't ship a recent perl? If that is a legacy requirement for whatever reason, then at least I'd use docker or podman to get a recent runtime. Or would you also write Python 2 or Php 7?
What are you using for parameter type checking? I switched to native function signatures, native try/catch and might look into the new class system soon, but I don't recall native type checking...
This looks like a huge project, even with AI help... I have a sweet spot for perl but I'm honestly not sure if the current community has the bandwidth and interest to sustain an alternative implementation. At the very least it should be ported to MacOS too. Breaking with XS is a bold decision. Best of luck though!!
Alcohol has been deeply embedded in human culture for thousands+ years, that's why prohibition is a bad idea. Loot boxes are a new invention, if they're deemed too harmful we can just do without them.
It's amazing how people will jump to something new just because it's there and it's being promoted.
When wireless headphones came out, I looked at my wired ones and asked the simple question: is a tangling cable worse than bluetoth pairing and having to keep yet another thing charged? My answer was no, so I kept using cheap wired ones.
A few years later, now that makes me look rich. Or something.
I guess it's really not for me though. First thing I do is turn autoplay off, and I'd refuse to use a service that doesn't give me that option. OTOH, I do sometimes find it fun to hunt for good stuff among the recommendations.
You've probably already done this, but first thing, turn off autoplay and make sure it stays off. Much easier to not get sucked into things when you have to actively click on them.
Why would you want to do that? I'm so happy I can search exactly what I want among heaps of long tail stuff, I would never want to go back to a "live tv" interaction model.
For most situations, I deal with this by keeping dates as strings throughout the app, not objects. They get read from the db as strings, passed around as strings. If I need datetime calculations, I use the language's datetime objects to do it and convert right back to string. Display formatting for users happens at the last moment, in the template.
No-one seems to like this style, but I find it much simpler than converting on db read/write and passing datetime objects around.
It's not really a Linux vs MS thing though. When Unicode first came out, it was 16-bit, so all the early adopters went with that. That includes Java, Windows, JavaScript, the ICU lintaries, LibreOffice and its predecessors, .NET, the C language (remember wchar_t?), and probably a few more.
Utf8 turned out to be the better approach, and it's slowly taking over, but it was not only Linu/Unix that pushed it ahead, the entire networking world did, especially http. Props also to early perl for jumping straight to utf8.
Still... Utf8's superiority was clear enough by 2005 or so, MS could and should have seen it by then instead of waiting until 2019 to add utf8 collations to its database. Funny to see Sql Server falling behind good old Mysql on such a basic feature.
The old defense of 16-bit chars, popping up in 2026 still! Utf8 is efficient enough for all general purpose uses.
If you're storing gigabytes of non-latin-alphabet text, and your systems are constrained enough that it makes a difference, 16-bit is always there. But I'd still recommend anyone starting a system today to not worry and use utf8 for everything.j
Did this post come out of a freezer from 1998? Who on earth creates databases in Latin1 in 2026?
Nevermind, looks like Sql Server didn't add utf8 collations until 2019 (!) and for decades people had to choose column by column between the 16-bit overhead of "nvarchar" and latin1... And still do if they want a bit of backwards compatibility. Amazing.
I don't think openclaw can possibly be secured given the current paradigm. It has access to your personal stuff (that's its main use case), access to the net, and it gets untrusted third party inputs. That's the unfixable trifecta right there. No amount of filtering band-aid whack-a-mole is going to fix that.
Sandboxes are a good measure for things like Claude Code or Amp. I use a bubblewrap wrapper to make sure it can't read $HOME or access my ssh keys. And even there, you have to make sure you don't give the bot write access to files you'll be executing outside the sandbox.
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.