Where is the evidence for this? Where is the evidence that you can and should mix config management all of the way down the OS stack? How many containerization concepts do we need? Docker, lxc, VMs, and now NixOS? If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again. I'm open to nicer restructuring of the Linux fileystem, but this is really re-inventing the wheel trying to polish over ugly parts that are ugly for a reason. Keep useful abstractions separate!
One problem that NixOS solves is to be able to use different tools on the same host in different versions easily(1) and in a reproducible way(2). Docker containers can be used to solve 1), but they are in some sense overkill and quite a few uses cases. If you are a developer who only wants do use different compilers then Docker containers are not really ideal, because they also enforce process isolation. Also there is the popular believe that Docker containers also solve 2) that is not really completely true. Yes you can run a Docker image in a reproducible way on different machines, but cannot necessarily reproduce the Docker image, at least not with the standard Docker tools. You can use Nix to create Docker images in a reproducible way.
> If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again.
The basic concept of Nix is (a) use the `--prefix` argument of ./configure scripts to keep things apart, and (b) use the `PATH` end var to choose what we want to run.
In comparison, containers are much more recent, require more invasive changes (i.e. support from the kernel), etc.
Personally, I like using containers to run binaries. Putting a whole Linux/Busybox installation inside one seems to defeat the point though...
Sure, the project is called Endpipe and it's an attempt to create a privacy-preserving cloud database. The idea is a Google Cloud Firestore alternative that works offline and synchronizes in real-time, but without the data being accessible to the server. The encryption key never leaves the client or trusted proxy.
We want to keep sensitive data like Protected Health Information (PHI) from getting into the wrong hands. Any hands really, but yours. You own your data.
Endpipe is offline-first and needs client storage to be secure and practically efficient, so it's different than most cloud databases. The client is trusted, and there can be also a trusted proxy, the server is untrusted. The server is distributed and maliciously secure, it can have arbitrary number of Byzantine-faulty replicas. It is a multi-model database (document, object and file) with range queries, automatic indexing and eventual consistency with explicit causality, which is used for conflict resolution. There are conflict-free operations for collaboration. It is multi-platform, the client core is being written in C/Zig/WASM on top of SQLite. Android, iOS, Linux, macOS and Windows are supported, eventually the web will be once there is a better File System Access API with origin private file system support. A Dart/Flutter library is the first priority, that is the beachhead. The supported data types are Bool, Int, BigInt, Double, String, DateTime, List<E>, Set<E>, Map<K,V>, Uint8List, Uint16List, Uint32List, Uint64List, Int8List, Int16List, Int32List, Int64List, Float32List and Float64List. Collections are generic, E, K and V identifies the type of objects they can store, which make collections homogeneous, but heterogeneous collections are also possible by not specifying the type. Our serialization format is space efficient, integers up to 127 are represented by one byte, smaller and larger integers use a variable-length (1 to 9 bytes) zigzag integer encoding. There are holes for supporting arbitrary-precision binary and decimal floating point numbers in the future. Large values up to 16 TiB are supported. Query results are available as data streams, they receive realtime updates, however Endpipe can delay updates for query smoothing. Endpipe can issue fake queries, prefetch or buffer data from the server data structure, which is essentially a dynamic volume-hiding encrypted multi-map with forward and backward privacy.
> management engined access to registers and DMA being a weakness
If you are talking about Intel ME on the client, we trust the client, we have no other choice. Client-side encryption is planned, it would offer some protection against snapshot adversaries, but not against a persistent adversary that has access to your device. History independence to be able to do secure deletion is not a goal.
On the server it doesn't matter whether it is curious or malicious, our threat model is a persistent adversary that has continuous total access to the server. Endpipe uses the server interactively to store and retrieve encrypted data, and the server is allowed to spy and lie, it's only function is to send the original data back, which the client can verify.
I disagree. ZFS is great on Linux. The killer feature of FBSD is its simplicity and lack of incoherence in focus, which all the Linux distros suffer from. People don't see to be able to differentiate between these issues: Linux distributions' diversity of features and options is not a problem - it is the lack of focus & coherency of their management. This makes it harder to help other people on the same distro, to collaborate about bugs on the same distro, etc... Then you read an OBSD/FBSD thread from developers who aren't really better than developers on Linux threads - and you see much more coherency; because of the coherency in the systems they're working on.
Normalization of pedophilia is occurring and Facebook, Google, Twitter, YouTube, HN, and all of the usual suspects are complicit. There are now 3 TED Talks promoting pedophilia normalization.
And where have you been for the last thousand years? Or the entirety of human history for that matter?
We are a pretty awful species. But if we can’t talk openly and honestly about how awful we are, we’ll never need to own our own awfulness, which means we’ll never have to try to be any better than that. Because it’s so much easier and politically expedient just to project all of our own personal awfulness onto the Other.
Thus, all good discussions should start in a mirror.
Agreed. Good support for compose currently, and swarm is usually overkill. With a bit more elegant HA functionality, docker-compose could be the go-to for many more. The comment below claiming he doesn't understand your comment reminds me of all of those who will say "well its not FOR production" - seems more like superstition than science.
