s_ting765

You could check out SQLite's auto_vacuum which reclaims space without rebuilding the entire db https://sqlite.org/pragma.html#pragma_auto_vacuum

My gripe is with Rust rewrites. Not uv. Though I very much think uv is overhyped.

Rust rewrites are known for breaking (compatibility with) working software. That's all there is to them.

For web development I would say avoid high-level frameworks as much as you can. Most of them are built for hand-holding developers which is counterproductive to learning the fundamentals and are usually inflexible to demands outside the "happy path".

I use the same exact trick from the source the article mentions.

I call it `temu` anubis. https://github.com/rhee876527/expert-octo-robot/blob/f28e48f...

Jokes aside, the whole web seems to be trending towards some kind of wall (pay, login, app etc.) and this ultimately sucks for the open internet.

You may be thinking of CSRF mitigations. XSS exploits are more dangerous and can do more than steal sessions.

Depends on specific app use case. Nginx doesn't work with it but valkey will.

You mean safer languages like Fil-C.

> I have version 1.30.0.4 installed.

Can confirm same case here. App was installed from f-droid, no longer linked to the store.

Rust's notorious compile times sticks out like a sore thumb partly because other system languages can run laps before your Rust build is done. And also because everyone and their grandma swears Rust is blazing fast.

Until you have to compile the program without prior build cache or start a build in a CI pipeline.

> “an airline wants its front-line customer service fully managed by LLM.”

This has been experimented on before by many companies over the recent years, most notably Klarna which was among the earliest guinea pigs for it and had to later on backtrack on this "novel" idea when the results came out.

People get confused talking about AI. For some reason they skip the fact that a human prompted the LLM for the generated output. One could almost think AI is an agent all on its own.

Or search companies are forcing LLM products on visitors and claim "see! everyone is using our AI search instead of the regular search".

> the language per se is fast enough

I literally explained why this is not the case.

And Nextcloud being slow in general is not a new complaint from users.

At the risk of sounding out the obvious. PHP is limited to single threaded processes and has garbage collection. It's certainly not the fastest language one could use for handling multiple concurrent jobs.

Nextcloud server is written in PHP. Of course it is slow. It's also designed to be used as an office productivity suite meaning a lot of features you may not actually use are enabled by default and those services come with their own cronjobs and so on.

Vibe code hell is the wrong term to be used here. Vibe coding is used in reference to people now rediscovering low code and who have no interest at all in learning about nor owning the code the LLM generated.

Chrome has a flag for this but I haven't tested it personally. #enable-user-navigation-capturing-pwa

Status report says issue with authentication fixed but it's far worse than that. This incident also took down docker pull for public images with it.

You're wrong. The obsidian flatpak ships by default with access to /home. https://github.com/flathub/md.obsidian.Obsidian/blob/5e594a4...

Security/dependancy updates depend solely on the specific maintainers. The platform itself doesn't automatically fix the developer or maintainer lethargy in this regard.

A warning will dissuade users from upgrading their system instead of doing the manual intervention.

Google cloud dropped gVisor in favor of micro VMs.

https://cloud.google.com/blog/products/serverless/cloud-run-...

Many things but summarily it would be the promise of a 1:1 drop-in replacement for Docker.

You are going to have to pry Docker from my cold dead hands.

Podman is a failed reverse-engineering of cherry-picked so-called "good" parts of Docker.

Pretty sure this is outdated news.

> How do you know that? How do you know that I wouldn't write an integrated test which verifies that my parser is correctly integrated with my system?

You already said so in your first argument: Unit tests are cheaper and better(than integrated tests I presume).

Am simply following your behavior pattern here.

> The point is, there is typically more than one path through the logic of a parser. The cheapest way to test these paths is in isolation. If there are five paths you care about, you could write six integrated tests — one for each of the five paths you care about, and one to verify that your parser is correctly integrated with your system, or of course you could write five isolated tests (which are cheaper to write and cheaper to execute) and one integrated test.

This is nonsense. A standard parser takes one input and does processing of this data to give an expected output. An integration test checks the parser does this one objective correctly. You have boiled down the 5 unit tests that don't test for anything *real into 1 integrated test that objectively gives better test data.

*code is not real until it does some business logic!

> Also if all else was equal between multiple types of test, there wouldn't be need for comparison ala cheaper.

> …What? I'm sorry, this is near enough unintelligible.

Maybe try to froth less when reading my comments, your brain might have some capacity left to understand comparitive adjectives.

Your example scenario avoided doing an end to end test for the data processing involving the parser instead opting for a unit test just for the parser.

We have developer sandboxes for this purpose so you don't have to guess the structure of the data you will receive from the actual server.

Also if all else was equal between multiple types of test, there wouldn't be need for comparison ala cheaper.

Cheaper to run tests does not mean better. And your example does not test for real world behavior therefore the test is lower quality by definition.

Here's the argument backing up my claim.

Unit tests don't matter when you have other types of testing like functional or integration testing that will tell you whether your code has the intended behavior and effect when run.

In the above statement unit tests is also considered as code.

That's where the redundancy comes from.