Increasingly, I'd like the code to live alongside a journal and research log. My workflow right now is spending most of my time in Obsidian writing design docs for features, and then manually managing claude sessions that I paste them back and forth into. I have a page in obsidian for each ongoing session, and I record my prompts, forked paths, thoughts on future directions, etc. It seems natural that at some point this (code, journal, LLM context) will all be unified.
Juice is cool, but tradeoffs around which metadata store you choose end up being very important. It also writes files in it's own uninterpretable format to object storage, so if you lose the metadata store, you lose your data.
When we tried it at Krea we ended up moving on because we couldn't get sufficient performance to train on, and having to choose which datacenter to deploy our metadata store on essentially forced us to only use it one location at a time.
I'm betting this is on the front page today (as opposed to any other day; Juice is very neat and doesn't need us to hype it) because of our Sprites post, which goes into some detail about how we use Juice (for the time being; I'm not sure if we'll keep it this way).
The TL;DR relevant to your comment is: we tore out a lot of the metadata stuff, and our metadata storage is SQLite + Litestream.io, which gives us fast local read/write, enough systemwide atomicity (all atomicity in our setting runs asymptotically against "someone could just cut the power at any moment"), and preserves "durably stored to object storage".
Litestream.io is amazing. Using sqlite as a DB in a typical relational data model where objects are related mean most read then write transactions would have to one node, but if the using it for blobs as first class objects(e.g. video uploads or sensor data) which are independent probably means you can shard and scale your set up the wazoo right?
In large-scale metadata scenarios, JFS recommends using a distributed key-value store to host metadata, such as TiKV or FoundationDB. Based on my experience with large JFS users, most of them choose TiKV.
> It also writes files in it's own uninterpretable format to object storage, so if you lose the metadata store, you lose your data.
That's so confusing to me I had to read it five times. Are you saying you lose the metadata, or that the underlying data is actually mangled or gone, or merely that you lose the metadata?
One of the greatest features of something like this to me would be the ability to durable even beyond JuiceFS access to my data in a bad situation. Even if JuiceFS totally messes up, my data is still in S3 (and with versioning etc even if juicefs mangles or deletes my data, still). So odd to design this kind of software and lose this property.
FUSE generally has low overall performance because of an additional data transfer process between the kernel space and user space, which is less than ideal for AI training.
As I understand it, if the metadata is lost then the whole filesystem is lost.
I think this is a common failure mode in filesystems. For example, in ZFS, if you store your metadata on a separate device and that device is destroyed, the whole pool is useless.
To be honest, the two biggest drivers for this project were Cost and Signal Integrity.
1. Cost: This was my main frustration. The Cyton is currently priced at
1,249.I managed to get the Cerelog ESP−EEG down to
299 (assembled). I really wanted to lower the barrier to entry for individual researchers and hackers who can't drop a grand on a hobby board.
2. The Bias/Noise Implementation: While we both use the same high-end ADC (TI ADS1299), I implemented the Bias (Drive Right Leg) differently. I designed a true closed-loop feedback system. By actively driving the inverted common-mode signal back into the body, the board follows the TI spec aggressively for helping cancel out 60Hz mains hum
Regarding the analog front-end: The current version keeps the inputs flexible (firmware configurable) for different montages. However, I’ve found that most researchers just stick to a single standard montage configuration. Because the Cyton tries to be a "jack of all trades" for every possible montage, it compromises on physical filtering. For future revisions, I plan to trade some of that flexibility for dedicated common-mode and differential hardware filtering to lower the noise floor even further. I already had this on a previous revision prototype but decided to take not out for simplified testing. I'd like to add it back in to a future revision after some more prototype testing.
3. Connectivity: I’m using the ESP32 to stream over WiFi rather than a proprietary USB dongle. Ive been trying to get BLE SW working as well but noticed MAC drivers aren't the most friendly to my implementation.
have not used longhorn, but we are currently in the process of migrating off of ceph after an extremely painful relationship with it. Ceph has fundamental design flaws (like the way it handles subtree pinning) that, IMO, make more modern distributed filesystems very useful. SeaweedFS is also cool, and for high performance use cases, weka is expensive but good.
Are there any distributed POSIX filesystems which don’t suck? I think part of the issue is that POSIX compliant filesystem just doesn’t scale, and you are just seeing that?
I think Lustre works fairly well. At the very least, it's used in a lot of HPC centers to handle large filesystems that get hammered by lots of nodes concurrently. It's open source so nominally free although getting a support contract from specialized consulting firm might be pricey.
You're going to have to open the image and then go to the third image. I thought it was interesting that OCI pegs Lustre at 8Gb/s and their high performance FS at much higher than that... 20-80.
Basically, we are building this at Archil (https://archil.com). The reason these things are generally super expensive is that it’s incredibly hard to build.
weka seems to Just Work from our tests so far, even under pretty extreme load with hundreds of mounts on different machines, lots of small files, etc... Unfortunately it's ungodly expensive.
Hmm idk about the focus on aesthetics. GPT image is your top image model, a model which is famously poor on aesthetics (though excellent on prompt adherence). I admit it's a difficult thing to eval, though, as in most side by side comparisons users will always pick the image with better prompt adherence regardless of instructions.
iOS Engineer - Build Krea’s first iOS app from the ground up, working closely with our designer to reimagine what multimedia AI looks like on phones and tablets. Expect to work heavily with 3D, streaming video / images to and from models running on our cluster, and local image editing.
ML or Performance Engineer - Depending on your skillset, work with either our inference, research, or data teams to speed up hot swapping models on GPU, implement ahead of time compilation for torch models in different codebases, experiment with different RL methods with diffusion models, implement techniques like CausVid on open source video models, write CUDA kernels for optimized media loading.
I'm sure this is very nice, but the article reads as if written by AI. The first thing I'd want to see is an example workflow (both code and configuration) in a realistic use case. Instead, there's a lot of "powerful and flexible" language, but the example workflow doesn't come until halfway down, and then it's just foobar
