I'm glad there's many teams with automated scans of pypi and npm running. It elevates the challenge of making a backdoor that can survive for any length of time.
That's a narrow fair use exception. Many of these open game engines are effectively 1:1 decompilations of the original games, and it would be shocking if they were not effectively copyrighted the same as the original.
I don't think this has been tested in court, but the recent flood of Nintendo game decompilations is likely to change that.
Pre BSD's (386BSD) where in the same case with AT&T Unix and after a few years of rewritting code under BSD licenses they were perfectly ok to ship, from NetBSD 0.9 to FreeBSD, OpenBSD was a NetBSD fork.
Current OpenTTD has no former TTD code since decades ago. I remember Solene@ from OpenBSD (now ex-user) playing OpenTTD for MacPPC (PowerPC G4) a few years ago as she had in issue with mouse input.
Microsoft released a video that covers effectively all of the Xbox One security system, and it's referred to extensively in the talk. The specific methods of glitching don't require any insider knowledge.
They also told everyone they added more anti glitching to later hardware revisions; which by the process of elimination tells everyone they thought this was possible.
The whole initiative was a success when it gave them a year; an unqualified triumph when it gave them the whole generation; they really are not going to be to sad after 12 years.
Right, as Markus says - even gods can bleed. And he's right: Tony Chen's team did god-level work with the Xbox One security system, so what must have followed in the Xbox Series S is truly unknowable. I don't think there's even a tech talk on it. This talk is probably the most elite hacking talk I've ever watched. Everyone who worked on this stuff at MS can and obviously should be very proud of what it took - especially as this probably won't have any commercial impact on Xbox game devs or multiplayers.
Many engineers get paid a lot of money to write low-complexity code gluing things together and tweaking features according to customer requirements.
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.
Complexity is not where the value to the business comes from. In fact, it's usually the opposite. Nobody wants to maintain slop, and whenever you dismiss simplicity you ignore all the heroic hard work done by those at the lower level of indirection. This is what politics looks like when it finally places its dirty hands on the tech industry, and it's probably been a long time coming.
As annoying as that is, we should celebrate a little that the people who understand all this most deeply are gaining real power now.
Yes, AI can write code (poorly), but the AI hype is now becoming pure hate against the people who sit in meetings quietly gathering their thoughts and distilling it down to the simple and almost poetic solutions nobody else but those who do the heads down work actually care about.
> A huge fraction of the software economy runs on CRUD and some business logic.
You vastly underestimate the meaning of CRUD applied in such a direct manner. You're right in some sense that "we have the technology", but we've had this technology for a very long time now. The business logic is pure gold. You dismiss this not realizing how many other thriving and well established industries operate doing simple things applied precisely.
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.
That's a false dilemma. If that's what you want, you absolutely can use the AI levers to get more time and less context switching, so you can focus more on the "simple and poetic solutions".
Hardware video decoding APIs often have significantly more latency than software decoders, to the point that it's a noticeable several hundred milliseconds of delay. If they have this delay, they're unusable for images.
You have that backwards. GFS was replaced by Colossus ca. 2010, and largely functions as blob storage with append-only semantics for modification. BigTable is a KV store, and the row size limits (256MB) make it unsuitable for blob storage. GCS is built on top of Spanner (metadata, small files) and Colossus (bulk data storage).
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!
Thank you, yes my knowledge was very outdated, waay before Spanner.
Spanner for GCS actually explains how public Google Cloud was always ACID for object listing, while S3 only implemented it around 2020. I always suspected that there must be some very hard piece to implement that AWS didn't have until 2020. Makes sense now that that piece was Spanner.
Most companies doing CGI work, both in games and movies, are quite open about their technical details. The whole industry relies on pooled research and development. While the actual code is typically confidential, publishing information serves multiple purposes for the work's publicity, the advancement of the field, the happiness of employees, and company prestige for recruiting people.
When LLMs predict the next token, they actually produce a distribution of the probability of each of the possible next tokens, and the sampler chooses one of them, and not necessarily the most likely one!
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.
Client-side frame extraction is far too slow to be usable for large volumes of data.
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.
Actually, I started with the precomputing approach you mentioned. But I realized that for many users, setting up a backend to process videos or managing pre-generated assets is a huge barrier.
I purposely pivoted to 100% client-side extraction to achieve zero server load and a one-line integration. While it has limits with massive data, the 'plug-and-play' nature is the core value of VAM-Seek. I'd rather give people a tool they can use in 5 seconds than a high-performance system that requires 5 minutes of server config.
reply