syntheweave

That's actually a problem for the business model of mobile games. A consumer can - or very soon will be able to - pick up AI tools and cut out the middleman org churning out these illustrations, just like they cut out the professionals. It won't be too long before games are made that advertise "put your original characters in the game", and it won't be some complicated character creation tool - it'll be generative stuff.

There's a lot of "but wait, there's more" in what's happening around AI.

Bugs related to concurrency - which is where you get race conditions and deadlocks - tend to pop up wherever there's an implied sequence of dependencies to complete the computation, and the sequence is determined dynamically by an algorithm.

For example, if I have a video game where there's collision against the walls, I can understand this as potentially colliding against "multiple things simultaneously", since I'm likely to describe the scene as a composite of bounding boxes, polygons, etc.

But to get an answer for what to do in response when I contact a wall, I have to come up with an algorithm that tests all the relevant shapes or volumes.

The concurrency bug that appears when doing this in a naive way is that I test one, give an answer to that, then modify the answer when testing the others. That can lead to losing information and "popping through" a wall. And the direction in which I pop through depends on which one is tested first.

The conventional gamedev solution to that is to define down the solution set so that it no longer matters which order I test the walls in: with axis aligned boxes, I can say "move only the X axis first, then move only the Y axis". Now there is a fixed order, and a built-in bias to favor one or the other axis. But this is enough for the gameplay of your average platforming game.

The generalization on that is to describe it as a constraint optimization problem: there are some number of potential solutions, and they can be ranked relative to the "unimpeded movement" heuristic, which is usually desirable when clipping around walls. That solution set is then filtered down through the collision tests, and the top ranked one becomes the answer for that timestep.

Problems of this nature come up with resource allocation, scheduling, etc. Some kind of coordinating mechanism is needed, and OS kernels tend to shoulder a lot of the burden for this.

It's different from real-time in that real-time is a specification of what kind of performance constraint you are solving for, vs allowing any kind of performance outcome that returns acceptable concurrent answers.

The last time I tested it, it wasn't performing differently from other DVCS options when pushing large files - that is, Perforce would still win hands-down. It does have a binary diff flag, but it's probably limited on a more fundamental level by being a SQLite app under the hood.

It's a combination of things. The "Pullman Loaf" (as in Pullman railcars) became common for sandwich breads in the 19th century and established a common target for what bread should look like in the US and UK - white, sweet, fluffy, thin crust.

Later, we were successfully marketed "Wonder Bread" as a clean(as in sanitary) and convenient product, and that set another standard, one sold to housewives. It was basically applying the same strategy that built McDonald's in its early years. At the time of Wonder Bread's introduction, many adults could still recall when products were being sold "from the cracker barrel", mixed homogenously and exposed to pests. All the early packaged foods, including the canned stuff and the sliced bread, were establishing a new norm of the manufacturer guaranteeing freshness to a sell-by date. It was PB&J on sliced bread for lunch and macaroni and cheese for dinner that got a lot of the US through the Depression years.

Continental Europe was simply less interested in this genre of bread - they had competition from other varieties of grain, and different kinds of bread dishes.

Well, then just have the class communicate with the chatbot in study groups, taking turns to type, if "social" is what you're after. The way class time is currently used reflects the need to keep that grade level engaged with appropriate activities, and only as you get to the older ages does it converge on that kind of solo self-study. But it has to, eventually. You don't do research without figuring out how to do it. The flaws in leaning on LLMs are just another form of "precision vs accuracy" - GPT is always precise and not always accurate, just in the verbal domain instead of the numeric one. But we do have many tools like that in the numeric domain. The limitations can be learned.

If the LLM gives a solid three-star "fast food" education, that is actually considerably better than letting it all fall on the shoulders of the babysitters that currently serve in many classrooms.

I can vouch for Krita and Inkscape pairing well as vector art programs and even doing things that CSP, whose vector layers are pretty well liked, can't match. The issue is that drawing in Inkscape is a little bit broken(it can be done, but the current UX is death by papercut) - thus I approach it through the other program, which is basic but consistent.

So the workflow I end up using for digital inks is: Open both programs, sketch in Krita, copy-paste the vector data into Inkscape, stroke->path, then use tweak tool to sculpt the lines. This adds line weight in seconds-to-minutes. Alternately, I can apply path effects instead of stroke->path, if I want a more programmatic design. If I want to paint, I can copy-paste the shape back into Krita.

Inkscape has a lot to work on as a "content creation" app, while in terms of being true to SVG, it's done a lot of things the way you'd expect.

And I think that's most of the disconnect in the UI, which the devs have gradually gotten over by adding shadow XML data in the SVG to support Inkscape features while always presenting a rendered result.

Still, the drawing tools aren't consistent about the units they use yet. There is a lot of stuff there, and some of it is just papercuts.

I believe, having recently installed Python libraries on it, that Debian stable has the best handle on what to do to produce defaults that a mere mortal can debug: Either use what's vendored in apt, or use venv and pip for your project's additional dependencies. Pip has been configured to be venv-only, which is good for the needs of Debian's maintainers, and clarifies what your project has to be responsible for. So, while I haven't needed it yet, I have some confidence that I can get to a reproducible dev environment with the appropriate version of whatever's needed, even if the resolution process is imperfectly automated.

You could definitely argue that it would be better to build off of something like Contiki, a modern small-device OS that gained a lot of fame for its ports to old microcomputers, but is currently active in industry as well, with a new "Contiki-NG" version.

The appeal of Forth is mostly in a principled sense of, if you want Forth to be your interface, you have to build your own Forth, because Forth does as little as possible to structure you. And building your own Forth is not impractical; that's the whole point. It's wonderful as an exercise and can be productive in the right context.

But any highly developed or standardized Forth system gradually converges on being "just another platform." And once it's just another platform, it's an annoying dependency, and you end up demanding more structure for it to help tame the complexity, so the Forthiness habitually erodes.

The article is making the case for unbundling the authoring experience by bundling the browser and making it an owned environment. And that could be a win.

Library environments are often better workspaces, especially study carrels at university libraries. (Stick to public universities if you don't want to be kicked out.) Cafes have more of a bustle to them that isn't good for extended "deep work" sessions.

But this article happened back in 2009, too. I remember it. I may have been part of the problem. It's a signal of an economy that is displacing and reallocating workspaces.

It's surprising by importance but not by size, which is actually a sweet spot for evaluating a new systems language - a small dependency that everything uses.

It's definitely something coming from the top down. I'll watch Peter Zeihan's Youtube because he tends to make arguments that the incumbent elites want to hear, and he did an anti-EV one yesterday in which he argued that the logistics were impossible and EVs could not be green.

But the only worthwhile analysis is basically "too bad, disruption is happening". Total car/truck sales went into a steep dive in 2020, made a marginal recovery the next year, and then declined again in 2022. The back-to-office coercion only had partial success - commercial real estate is still sinking in many markets. Meanwhile, e-bike sales got red-hot and everyone suddenly discovered Youtube urbanism. California governor Gavin Newsom made a trip to visit BYD recently, and their buses are being trialed in a few cities. You can even pin a lot of the global instability on energy changes - Russia was a big oil/gas exporter, and they seem to have driven everyone away from them at this point.

The thing that creates the specific downward pressure in the US is also the thing that makes it very GDP-productive. When business raises their voice, they get to call the shots and define society in a way that creates economic rent: so, car dependency, approaches to childcare, approaches to healthcare, and so on. A lot of money from these businesses is "on the books" and easy to assess for taxation and investment purposes, and the government tends to be satisfied with this arrangement since it makes easy to know who's in charge. Meanwhile, everyone suffers from having sprawled cities with expensive homes, oversized trucks, bad healthcare, etc. All of that results in an expensive childcare number.

But this structure is also rather unrelated to the real productivity of the economy - the creatively destructive portion of American business always has something to say about it. If those companies want their labor to be cheaper and less frequently disrupted, they have to go cause grief for one of these rentier businesses, socialize some things and cut into some monopoly inaction or low standards. But they only reach that conclusion by letting the economy get into a highly unstable position first.

I think one thing that could be said of "Lost Generation" systems is that they primarily reflect memory size, not other aspects of performance. The graphics on 400/800/5200 could be described, in rough terms, as the 2600 plus a lot of framebuffer RAM and generalizations on the rasterization to move it out of software kernels and allow different allocations of video memory for the application. If RAM had been cheaper when the 2600 was designed, the architectures would be more similar than different. You can also see this in modern Intellivision homebrew: while the graphical I/O is limited, the CPU on it is a Motorola 68000 and can easily throw around whatever processing is needed for any 80's game experience. Like Atari, Mattel dropped the ball, experienced corporate paralysis, and didn't go forward with a planned upgrade to the Intellivision platform(Intellivision IV), which would have been a very high-spec third generation machine.

And this theme of memory basically holds true through the end of the "Fourth" Generation: games on console were assumed to be memory-starved, and advancements within those generations occurred through larger ROM enabling larger and more animated sprites, more graphically distinct "worlds," full soundtracks and scripted cutscenes. In 1988, the year of the great DRAM shortage, more of the games released used smaller ROM space, and it caused a notable regression back to technically simpler productions.

When you get to the Playstation/Saturn/N64 the approaches diverge quite a bit because the bottlenecks shift according to which platform you talk about. Memory is still a major consideration, but data streaming can be either relatively easy(N64) or a considerable engineering problem(everyone else), while the inverse is the case with data storage capacity. It's easier to discuss specific platforms as stable entities from that era onwards, since there's a cleaner separation of computing resources from game content.