rdw

I spoke with an Anthropic employee, and came to understand that their definition of safety is more like "making AI be a tool that humans can use without hurting themselves or others more than they can already do". It's literally about how AI makes it easier for people to construct bombs, poisons, manipulation, and exploits. Consistent with their caution about releasing Mythos to unvetted actors. So it's not about superintelligence killing humanity, at least as far as this employee conveyed to me.

This means their strategy is more like:

1. If someone builds a market-leading unsafe strong AI, it may be misused in a damaging way by a large number of humans, undermining society and creating a catastrophic upheaval.

2. However, if the leading AI maker also works to make it safe against misuse, as long as the stay in the lead and keep it safe, then the ability of human bad actors to misuse the AI is limited. Given enough time, society will adapt to pretty much anything, so eventually there's no longer an arms race to stay ahead.

I don't really know whether I agree with their concerns, but I do think that (my understanding of) their principles is that they're reasonable, self-consistent, and they adhere to them in all their public and private actions.

Once you write enough code, you'll realize you need synchronization primitives for async code as well. In pretty much the same cases as threaded code.

You can't always choose to write straight code. What you're trying to do may require IO, and then that introduces concurrency, and the need for mutual exclusion or notification.

Examples: If there's a read-through cache, the cache needs some sort of lock inside of it. An async webserver might have a message queue.

The converse is also true. I've been writing some multithreaded code recently, and I don't want to or need to deal with mutexes, so, I use other patterns instead, like thread locals.

Now, for sure the async equivalents look and behave a lot better than the threaded ones. The Promise static methods (any, all, race, etc) are particularly useful. But, you could implement that for threads. I believe that this convenience difference is more due to modernity, of the threading model being, what 40, 50, 60 years old, and given a clean-ish slate to build a new model, modern language designers did better.

But it raises the idea: if we rethought OS-level preemptible concurrency today (don't call it threads!), could we modernize it and do better even than async?

In the area I live, houses are often built one complete room at a time, over many years. They start out as a single-room shack, then the owner builds extensions as they have children or money. Often, they build a porch, and then decades later wall up the porch and turn it into a room of some kind.

I kind of like this analogy because it does help us reason about the situation. The one-room shack is basically an MVP; a hacky result that just does one thing and probably poorly, but it is useful enough to justify its own existence. The giant mansion built from detailed architectural plans seems like a waterfall process for an enterprise application, doesn't it?

There are many advantages to building a house one room at a time. You get something to house you quickly and cheaply. When you build each extension, you have a very good idea of how it will be most useful because you know your needs well. You are more capable of taking advantage of sales (my neighbor collects construction overstock for free/cheap and starts building something once he has enough quantity to do so). It's more "agile". The resulting houses are beautiful in their own bespoke ways. They last a long time, too.

The downsides are that the services and structure are a hodgepodge of eras and necessity. If you're competent, you can avoid problems in your own work, but you may have to build on shoddy "legacy" work. You spend more of your time in a state of construction, and it may be infeasible to undertake a whole-house project like running ethernet to every room.

It's all tradeoffs. I think it does in many cases make sense to build a house in this way, and it likewise makes sense to build software this way. It depends on the situation.

"We should do something to preserve leading-edge chip manufacturing in the US. This is Something, therefore we should do it."

The bitter lesson is becoming misunderstood as the world moves on. Unstated yet core to it is that AI researchers were historically attempting to build an understanding of human intelligence. They intended to, piece-by-piece, assemble a human brain and thus be able to explain (and fix) our own biological ones. Much like can be done with physical simulations of knee joints. Of course, you can also use that knowledge to create useful thinking machines, because you understand it well enough to be able to control it. Much like how we have many robotic joints.

So, the bitter lesson is based on a disappointment that you're building intelligence without understanding why it works.

Thanks, Max! I've personally never been able to wrap my head around BSP; I appreciate your diagrams explaining everything, and I am optimistic about the new engine. It's crazy how much faster it can be; really drives home how much extra stuff Unreal is doing that your game may not need.

Article is from 2021, but the game launched today.

It's a very risky industry. It's quite likely to sink a ton of money into a game and earn very little back, basically wasting everything. Game series that consistently make revenue are even rarer so they're extremely coddled while they last, though it is expected that eventually they will die, too. The rare successes cover the costs of the common failures.

It's a lot like the VR hype cycle of the past 5 years. Maybe there will be more of an actual change from the AI stuff, though.

I used to believe this and then I got into the area. It depends on the area of course but it turns out that the cost of the house is quite significant. House construction costs are $200-500 per square foot, putting even a medium-sized house at around a quarter of a million dollars. When you look at the costs of empty plots of land versus similar plots of land with houses on them, you'll see that the housed plots of land cost the same as the empty plots plus the construction costs of a similar-sized house. In the areas where I looked, the costs of the house dominated, such that the land value is about 20% of the total value of the plot. Even the variance that occurs at that level can be further explained by the value of potential future plots of land on the space -- a plot of land that has one house but could hold a second (for whatever reason) is more valuable than an otherwise-identical plot that can only support one house.

It has more to do with how game engines are built, making embeddability be the most important criteria.

Most game engines are written as a large chunk of C++ code that runs each frame's timing, and the big subsystems like physics, particles, sound, and the scenegraph. All the important engineers will be dedicated to working on this engine and it behaves like a framework. The "game logic" is generally considered to be a minority of the code, and because less-technical people generally author it, it gets written in a higher-level "scripting" language.

This creates some serious constraints on that language. It must be possible to call into the scripts from the main engine and the overhead must be low. The scripts often have to make calls into the data structures of the main engine (e.g. for physics queries) and the overhead of that should be low as well. It should also be possible to control the scripting language's GC because the main engine is pretty timing-sensitive. Memory consumption is pretty important as well.

All these requirements point towards two implementations specifically: Lua (and LuaJIT), and Mono. Those two runtimes go out of their way to make it easy and fast to embed. A third option which a lot of engines pick is to write their own scripting language where they control everything about it. Any other language you can think of (with the possible exceptions of Haxe) will have some major hurdle that prevents easy embedding. The fact that you can compile multiple languages to Mono bytecode pushes some folks in that direction; if you're planning to write a lot of code in the scripting engine (not all of them do! See: Unreal) that's nice flexibility to have.

You're right, and it's got more layers than that. C# does have value types, which are not boxed, and using them judiciously can avoid garbage. However, they are a more recent addition to the language (which started as a lame Java clone), and so the standard library tends to not know about them. Really trivial operations will allocate hundreds of bytes of garbage for no good reason. Example: iterating over a Dictionary. Or, IIRC, getting the current time. They've been cleaning up these functions to not create garbage over tiem, of course, but it's never fast enough for my taste and leads to some truly awful workarounds.

I had one, and I wrote a lot of code on it. There was pretty much nothing else on the market that could do web browsing in that portable of a form factor, and at that price point. Steve was somewhat right to worry about them -- in an alternate history they would have taken over as the dominant form of computing, creating a whole evolutionary tree of tiny laptops, converged with keyboarded mobile phones, at all price points and build qualities.

The 11" Air I got to replace the Eee was much better in every single way. One note is that the thin-and-long of the Air was much more portable than the chunky but stubbier Eee. It just fits better into the kinds of bags we all have. The thinness wars started then.

Yes, I've heard this said many times about sales people. If they're not visibly wasting money, people are reluctant to hire them because they either aren't good (and thus have no money to waste), or won't be hungry (because they've saved the money they earned by not wasting it). So conspicuous consumption becomes a way to signal that the sales person is capable of reliably generating large incomes.

It's fun to be back in the age where every few years you want to upgrade your computer because the new ones are so much faster, not because the old one is worn out.

20% faster isn't enough to make me regret my M1 purchase, but after one or two more 20% speed gains I'll feel like upgrading to the latest is going to be worth it.

The practice of using political party affiliation as a criteria at all for drawing district borders inevitably leads to gerrymandering. This part of the article does seem apparent, which is why the solution, to _not_ do that, seems mysterious in its absence.

This is written in such a way that it seems like it makes sense, but it ultimately takes its conclusion as an axiom and is thus essentially meaningless.

Gerrymandering is to draw districts according to political party affiliations. So of course if you only divide up your districts by political party affiliation (in rather extreme ways) you will discover that doing so doesn't lead to stable political systems. No shit, that's the problem with gerrymandering.

Any serious analysis of this problem needs to confront the realities of geographical location and migration.

Can someone explain to me how any schools are in danger of going out of business? Their expenses aren't going up, they're not paying professors more, they're not leveraging themselves into debt. What are the huge cost increases they're bearing that force them to raise tuition? The one institute I'm familiar with appears to have hired an absolute shitload of useless administrators, but that is an expense of choice that could be trimmed at any time.

> Code that runs slow over pathological input is nowhere near as dangerous as code that goes into an infinite loop over pathological input.

In my experience, these are not actually that different. Even in straightforward web development on smallish data sets, it's pretty easy to write something that runs "fast on my machine" but is so slow on production-sized data that it is effectively infinite.

Presumably related to this: https://www.roryctait.com/post/why-did-shaq-just-add-eth-to-...

Oooh, I have one. It is really amazing, in that there's really a usable display in a package the size of one's finger.

I've struggled to use it for anything practical, though, because of small issues with the mounting. It isn't quite adjustable enough so it's slightly out of focus. It's a too heavy so it's tilting the glasses and making them fall off if I tilt my head forward. The micro-HDMI cable interferes if I rest my head on anything. So I pretty much have to use it sitting or standing in free space, in which case, why not use a regular monitor?

I wonder if Thunderbolt makes it possible to take another crack at this design without the battery, hugely reducing the weight.

Don't give up on the industry. I believe that HP is actually seeding the idea that no printer is better, because I've heard several people resignedly tell me that they're getting an HP because "they're terrible, but every printer is terrible and at least I recognize the brand". Some sort of endgame of marketing perhaps. But reliable and good printers are indeed available to purchase, as long as you can find them. I can recommend the Brother HL-2270DW I purchased nearly a decade ago which is still completely trouble-free (And prints duplex in a small footprint! Delightful.)

Making printers is not trivial. Paper is not as simple as it seems. It's super thin and light which is difficult for machines to handle at speed, and it also comes stacked in a near-solid block from which pieces need to be separated delicately but firmly. The materials science behind the rubber to grip with just the right amount of friction, time after time, accounting for wear and dirt, is mind-boggling. Paper is also noticeably affected by temperature and humidity, both of which change its properties nearly by the minute. This changing nature affects feeding, making the pieces floppier at times and liable to miss the handoff to the next set of rollers, or clingy at others and adhering to a plastic guide for longer than expected. Also the electrostatic properties vary which affects how much charge the drum needs to put on each piece to ensure the correct amount of toner particles adhere -- too much and you get squished smears, too little and the text is faint. And let's not forget the fixing process, which heats the paper to bake the toner into the crevices of the page, which may take twice as long due to extra moisture, but you wouldn't want to burn things if someone is sending through some extra thin paper for some reason. And of course as it's printing the printer is changing all of these variables with its heat and motion, changing the dimensions of every space in its interior. Every printer contains many environmental sensors so they can detect these changes and tweak their control mechanisms for each individual piece of paper. It's kind of akin to baking a perfect baguette every time.

Printers are miniature marvels, and there are still some wizards out there who know how to make them well. But we have to, like, patronize those wizards instead of the goblins of HP or else we will truly be buying our own way into the dismal future of crap that HP creates.

Google spends most of their time blocking ads. "Spam" is ads.

Alphabet isn't quite the same thing, though. They kept the Google name around, and created Alphabet as a kind of holding company. This way they retained the value of their brand while also getting to have a kooky company with a fun name.

> Incidentally I didn't really win much

I've heard it said that the casinos encourage bad card counters, because someone who has a "system" that doesn't really work for them is going to lose even _more_ money playing. It's only when you start really winning that they care. The fact that you were obvious about it just made it easier for them to identify you once you won anything significant.

It's still true that UDP is necessary for realtime communication. I recently worked on an MMO project in which a sub-team attempted to use TCP as the main layer, but ran into huge issues, all of which were cured by switching to UDP. TCP is good at what it's good at, but nearly every realtime audio and video protocol is gonna keep using UDP. You have to be able to ignore dropped packets instead of blocking the entire channel waiting for a full RTT, it very quickly spirals out of control.

Of course, TCP is a much better protocol for infrequent and request/response type interactions, so while I was at Linden we converted as much traffic as possible to TCP/XML. But a lot of the "realtime" stuff like object updates had to remain UDP, for empirical reasons.

Second Life didn't reimplement fragmentation -- messages just got truncated if they went over the MTU, lol.

It was basically "throwaway code" which was written in a hurry for a prototype that was not expected to have a long life. This kind of parsing was (is?) very common in the video game industry, and quite easy to author in C++, so it would have been the first tool the developers reached for to implement a real-time network protocol.

The evolution was hardcoded -> message template -> "Liberación" which allows the protocol to tolerate unknown fields, and thus be future-compatible, much like Protobuf does.

Source: worked on the Liberación project.

Minor correction: it's actually nearly a 2% chance of dying (1.7%), after Delta became the dominant variant. Folks never really upgraded their talking points but subjectively 2% feels _much_ higher than 1%.

This post sounds like wisdom, but after looking at it hard, it seems that the point is no more than "peer review processes are popular". Not to say that code review is bad in any way (I do it at my current role), but, this argument for them is not very good.

One downside of code review is reduced velocity. There are teams out there who use code review so effectively that they never ship big fuck-ups to production. They never have to tell clients that they have bad practices. Instead, they struggle to get clients because they pay much more per line of code shipped and therefore don't deliver as good of a value as their competitors.

This where the argument needs to be: whether and how to have code reviews be a net positive.

It repeatedly asserts that immunocompromised patients cannot have antibodies ("weirdness" 3 & 4), but, immunocompromization is a spectrum. Many people can produce antibodies but not as many as normal.

If the piece hinges on getting this pretty basic element wrong, how wrong is it about some of the more sophisticated analyses?