If there is no database, where one should persist state?
Most software is stateful and needs to persist state across restarts, so I would argue that one needs at least SQLite.
On SQLite being safe default: in practice it means supporting multiple databases, say SQLite and Postgres, this is more complicated that supporting just Postgres. As soon as a project leaves localhost and enters cloud development you need talk to a database over network, which warrants MySQL or Postgres.
Which is more complicated: supporting a docker container with mysql or Postgres for local development OR supporting multiple databases in the project?
Of course, the answer could be “it depends”, I but I would not call SQLite a default choice. It would be if you are writing desktop or mobile app, but for anything like a web app it’s a questionable choice.
I think the findings that the LLM triggers “desperation” like emotions when it about to run out of tokens in a coding session have practical implications. The tasks needs to be planned, so that they are likely to be consistent before the session runs into limits, to avoid issues like LLM starts hardcoding values from a test harnesses into UI layer to make the tests pass.
I’m was thinking about building native windows UI, wrapping around cross platform library written in swift. I did not know it was that messy and complicated.
I don't think it was a confirmed story. That is, the tiny "grain of rice" size Ethernet module that CEO of a security audit company allegedly found, was not present in other SuperMicro servers. SuperMicro itself, as well as it's buggest customers did not confirm the findings.
From what i recall, the story was very vague, there were no pictures of the specific chip, no pictures of the motherboard of the motherboard that would include serial, i.e. no details that would accompany a serious security research.
The only photo I saw of the "hidden Ethernet module" was a ceramic RF filter or diplexer, basically a passive $2 part that does nothing on its own, and that would have stuck out like a sore thumb if actually installed in the area where it was depicted.
Just a random surface-mount component that someone pulled off another board or found on the floor behind a workbench. Allegedly.
100%! Lots of issues are only discovered when enough code has been written. More than that , other issues are discovered only when the project is actually deployed as MVP.
TDD helps a lot, but it’s no guarantee - LLM is smart enough to “fake” the code to pass tests .
I’m working on project - a password manager, where I have full end to end test harnesses - cli client makes changes, sync them to the server and then observe the data in iOS app running in the emulator. More than once I noticed codex just hard coded expected values from the test harnesses directly into UI layout in iOS app to make the test pass…
Similar issues in the crypto layer - tests were written first , then code was written . During the review I noticed that the code was made to just pass the test - the logic was to check if signature values exists
instead of checking if crypto signature is valid.
LLM can help with code reviews as well, but it has to be guided specifically what to look for for. This is with codex 5.4 model
I’m at level 6 according to this article. I have solid harness, but I still need to review the code so I can understand how to plan for the next set of changes .
Also, I’m struggling to take it to multiple agents level, mostly because things depend on each other in the project - most changes cut across UI, protocol and the server side, so not clear how agents would merge incompatible versions.
Verification is a tricky part as well, all tests could be passing, including end to end integration and visual tests, but my verification still catches things like data is not persisted or crypto signatures not verified.
I've glanced over the article - I think using SQLCypher makes sense if it benefits Keepass project internally, meaning makes it easier to implement new features or fix bugs.
I do not see how it would benefits end users in any significant way. Sure, you can look inside the database, how many people need that?
Dumping the database to CSV is not a good backup, schema changes over time, what was dumped from one version of the app would not work for importing into another version if schema changes. Backup it needs a versioned schema format, which would actually look like KDBX format if implemented in XML :-)
I'm working on an alternative to KeePass/KeepassXC called Lockstep - it is local-first password manager that supports sync natively.
It uses SQLCypher as local data store and keeps KeePass-compatible data model - supports import of .kdbx database.
SQLCypher and different schema used in Lockstep alone did not solve any problems that I have with Keepass. Those problems are sync and sharing.
Solving sync and sharing cannot be done on whole database file level, as it implemented now in KeePass. Changes need to be tracked at the password record level, all changes need to persisted as operations log and that log needs to be distributed across devices.
The above means writing a whole protocol, and that's a lot more work than changing local storage.
I'd say it's mainly to do with browser/iOS plugins not being responsive. I find myself often resorting to opening the app and copying and pasting the password or other info because autofill function doesn't work on different websites.
Otherwise minor UI things like categories on the sidebar which made it easy to navigate, but they got rid of it a while back.
Most software is stateful and needs to persist state across restarts, so I would argue that one needs at least SQLite.
On SQLite being safe default: in practice it means supporting multiple databases, say SQLite and Postgres, this is more complicated that supporting just Postgres. As soon as a project leaves localhost and enters cloud development you need talk to a database over network, which warrants MySQL or Postgres.
Which is more complicated: supporting a docker container with mysql or Postgres for local development OR supporting multiple databases in the project?
Of course, the answer could be “it depends”, I but I would not call SQLite a default choice. It would be if you are writing desktop or mobile app, but for anything like a web app it’s a questionable choice.
reply