A problem of both the Altman post and posts that react on him is that they take efficiency/utility in absolute sense instead of in marginal sense.
There is clearly high marginal utility of the first n GB of RAM in your computer, but then its go down probably faster than for RAM in OpenAI's datacenter. And the market just solves for the equilibrium.
It is not for the same pay. Real wage increased dramatically during that time period. And despite all obsoleted jobs, society is still more or less at full employment.
This terminology change is mostly limited to anglosphere. Outside of that 'liberal' is still commonly used for economic-right low-intervention position.
Depends on country. Here in Czechia, Communist party is one of most socially conservative one, while conservative christian party is center-left economically. Social democratic party, when it was relevant, was also pretty socially conservative, which makes sense considering their working class demigraphics.
That would be true if there is only one receiver and if i could exactly predict how the receiver would interpret these 300 bits. But i could use LLM to expand these 300 bits to 1000 bits of more explicit information that gives enough redundancy and context that minimizes risk of misunderstanding and increase easiness of understanding, then validate such expanded message (and possibly do iterative corrections if LLM did not understand those 300 bits correctly), and finally release expanded message to (potentially large and heterogenous) group of receivers.
If there's a significant risk of misinterpretation when writing only 300 bits, then the idea you're trying to convey is worth more than 300 bits. In the process of prompting the LLM to add information, you're giving information to the LLM that you could instead just give to your readers directly. If you're just using an LLM to expand your thoughts in the hope that you get a better piece of writing, maybe you should put more effort into your own writing.
(This is all under an information model that assumes the LLM and your readers have equal access to knowledge, which I probably should have made more explicit in my original comment.)
Note that classical pixel art was not necessary particularly fat/blocky. Since SVGA become common, games like SimCity 2000 or Transport Tycoon Deluxe run in 640x480 on 14" CRT, which is ~60 DPI. Later (in second half of 1990s), higher resolution became common, but also higher screen sizes, so DPI was in 70-80 range. That is not really that different from full HD on 24" LCD (~92 DPI), which dominated later era.
Now I’m wondering what were some of the last generation of games to dominantly use fully hand-drawn pixel art. After 1995 or so, games using isometric art such as Red Alert (1996) and Fallout (1997) were more and more switching to sprites and environments rasterized from 3D models and hand-tweaked at most, as desktop 3D modeling became more affordable and SVGA resolutions meant less need to hand-fix aliasing artifacts.
I have no problem with that with XMPP. Conversations automatically reconnects after each switch within few seconds, so it is transparent for users. On IRC that is huge pain, true.
I use XMPP (with OMEMO) extensively and my main problem with it is absence of some basic key trust chains and bad handling of group chats
1) With OMEMO, each client/device of a user has its own key, but there is no trust relationship between them or some common master key. I can verify and trust counterparty key, but then counterparty adds another client/device and i have to do manual verification again.
2) Group chats do not have group key, but one encrypt messages for each group member (pairwise), which means that everybody has to do key exchange with everybody. This does not scale, especially with 1), which means that even if membership is stable, new keys may appear. Some clients (Conversations) do not allow to send message to a group when they do not know some keys of some group members/devices, which is fail situation that happen pretty often.
1) I think that's by design: you've got two ways to use OMEMO, the "friendly (default)-way" (with BTBV, Blind Trust Before Verification), and the "paranoid-way" (where you verify each and every device). In the latter, you don't want your messages to be encrypted for a new, unverified device (as it could potentially be that of an attacker): you can either verify the new device yourself, or your contact can verify theirs and you verify them again. Like I said, that's not for everyone. And if you are not that paranoid, then verification is an afterthought anyway and you don't lose or gain much with verification anyway.
2) That's where MLS¹ kicks in, essentially a new encryption scheme that's suitable for large group chats. There are projects² for its adoption in XMPP. I have no strong opinion about MLS, but I tend to think that it's more for the gimmick and having XMPP score well in random protocol benchmarks: if you've got such a large groupchat that OMEMO doesn't scale anymore, you have a groupchat with so many participants that it is only private in name and more or less encryption doesn't matter.
I've tried designing an E2EE group chat system before and ran into all of these. They're not impossible to solve but are very hard. Telegram's official docs shrug off multi-device E2EE too, calling it a "mess."
reply