Some professional printers do have their spools in cartridges, and refuse to work without them...

5 axis printers using non-planar slicing are becoming more common in pro use, they allow you to print things without supports which would have required supports.

systemd might make sense for ephemeral VMs. That doesn't justify it for long-running servers or desktops.

Every silly error I see in automatic captions today is on Youtube and was created by an LLM. Why didn't it catch them?

I didn't find them to be so. The primary advantage claimed was that it eliminated init scripts. But init scripts are really easy on modern Linux because of the boilerplate, and there are still cases where you need scripts with systemd, so it didn't actually eliminate them — It only reduced their number. The other advantage claimed was that it implemented cgroups. Well, I'm using Devuan and that uses cgroups too, they are created and managed and destroyed with simple commands and you do not need any special tools for that at all.

systemd solves a non-problem, since scripts are a core OS feature.

Closed environments and simulations. Simulations are better in particular because you can create test situations trivially, so you can test on e.g. a thousand variations of the same onramp. You can't really build the vision models in simulation, but that's OK, because you can build them by logging data from cars where the computer isn't controlling anything and therefore isn't endangering anyone.

This isn't new, though, this is obvious. You just want to move fast and break things.

Weren't you here when we discussed this when Debian adopted systemd? The change was rammed through without the normal discussion procedure, specifically for the purpose of supporting GNOME at a time when nobody gave a fuck about it any more. The idea that they have to have had a good reason because they did it is not logic-based.

Me too!

The real problem with C is that it doesn't have any built-in support for strings. Everyone is forced to fake it with char-arrays, which aren't quite the same thing and require very careful handling. The problem with that is, everyone has their off days, and so everyone who does string-handling in C eventually ends up shipping string-related bugs that introduce security problems.

You also have to give them achievable parameters. "You are always responsible" is not realistic. In some cases someone else is, in fact, responsible. And that's the rub of regulation, not that I think this means we shouldn't regulate, but it's going to always be true that doing it well takes effort. You can only ever reasonably expect that people are moving forwards (at best) and doing what is reasonably and humanly possible, and hopefully advancing the state of the art. Determining whether or not they are doing that is inherently complex.

The United States started restricting export of computers in 1949. When the G4 exceeded the performance limit to be classified as a mulition in 1999 Apple ran ads about it: https://www.youtube.com/watch?...

"Advanced computations required for frontier AI" sounds better than "adds and multiplies faster than our arbitrary limit" and way less stupid than "now that this is a munition we have discontinued the translucent blueberry and frost white color option in favour of a more professional 'graphite' color scheme. Mirrored drive doors will be an option in the future."

The same cold war ideas as ever.

1. Find or make a boogey man enemy to scare the population
2. Profit

Yes, OceanGate tried to wiggle out of safety regulations at every opportunity. Transportation regulators are very familiar with maneuvers like that. OceanGate accepted money for services. In fact, the whole company was set up to do just that. You can call your customers blueberry pancakes if you want, but it doesn't matter.

That's why you can't, for example, take your buddies flying with your private pilots license and let them pay for gas, or make a profit from taking your friends out on your boat.

Why would you do that? If you're using it for non-strings, you'd never have used strncpy, you'd have used memcpy. Which is the same thing without the null termination rules of strncpy. You'd never use the str versions unless actually working on strings.

It has seemed to me, for a very long time, that modern AI systems would need to be integrated with standard RDBMS systems for reliable persistant storage of raw information, some sort of no-sql database (memcache or some variant) for persistant storage of associations, some sort of document database for blocks of textual information, a SPARQL system for searching semantically-marked information within the document database, and a more old-fashioned back-propogation NN to provide a store of understanding that the user can directly manipulate.

Probabalistic classifiers are all fine and good, but only for a subset of the tasks needed. The above structure is a very loose, wildly-speculative initial framework. It's almost certain that if you actually tried building an integrated multi-model system, that you'd end up making a lot of changes to this basic idea, but that you'd end up having to implement the same core concepts that are identified in it.