This isn't strictly better to me. It captures some intuitions about how a neural network ends up encoding its inputs over time in a 'lossy' way (doesn't store previous input states in an explicit form). Maybe saying 'probabilistic compression/decompression' makes it a bit more accurate? I do not really think it connects to your 'synthesize' claim at the very end to call it compression/decompression, but I am curious if you had a specific reason to use the term.
The act of compression builds up behaviors/concepts of greater and greater abstraction. Another way you could think about it is that the model learns to extract commonality, hence the compression. What this means is because it is learning higher level abstractions AND the relationships between these higher level abstractions, it can ABSOLUTELY learn to infer or apply things way outside their training distribution.
ya, exactly... i'd also say that when you compress large amounts of content into weights and then decompress via a novel prompt, you're also forcing interpolation between learned abstractions that may never have cooccurred in training.
that interpolation is where synthesis happens. whether it is coherent or not depends.
I mean, actually not a bad metaphor, but it does depend on the software you are running as to how much of a 'search' you could say the CPU is doing among its transistor states. If you are running an LLM then the metaphor seems very apt indeed.
It's 'wild' to this person because it challenges their opinion on Musk and Tesla I have to guess. This is a classic 'it is bad reporting because it does not agree with my worldview' take, aka 'fake news'.
That type check is honestly not pointless at all. You can never be certain of your inputs in a web app. The likelihood of that parameter being something other than an arraybuffer is non-zero, and you generally want to have code coverage for that kind of undefined behavior. TypeScript doesn't complain without a reason.
Not only that but they get to use an individual who they have philosophical differences with. You can say it was 'good security practice', tarnish his reputation, and get to switch the narrative to something sympathetic to yourself all in one go. Very convenient for them.
I think they make a lot of overly strong claims here, even though there are plenty of alternative explanations possible. The mere fact that 3 people had AWS root access during this period but they only identify one and never question that it could have been one of the others is telling. They reallllly want you to just take it as obvious that 1) all these actions were taken by 1 individual and 2) that individual was malicious. Then they sprinkle in enough nasty sounding activities and info about Andre to get you to draw the conclusion that he is bad, and did bad things, and they had to do these things the way they did.
Using what reads like a business strategy email as a 'nefarious backstory' is so bad faith. I bet if you got access to all the board's emails you would see a ton of proposals for ways to support RubyGems that may not all sound great in isolation. They are being just transparent enough to bad mouth Andre while hiding any motivations from their end as purely 'security' related.
-> In my opinion they are now deliberately making the community angry.
This is one thing I think hasn't been talked about explicitly enough within the community (that I see at least) yet, Ruby Central seems to be actively trolling the 'other side' of this situation. It reads to me like they know they have the lawyer power to defend their castle and are enjoying pissing down on people and telling them it's raining. Oh and you should enjoy that because it means there will be flowers soon... or something.
I think the dialogue of 'are they acting in good faith' only works in so far as they even care about the rest of the Ruby community at all. If they are indeed bad actors (motivated purely by greed, ambition, ego, etc) then they are not ever going to come clean and they would let the whole Ruby community die before they admit defeat or wrongheadedness. My favorite term for these types of actors is SCUM - Sufficiently Clever and Uncaring Malefactors.
Sadly mine does :\ Not that I don't support trying to get it approved, but anyone in a large enough corporation knows that approval for an external source often takes... a very a long time lol
Churn is not just rate of commits it is the changing of the same lines/files/functions repeatedly, AI answers seem to get this wrong a few places I checked which is interesting. Rate of change in itself is not 'instability', it can be a sign of new ideas emerging or lot of other positive things.
Package management cannot be a 'solved problem' or there would be no innovation there, and you don't have to look far to find is not the case.
As for the idea that rubygems is 'dead' (not what mperham said), that is still too early to say for sure, as I imagine mperham would also agree, but it is definitely not a good sign. If we only get a trickle of changes to something that was once a very vibrant and lively community repo then that is to the detriment of the whole Ruby ecosystem. That would also be a bad sign.
