I don't think this has been tested in court, but the recent flood of Nintendo game decompilations is likely to change that.

Most businesses can and many businesses do run efficiently out of shared spreadsheets. Choosing the processes well is the hard part, but there's just not much computational complexity in the execution, nor more data than can be easily processed by a single machine.

When the difficulty of a task is neatly encompassed in a 200 word ticket and the implementation lacks much engineering challenge, AI can pretty reliably write the code-- mediocre code for mediocre challenges.

A huge fraction of the software economy runs on CRUD and some business logic. There just isn't much complexity inherent in any of the feature sets.

But that's besides the point. When people say "RDBMS" or "filesystem" they mean the full suite of SQL queries and POSIX semantics-- neither of which you get with KV stores like BigTable or distributed storage like Colossus.

The simplest example of POSIX semantics that are rapidly discarded is the "fast folder move" operation. This is difficult to impossible to achieve when you have keys representing the full path of the file, and is generally easier to implement with hierarchical directory entries. However, many applications are absolutely fine with the semantics of "write entire file, read file, delete file", which enables huge simplifications and optimizations!

If instead you run LLM prediction and then encode the probability of the next token of the input text you want to encode (from the cumulative distribution, a number in [0, 1]) using arithmetic coding, you can run the same operation in reverse to achieve lossless compression.

The tricky part is ensuring that your LLM executes absolutely deterministically, because you need to make sure that the encoder and decoder have the same probability distribution map at each step.

You want to precompute the contact sheets and serve them to users. You can encode them with VP9, mux to IVF format, and use the WebCodec API to decode them in the browser (2000B-3000B per 240x135 frame, so ~3MB/hour for a thumbnail every 4 seconds). Alternatively, you can make the contact sheets with JPEG, but there are dimension restrictions, reflow is slightly fiddly, and it doesn't exploit intra-frame compression.

I made a simple Python/Flask utility for lossless cutting that uses this to present a giant contact sheet to quickly select portions of a video to extract.

(Yep! https://cod.ifies.com/voxel-visibility/ )

(Off-topic AMA question: Did you see my voxel grid visibility post?)

You can more precisely track flows and do maximization with ILP, but that often loses conflict-driven clause learning advantages.

Note that traditional SAT and SMT solvers are quite inefficient at computing flood-fills.

The ASP specifications it uses to compute optimal solutions are surprisingly short and readable, and look like:

  #const budget=11.
  horse(4,4).
  cell(0,0).
  boundary(0,0).
  cell(0,1).
  boundary(0,1).
  % ...truncated for brevity...
  cell(3,1).
  water(3,1).
  % ...
  
  % Adjacent cells (4-way connectivity)
  adj(R,C, R+1,C) :- cell(R,C), cell(R+1,C).
  adj(R,C, R-1,C) :- cell(R,C), cell(R-1,C).
  adj(R,C, R,C+1) :- cell(R,C), cell(R,C+1).
  adj(R,C, R,C-1) :- cell(R,C), cell(R,C-1).
  
  % Walkable = not water
  walkable(R,C) :- cell(R,C), not water(R,C).
  
  % Choice: place wall on any walkable cell except horse and cherries
  { wall(R,C) } :- walkable(R,C), not horse(R,C), not cherry(R,C).
  
  % Budget constraint (native counting - no bit-blasting!)
  :- #count { R,C : wall(R,C) } > budget.
  
  % Reachability from horse (z = enclosed/reachable cells)
  z(R,C) :- horse(R,C).
  z(R2,C2) :- z(R1,C1), adj(R1,C1, R2,C2), walkable(R2,C2), not wall(  R2,C2).
  
  % Horse cannot reach boundary (would escape)
  :- z(R,C), boundary(R,C).
  
  % Maximize enclosed area (cherries worth +3 bonus = 4 total)
  #maximize { 4,R,C : z(R,C), cherry(R,C) ; 1,R,C : z(R,C), not cherry(  R,C) }.
  
  % Only output wall positions
  #show wall/2.

Here's the word on the internet streets:

- THE FIRST GROUP of individuals exploited a Rainbow 6 Siege service allowing them ban players, modify inventory, etc. These individuals did not touch user data (unsure if they even could). They gifted roughly $339,960,000,000,000 worth of in-game currency to players. Ubisoft will perform a roll back to undo the damages. They're probably annoyed. I cannot go into full details at this time how it was achieved.

- A SECOND GROUP of individuals, unrelated to the FIRST GROUP of individuals, exploited a MongoDB instance from Ubisoft, using MongoBleed, which allowed them (in some capacity) to pivot to an internal Git repository. They exfiltrated a large portion of Ubisoft's internal source code. They assert it is data from the 90's - present, including software development kits, multiplayer services, etc. I have medium to high confidence this true. I've confirmed this with multiple parties.

- A THIRD GROUP of individuals claim to have compromised Ubisoft and exfiltrated user data by exploiting MongoDB via MongoBleed. This group is trying to extort Ubisoft. They have a name for their extortion group and are active on Telegram. However, I have been unable to determine the validity of their claims.

- A FOURTH GROUP of individuals assert the SECOND group of individuals are LYING and state the SECOND GROUP has had access to the Ubisoft internal source code for awhile. However, they state the SECOND GROUP is trying to hide behind the FIRST GROUP to masquerade as them and give them a reason to leak the source code in totality. The FIRST GROUP and FOURTH GROUP is frustrated by this

Will the SECOND GROUP leak the source code? Is the SECOND GROUP telling the truth? Did the SECOND GROUP lie and have access to Ubisoft code this whole time? Was it MongoBleed? Will the FIRST GROUP get pinned for this? Who is this mysterious THIRD GROUP? Is this group related to any of the other groups?