mickeyp

That is literally how it is supposed to work. Prometheus grabs metrics --- that is how it works. If you for some reason find yourself unable to host an endpoint with metrics, you can use the fallback pushgateway to push metrics where yes they will stay until restarted. Ask yourself how it could ever work if they are subsequently deleted after read. How would multiple prometheus agents be able to read from the same source?

IMO, you should not avoid triggers if it helps prevent invariants in your database. That is what they are especially good at preventing.

You can instruct postgres to raise exceptions using the same error code that constraints use: that way your clients do not need to know the difference.

I had one of those as a kid. Great watch.

Reading the wikipedia page for it may make you rethink that thought though :(

1x1 pixels for padding and aligning? That came later. Your memory is off.

In the 90s, sites did kinda look like that.

You are talking about low level stuff like syncing to the filesystem; that data is journalled and ensuring atomicity is maintained and I am in actual fact not.

Dislocating DML from the code that triggers it creates many problems around ensuring proper data integrity and it divorces consistent reads of uncommitted data that you may want to tightly control before committing. By punting it to a dedicated writer you're removing the ability to ensure serialised modification of your data and the ability to cleanly react to integrity errors that may arise. If you don't need that? Go ahead. But it's not fud. We build relational acid compliant databases this way for a reason

For small oltp workloads the locking is not going to be a problem. But stuff that holds the write lock for some measurable fraction of a second even will gum things up real fast. Transactions that need it for many seconds? You'll quickly be dead in the water.

"performance optimisation" --- yeees, well, if you don't care about data integrity between your reads and writes. Who knows when those writes you scheduled really get written. And what of rollbacks due to constraint violations? There's we co-locate transactions with code: they are intertwined. But yes, a queue-writer is fine for a wide range of tasks, but not everything.

It's that we need to contort our software to make sqlite not suck at writes that is the problem.

Edit: disregard. I read it as he'd done it and had contention problems.

I mean it's not if he's got lock contention from BUSY signals, now is it, as he implies. Much of his issues will stem from transactions blocking each other; maybe they are long-lived, maybe they are not. And those 3-500 queries --- are they writes or reads? Because reads is not a problem.

These are my PRAGMAs and not your PRAGMAs. Be very careful about blindly copying something that may or may not match your needs.

    PRAGMA foreign_keys=ON
    PRAGMA recursive_triggers=ON
    PRAGMA journal_mode=WAL
    PRAGMA busy_timeout=30000
    PRAGMA synchronous=NORMAL
    PRAGMA cache_size=10000
    PRAGMA temp_store=MEMORY
    PRAGMA wal_autocheckpoint=1000
    PRAGMA optimize <- run on tx start

Note that I do not use auto_vacuum for DELETEs are uncommon in my workflows and I am fine with the trade-off and if I do need it I can always PRAGMA it.

defer_foreign_keys is useful if you understand the pros and cons of enabling it.

Edit: disregard. I read it as he'd done it and had contention problems.

You can't. You have a single writer - it's one of the many reasons sqlite is terrible for serious work.

You'll need a multiprocessing Queue and a writer that picks off sentences one by one and commits it.

I mean, you're not wrong, and that is one way to solve it, but the whole point of a sensibly-designed WAL -- never mind database engine -- is that you do not need to commit to some sort of actor model to get your db to serialise writes.

Indeed. Everyone who uses sqlite will get burnt by this one day and spend a lot of time chasing down errant write-upgraded transactions that cling on for a little bit longer than intended.

SQLite is a cracking database -- I love it -- that is let down by its awful defaults in service of 'backwards compatibility.'

You need a brace of PRAGMAs to get it to behave reasonably sanely if you do anything serious with it.

Last time I checked, writing efficient, contention-free and correct parallel code is hard and often harder than pulling an algorithm out of a book.

It is so sad to see so many people -- including the article, to an extent -- and also people in the comments cast shade on this distro and the people who may try Linux either for the first time, or perhaps one more time, because they tried and failed to switch before.

Calling it flashy is an especially amusing critique. You couldn't kick your way through the 90s and 2000s without the endless parade of semi-transparent terminal windows running on various shades of windowmaker, enlightenment, kde, etc. all to show off how much more advanced the graphics pipeline and customisation was compared to Windows or Mac at the time. So this is hardly a new thing.

Let's hope this distro picks up steam; that it helps convert people who are fed up with Apple and Microsoft to another way of doing things. Arch + hyprland is a fine place to start.

[flagged]

Emacs can easily work with non-posix tools. Many people use ag, ripgrep, or ack in lieu of grep. You change the command string Emacs uses for finding and grepping to your tool of choice.

What? Emacs has eglot built in. It has had native grep and find stuff for decades.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Gr...

You can change the exec-path to point to your cross compiled grep tool --- or you can change the command string to your tool of choice.

The knocks against Emacs feel unwarranted. It has plenty of colour; it has mouse support, even in the terminal, but not all terminals support it, so it's optional. It also runs in a GUI with, you know, image support and whatnot.

You can rail against its defaults, but do not make misleading claims.

False equivalence. That the creators of various PHP blogging platforms sucked at security does not invalidate the poster's point that a self-hosted CMS with a simple comment system is indeed much simpler and easier to reason about.

Yeesh. "Those darn 40+-something millennials and their differing tastes!"

Rock 'died' because it's been around for 50 years; were the favourite of boomers who ensured it always had air-time; and now they're out to pasture and other music styles reign. My dad was a pro drummer in the 70s and hated everything that wasn't rock or metal. He was incapable of appreciating anything else. Or so he said.

As a kid of the 90s, I could never quite find music that fit me. Sure, I liked some rock and roll, pop, and so on --- but when I was first introduced to techno (Antiloop - Believe, to be specific) at a LAN party I knew I'd found my home: techno and then trance.

But good luck finding Antiloop or the nascent trance on MTV or commercial radio in the 90s. The people who ran those things didn't like it, know about it, listen to it, or felt it had commercial value. So I had to learn about it from randos at a LAN party.

Seconds. I mean, something on the order of that, anyway. Fast enough to iterate but I mean it's still the weakest link in the iteration chain of course.

Good to know, thanks! Now that I 3d print (apropos hobbies with infinite depth...) I would probably just CAD design and print my own instead, but I've come to accept the limitations, such as it is, of the moonlander's tenting design.

> I switched from a Moonlander to a UHK, and the programming time is ~instant. You click flash and in 1-2 seconds it's done. For the Moonlander you have to download the firmware, find the file, drag and drop onto the flashing tool, and wait 10+ seconds. It's amazing how much of a difference that made for me.

Actually I point out you can use webusb to flash it (if you use Chrome) further down ...

That assumes the OOM killer kills the right thing. It may well choose to kill something ancillary, which causes your OOM program to just hang or misbehave wildly.

The real danger in all of this, swap or no, is the shitty OOMKiller in Linux.

Some of us use triple dash to indicate the same thing. Like LateX. You should add that too.

Care to show me a job board bursting at the seams with Delphi jobs?

Uh-huh. There are zero -- sorry, nil -- Delphi jobs on jobserve in the UK. That is one of the leading job sites in the UK. Zero. There are 282 jobs with python in the job description.

Yes, that sounds like a Delphi developer alright.

I worked with Delphi personally and professionally for many, many years. You were at the precipice of unemployment in the 2000s if you used it then. To do it now? You're like a looney toons character suspended in mid-air. There's Delphi work around, to be sure, but you're competing against people with 30 years of commercial experience building -- or rather just keeping them limping along -- today, and they are as desperate as the Powerbuilder, Oracle Forms, FoxPro and Lotus Domino folk in scratching out an income in a stagnant pool.

Delphi died an ignominious death a long time ago, and it is truly sad. I miss it; frontend development today is a joke compared to what we could do with Delphi. But so what? It's dead. And it's not coming back.

Right, but it instantiates it _once_ on module load! That is the point I am making; nothing else.