This was a solo project, for about a few months of evenings. What it does not defend against, up front: an actively malicious server (the JS-delivery problem that basically every browser-E2E app shares), a compromised device, etc. Those are in the design doc.
I'd most like feedback on the threat model, and on the auth path: login still goes through a normal password-to-server handshake, and moving to a PAKE (OPAQUE/SRP) so the password never reaches the server is the obvious open item I have not done yet. Happy to get into the cryptography also, the no-bank-connection decision, or why it is bootstrapped and not VC scaled.
I'm not sure about this one, though. Today, my experience with LLMs is that they're already pretty helpful for unit test edge cases I wouldn't have thought of. If you mean broader functional tests then maybe, but I wouldn't say the same for unit tests.
Yes but in my experience, LLMs are prone to cheating and implementing "shortcuts" that look functional but are in fact not really if you look closely. At the moment, you still need a human in the loop to make sure the LLM actually did what it promised and didn't cheat.
Reading through the thread, it's striking how many people are feeling the same mix of excitement and exhaustion you describe. I'm in that camp too... the tools are incredible, but the pace and expectations around them can feel overwhelming.
I fully agree with what you say regarding Boris, but I would emphasize that I don't think he has malicious intention either. He still is doing his job, to showcase the features their product offers.
I'm curious how much of this behaviour is still intentional design vs. just inertia. Are the modern filesystems still constrained by these older choices, or is it mostly for compatibility?
The filesystems of macOS are particularly opinionated, much more than most Unices which tend toward "anything is allowed [and usually preserved] except \0 and /".
macOS supports case-insensitivity[0] and performs unicode normalization[1] on filenames, and decomposes name data to an extent that the question "what does the fs see" is a bit moot.
With that said, the internal storage of filenames in APFS are a nul-terminated UTF-8 string[2], with (i'm pretty sure) colons as colons, which the Finder displays as slashes.
[0] if you make a file named "Makefile" then touch a file named "makefile", it'll touch the first file, instead of making a second file.
[1] if you make a file named "schön" (s-c-h-combining¨-o-n) and then search for (s-c-h-ö-n), you can find it, or vice versa. The particular normalization/canonicalization used is NFD.
Well, strictly speaking Linux does too, since it supports mounting local or remote filesystems with this feature
For a long time, the real distinction was that “native” Linux filesystems didn’t support it, but “foreign” ones did. However, nowadays even some of the “native” filesystems have optional support for case-insensitivity (e.g. casefold feature on ext4)
The real difference now: on macOS, it is normal to have this feature turned on, exceptional to have it disabled; on Linux, it is the other way around
Combining marks come after the character they modify, btw. (Presumably thanks to support from things like harfbuzz, modern systems will happily put two dots above an h.)
You can imagine many internal APIs as taking "look up this <name> from directory <handle>". Surprisingly often the only practical limit is that the name does not contain NULL bytes.
Path separators, whether to accept directory entries with path separator in them, etc. are usually handled layer above
Genuine question, how did you get to these 11 LLMs instead of 10 or 12? I'm interested in understanding how you did benchmark these 11 LLMs or whether it was an arbitrary ensemble you selected.
DuckDB is a great example of how far you can get by removing unnecessary layers... Columnar layout and vectorized execution is a powerful combination for OLAP workloads.
the CSV parser is really good too. Anyone who's struggled with consuming CSV/TSV knows this is not trivial. DuckDB uses hueristics to be very liberal in what it accepts without crapping out like many parsers.
I wrote some of my concerns about going open-source with it in the other reply. Mainly, I want to build a commercial tool, true open-source is not that obvious to go with, but still possible of course. I'm still not sure about the proper way.
