joepie91_

Data expiration is easy enough if the expiry is a fixed term, you just 'chop off' a chunk of the internal DAG. But how would you implement 'logical deletion' under these circumstances?

To achieve "client does not need to trust the database engine", it would need to be possible for the client to independently walk the history of the database and verify that neither its mutations nor its order has been tampered with. For that, the actual data needs to somehow be taken into account in the signature, commit hash, whatever.

So when you logically delete data, how are you _not_ breaking that hash chain? The original data that produced a signature/hash is no longer available, and therefore not verifiable anymore. This means that the relevant commit cannot be trusted, and therefore neither can anything that comes before it.

Or are you just trusting that any 'redacted' commit is valid without actually verifying its hash? In that case you'd be compromising the trustless nature, because the database engine could autonomously decide to redact a commit.

I'd have a look at the research paper, if it weren't hidden behind an e-mail wall. I was initially happy to see a 'research paper' link at all, but that e-mail wall definitely compromises my first impression of immudb, because now it looks like I'll be getting a corporate brochure and not an actual technical paper.

> Basically a hash value denotes the entire state of the database (including the entire history). This hash may be cryptographically signed and exported from the server. immudb SDKs keeps track of the last verified state, each time a new one is received, it's cryptographically validated.

Okay, but how do you persist that hash across eg. client restarts? You obviously can't store it in the database. And this does not sound like "zero trust" to me - that's a much higher bar to meet, and would allow for eg. untrusted writers.

As I understand it right now, immudb works more or less the same way that Git does; it's a DAG of database (instead of file) mutations, and you can persist the latest commit hash to ensure that someone hasn't messed with what a branch points to.

Which can be useful, don't get me wrong, but it's not "zero trust" and it's certainly a fairly niche security feature.

Edit: To be clear, I'm very much in favour of what immudb seem to be trying to do - getting enterprises away from ultimately dysfunctional "blockchains" by providing something more sound with nominally the same features/appeal. But it's always important to be very clear about what your tech does or doesn't provide, blockchain or not.

I'm not following. Dependencies can be nested, so you cannot assume that a dependency by a given name can be satisfied by a previously loaded dependency by the same name. Which means you still need as many serial roundtrips as there are depth levels, whether you parse in parallel or not.

Sure, you can cut down on the delay introduced by the parsing, but 10 depth levels over a 100ms connection is still going to take a second to fetch, because you simply can't know the N+1th dependency until you have at least completed the Nth roundtrip.

Note how I was specifically talking about depth-wise.

The build times I listed are including a Babel plugin.

It's a fundamental technical constraint of any tool-less setup. At some point you need to traverse the dependency tree by parsing modules and following imports, and your choice is to do that either:

1) on the client, across the network, one roundtrip for every level of depth, or 2) in a build environment, directly on the filesystem

Option 2 means you need some kind of build tool to make it work, and by that point it doesn't really matter anymore whether the tool just traverses the dependencies and makes a list of filenames, or also concatenates their contents into a bundle.

And that is why the fundamental premise of ESM cannot work; there are no technical options besides those two. If you want to avoid network roundtrips, you must have build tooling. No way around it.

It's a bit more complicated than that because you'd not want to match such things if eg. they exist inside of another string literal; but the actual implementation of 'dependency collection' in various bundlers isn't too far off from this. They just often do an AST match instead of a string match.

This is not actually a meaningful benefit that ESM has in practice, as I've explained in my article.

Worse, even if they were all fetched in parallel, you would still see terrible loading times simply because a dependency graph can only be traversed depth-wise serially. Doesn't matter what network protocol you use or how parallel it is.

Believe me, I would much rather not have had to build that hack. But considering that I want my development tools to actually, y'know, work, what would you expect me to do?

Hi, author here. I'm going to ignore the personal attacks and simply point out that my dev build processes typically have a startup time of under 5 seconds even for large projects, and a rebuild time of under 500ms. This is with Browserify.

If you are having very slow build times with your existing toolchain, the problem isn't the bundling, which is an extremely fast operation. It's almost certainly going to be one specific computationally-intensive plugin that you either don't need, or would also need if using ESM.

I would have considered this a valid argument if overly-clever use of `require` was actually a problem in JS. But it's not! These 'simple' types of obvious cases are the only types of cases that people actually use this syntax for in practice.

Mixed. Some things - like the theme switcher - break constantly because KDE has no awareness of NixOS and its configuration management approach, and indeed its configuration setup seems to change all the time.

The base setup works fine though, I've only had some core functionality break once, and that was after an upgrade to a new NixOS version - the progress display integration thingem for the file manager was broken.

> set of overengineered abstractions

While there are definitely a lot of remaining documentation and usability issues with Nix as it stands today, the core model is far from 'overengineered' - if anything, it's orders of magnitude less complex than the organically-grown cobbled-together pile of tools and conventions that 'traditional' distros are made out of.

Nix having a well-defined, complete, specified-upfront, coherent model doesn't make it 'overengineered'; it just means that the tools were designed from the start to help you manage the complexity of system management, rather than just kind of leaving it implicit and letting the end user and/or packager deal with the fallout later through an ever-growing collection of workarounds and patches and scripts.

It's completely valid to decide that NixOS is not (yet) for you due to the learning curve that still exists; I frequently warn people away from NixOS (when they are not prepared to deal with that) for this precise reason. But please don't conflate that with 'bad design'.

> I don't mind learning per se but if I put the time in it I'd like it to be for something that's useful in more places. Like ansible.

Depending on whether you mean "used by more people" or "applicable to more problems"... if the latter, tools like morph or NixOps might be of interest to you, which essentially extend Nix to "across multiple remote machines", which means that de facto you end up with an orchestration tool like Ansible or Puppet.

> I've learned more about cmake from mkDerivation that anywhere else.

This is something I find really fascinating about Nix (or more precisely nixpkgs) that gets overlooked a lot: it is essentially a giant database that documents how different build tools work, how different projects are built, and so on, in an exhaustive and consistent manner.

That can be an extremely valuable resource to have in your back pocket, even if you're not actually using Nix!

"not afraid to fuck up anything" likely refers more to the ability to rollback the system to any (non-deleted) previous revision of the system configuration, directly from the bootloader, which means you can easily recover even from a broken kernel.

This applies regardless of whether you are packaging/updating something in the package set yourself, or using something that someone else packaged.

Not to mention that since systems are deterministically built, you can usually reliably reproduce the failure mode on a separate system and investigate it there.

"Hey, what's the store hash of the thing that's failing, so I can grab it and reproduce it locally" is a thing you can just do with Nix.

Essentially, Nix is a build tool and/or package manager that provides a lot of baseline guarantees about determinism and dependency (not runtime!) isolation and rollbacks and so on.

NixOS is a distro/OS built on top of Nix, which extends this model to not only packages, but the entire system configuration, bootloader, local container management, and so on.

While all of that is correct, I feel like you're leaving the most important part unspoken: Nix (and, by extension, NixOS) prevents this by construction, so that you are no longer dependent on somebody using the tool perfectly in every single place to not have this issue.

It's the difference between "you can use this tool safely" and "the tool makes sure that you will use it safely", basically.

Because Bitcoin is something that some people do actually use in practice. And even then it's a rounding error in the payments I handle.

Correct. I am one of the seemingly handful of people who actually tries to use cryptocurrencies as currencies (and have been doing so since getting involved as an early adopter).

I can assure you that that has become more and more difficult and risky over the years thanks to speculative vultures and the dynamics described in the gist. If anything, this should tell you that I'm not some armchair complainer who doesn't understand how it works.

I'm also not sure why you seem to be implying some sort of conflict of interest here, since I am arguing against it.

The difference is that you - presumably - aren't the de facto steward of one of the most important open communication platforms on the planet that literal nation states rely on to function correctly, in addition to the general public.

> And yes, I believe that if you have expectations on the availability of your website, it should be tested frequently enough, with automation or simply having the regular team working on the product or QA use newer browser versions on the regular.

This is so, so illustrative of the problem with the Chrome team's attitude - I'm not sure you could imply "the web is for businesses, amateurs should get out and just consume" any more heavily if you tried.

"We have the choice of destroying your life and have chosen to only do so if you don't do what we want" is not a virtue, it's blackmail.

They could also choose to just, y'know, not report them to anything full stop, unconditionally, like any reasonable empathic human would.

Hey, speak for yourself. I've been speaking out against such practices for years in the same way that I'm speaking out against Copilot.

If you use "but there are other horrible things!" as a justification to trivialize one horrible thing, what do you think the outcome is when that strategy is applied to the world at large? Bingo, "nothing matters" and no consequences ever follow malicious behaviour, because there's always something else that's also bad.

Don't do this.

> I could be wrong but I think nix is focused more on just the producing the artifact part.

That is only true to a point. Nix has an extremely broad definition of what constitutes a "build", in practice, and this process can include things like tests.

That having been said, there are undoubtedly certain tasks that Nix itself is not great at - but when you think of Nix more as a system primitive for expressing build processes rather than as a universal do-everything tool, that just means you would build tooling on top of it for those tasks, like Hydra does for CI for example.

That way everybody wins; you don't need to reinvent the build orchestration parts of the process, it interoperates with the entire existing package set, and the broader Nix community gains a new tool that helps them solve their problems more effectively.

> pure sloppiness on the part of github

Considering that their entire business model from the start has been "capturing the open-source ecosystem onto a closed and proprietary platform that doesn't interoperate", I'm more inclined to assume malice here than 'sloppiness'.

Edit: By which I mean that their approach most likely just couldn't work well enough for end users, in terms of hassle, if they actually did it above board and included licensing information. So not caring about that was the profitable option.

> I find it hard to believe that an organisation with GitHub's expertise and resources haven't analysed (and got comfortable with) the legal issues associated with the use of GPL / AGPL software to train CoPilot

Almost certainly. But what people tend to forget is that "working out the correct legal interpretation" isn't actually the job of a lawyer; it's the job of a judge. The job of a lawyer is to devise a legal strategy that works for the client.

In practice that will quite often mean "yes, this is illegal, but we will publicly claim that it's legal and ride the wave, and the consequences will cost us less than we can profit off it".

Even if it's not explicitly stated like that and couched in vague "legal risk" handwaving, the lawyer ultimately works for their client and that's who their allegiance is to, not to the law.

I think they're referring to the idea of companies jealously guarding access to any and all source code because copyright doesn't protect them anymore, while FOSS authors have no protections.

I don't think that that's a realistic fear, though; this is basically already how it works with FOSS code being used in remotely-hosted SaaS systems and there being no effective legal recourse for FOSS authors.

It just doesn't officially say it yet in a law.