Actually... the electoral college (and number of representatives in the house) is based on census, and the census is based on all residents, US citizens and otherwise.

https://govfacts.org/elections...

"A 2020 analysis by the Pew Research Center, based on population projections, estimated that if undocumented immigrants were excluded from the 2020 apportionment count, three states would each lose a congressional seat they were otherwise expected to have.

California would have lost two seats instead of one, while Florida and Texas would have seen their gains reduced by one seat each. Conversely, three other statesâ"Alabama, Minnesota, and Ohioâ"would each have held on to a seat they were otherwise projected to lose.

A similar analysis by the Congressional Research Service (CRS), using 2013 population estimates, projected that a citizen-only count would cause a shift of seven seats among 11 states.

Under this scenario, California would lose four seats, while Texas, Florida, and New York would each lose one. These losses would be offset by single-seat gains for Louisiana, Missouri, Montana, North Carolina, Ohio, Oklahoma, and Virginia."

So states with large numbers of non-voting residents (as in non-citizens) can give the voting residents (as in the citizens) of those states, outsized power when voting (assuming everyone turns out to vote - which is a different issue.)

Not quite the illegal voter / replacement theory that right wing meme artists want to push, but it can impact the census, and thus, every ten years, the way that seats and electoral college votes are distributed.

From this perspective, if Trump wants to depopulate House seats and electoral college votes in blue states, it is absolutely to his advantage to drive people out of those states and into red ones. Next best thing after that is to keep people from migrating into blue states to begin with.

Consumers won't be able to afford it.

Governments and businesses will likely sign long term contracts with service organizations, if the past is any indication.

We'll all be interacting with these systems in one way or another. Possibly not directly, but at one or two levels removed. The technology keeps changing so I can be confident that what we think of as the primary methods of using these systems is probably not what will be the dominant form in a few years.

Would you give a human assistant the login and password to your inbox? Or would you set up a shadow inbox that mirrors your actual inbox so that you don't need to share your login and password?

In a similar vein, when testing automation code, do you just give it admin level prod credentials and then YOLO it, or do you create a test environment that shadows the data from prod, so that you have a way to validate what the automation code is doing without accidentally damaging prod?

Fundamental rules people! Least privileged access to do the work needed. Safeguards commensurate with the negative consequences of failures. In other words... basic risk management.

To give a slightly different example, would you let your self-installed, open source AI self driving interface (see comma.ai) drive you on the highway without sitting in the driver's seat with hands on the wheel, feet on the pedals, just because it managed to complete a test course with flying colors?

The example given with regards to the openclaw agent is like sitting in the back seat of that self driving car, then desperately trying to climb into the front seat when you realize the AI driver is about to drive you off a pier into the ocean.

There are three problems when dealing with legacy code.

1. Figuring out what the code does.
2. Figuring out what the code was supposed to do.
3. Figuring out what the code actually should be doing.

The three are often not the same. The code lies. The comments lie. The commit messages lie. The documentation lies. The managers lie. The users lie.

By lie, I mean, what they tell you, regardless of what they believe to be the truth, is not reality.

For example:

Someone took a stab at writing some code in a modular fashion, or someone before you refactored it. There's a function - it says getXYZ, and it returns a value. Great! Then you dig deeper and discover that getXYZ sets several flags which are then used by the calls that come after getXYZ in the block you are looking at. You discover this only after shit starts breaking because you reordered several function calls during refactoring, none of which had the singular result of getXYZ as a dependency.

An even more straightforward example of that would be discovering a bunch of shit broke when you looked at and found that nobody used the result of getXYZ, and refactored out what looked like dead code. Again, because getXYZ, despite the pattern, actually had side effects.

At this point, now you have a problem. Is getXYZ actually supped to return a result that someone is supposed to use? Was that its original utility, and someone just jammed shit into it because it was faster than refactoring it into something else? Or was it even worse, and this was an incomplete refactor?

Nobody knows! Nobody can tell you! The commit history doesn't go back that far, and even if it did, nobody actually leaves coherent, useful commit messages!

And don't get me started on documentation and comments. Sometimes they can tell you how the system was supposed to behave at one point... but that's not how the system behaves now, and it isn't how all the users and managers believe the system is supposed to work because they've been using the current system for so long.

"Fixing" the code to follow what was supposed to be the correct design can cause all sorts of problems with downstream processes that rely on the current broken behavior. I'm going to steal Uncle Bob's example of finally fixing a typo in a dropdown menu and causing a bunch of UI macro code that looked for that typo to fail...

Often times modernization means essentially re-negotiating all the contracts and interfaces and process workflow with all the stakeholders to come up with a common understanding of what the code should be doing. That's like the best case scenario.

The worst case scenario is they say - use the old code for requirements, make it work exactly like that. Well, if the old code is shitty and illogical, and you need the new code to interface 1:1 with everything that plugged into that... well, guess what? You're going to get an architecture that is going to replicate shitty and illogical 1:1. The actual code might be great, but the process will be just as hard to understand, and probably eventually just as head scratchingly difficult to modify and maintain.

I wish our robot overlords the best of luck with this problem.

Thesis 1:

Cybersecurity companies are bloated and had a stock valuation premium created by insurance mandate (thou shalt contract with a cybersecurity company to keep your insurance premiums low) that will be going away.

Thesis 2:

People are freaking out, without basis, that #1 is true, when in fact the opposite is true - even with AI making code more secure, you will still need cybersecurity insurance, and the insurer is still going to mandate that you contract with an existing cybersecurity company in order to keep your premiums low, due to reinsurance rules. In fact, because of dumbshits using vibecoding, AND the use of automated tools to identify and chain vulnerabilities, domain specific expertise provided by a deep bench will be needed in the future.

Thesis 3:

Cybersecurity companies will be trimming headcount and employing more AI tools internally.

Thesis 4:

Instead of hiring a cybersecurity company, companies will staff their own cybersecurity departments.

Of all of these, I think #4 (companies growing their own cybersecurity departments) is the least likely. #3 is highly likely (there will be some reorganizing and continued adoption of automated tooling). And while #1 (companies will no longer be able to command a large premium) may be true in some cases, I think #2 (this is a giant overreaction, and the use of automated exploit chaining means you need more expertise in defense) is probably the most likely outcome. Building a system to ensure your code is foolproof just breeds bigger fools.

This is an interesting point (taxation, or licensing fees) that I'm not sure others have brought up before. However, it is a logical extension to the idea that once a review/ban platform is in place, you could then pay a "fee" to the right people to let you print the desired item.

Let's assume that they're not blatant enough to slap on something called a production tax. Instead let's assume they're going to pass an "Environmental Recycling and Recovery Fee" and a "Emissions Control Fee", because, California, which of course, are just another form of production tax.

But frankly they could just do that by slapping those fees on filament just like the music industry got a tax passed to tax recordable media.

"The Audio Home Recording Act of 1992 (AHRA) amended the United States copyright law by adding Chapter 10, "Digital Audio Recording Devices and Media". The act enabled the release of recordable digital formats such as Sony's Digital Audio Tape without fear of contributory infringement lawsuits. "

https://en.wikipedia.org/wiki/...

I guess in the case you are proposing, then certain types of 3D printed shapes would be worth more than others? And who would define the prices, and who would get the revenue? I'm reminded of fraudulent music copyright takeovers on Youtube:

"The MediaMuv scam is not unique. YouTube scammers commonly claim a small percentage of song royalties, hoping to go undetected by targeting songs with multiple rights holders who likely arenâ(TM)t aware of how many royalties are being collected. However, MediaMuv was more âoebrazen,â Billboard reported, âoeoftenâ claiming âoe100 percent of royalties for master recordings or publishing.â

Through AdRev, MediaMuv collected royalties that belonged to other rights holders, who starting in 2017, began contacting MediaMuv and AdRev over MediaMuvâ(TM)s fake copyright claims that some believed were genuinely made in error."

https://arstechnica.com/tech-p...

Whenever a faceless entity controls the collection and disbursement of money, that pile of money is vulnerable to fraud.

Bingo.

It is too expensive for private interests to build such a system and then convince people to willingly use it.

However, if they convince government to do it for them, using taxpayer money, then it would be trivial to then layer on additional "protections" that benefit their pocketbooks.

Imagine if John Deere was able to say "You can't plastic print these parts, because they are a public safety hazard to people using John Deere equipment, and we don't want people counterfeiting and selling these parts." This would of course also ban farmers from printing their own parts and enforce the lock-in that has expensive equipment stranded in fields and crops rotting as you wait for a service technician to show up.

"DOJ" in this case refers to the California Department of Justice, not the US Federal Department of Justice.

Text of the proposed California Assembly bill is here:

https://leginfo.legislature.ca...

Generally it is not illegal for you to rent time in a machine shop (in the United States) to produce a receiver (depending on various state laws.)

It is also generally not illegal in the United States (again, depending on various state laws) to run your own small scale ammunition press at home to make your own ammo. It is in fact, the only way for certain out-of production calibers to be produced these days, unless you want to commission a custom run. There are also people who design and produce their own custom derivations (known as wildcat cartridges), some of which have become later commercial successes in their own right. Other people hand-load in order to optimize the ballistics for a specific application (for better distance, accuracy, compatibility with a specific firearm build, etc.) To my knowledge, other than state laws restricting the sale of ammo (if they exist), and federal restrictions on caliber, as well as issues with liability and quality, there's no restriction of resale of handloaded ammo, as there is with a homebuilt gun produced for personal use.

Manufacturing a firearm without a license for sale is the regulation you are talking about.

Quick education in guns:

The receiver is whatever the ATF says it is. In some cases, the frame is the receiver (for example a revolver, or a traditionally manufactured pistol). In other cases, the metal rails that nest in the interchangeable plastic frame are the receiver.

A trigger is typically not considered part of the receiver. However, there's nothing in the proposed law that says that the trigger shall be excluded from consideration as part of an overall algorithm to prevent printing of "a firearm."

https://leginfo.legislature.ca...

"(3) The performance standards shall require that firearm blueprint detection algorithms have the capacity, with a high degree of accuracy, to do all of the following:
(A) Evaluate three-dimensional printing files, whether in the form of STL files or other computer-aided design files or geometric code.
(B) Detect and identify any such files that can be used to program a three-dimensional printer to produce a firearm or illegal firearm parts.
(C) Flag any disallowed files for rejection by a software control process."

Some triggers (in combination with other modifications) can be considered modifications that allow rapid fire, and thus disallowed by the algorithm, as a potential "illegal part".

The kicker is this:

"(5) The department or other relevant state agency shall not require that a firearm blueprint detection algorithm produce a perfect success rate at detecting disallowed files. "

Assume a company designing an algorithm to pass the state mandated law. With (5) above, it would probably be better to have it err on the side of caution and flag all firearm related parts. Better to do that than get hauled up before a board of inquiry as to why the algorithm failed to detect a part of a print (which would include the trigger) that made it into a gun that was used to commit a crime.

Still, there's a lot of potential legal liability for the company producing the algorithm if there was a chance that such a print actually could be done and the state-approved algorithm failed to detect it. Think about companies that produce cameras to detect weapons in schools. Better for them, from a legal liability perspective, to flag a bag of Doritos as a gun, than to miss a real gun, even if for the schools, the false positives are a headache.

Road to hell. Check.
Good intentions. Check.

At this point I'd want to know what the estimate is for establishing and funding the CA DOJ apparatus to regulate 3D printers in the state, and the impact it would case on professional and hobbyist markets through:

1. Regulatory compliance. There are a number of pistols that are not sold in California because California has its own set of safety certifications that manufacturers have to get that effectively act as a ban on sales in the state (hint, it's an effective ban because the cost of certification far outweighs any resulting sales.) I would assume that they'd extend this regime to 3D printers - you'd have to pay the state to prove your product doesn't violate the law, and then continue to (pay to) maintain that certification in order continue selling in-state. They do this with catalytic converters too - California has its own regulations that override EPA certifications for catalytic converters, which mandate which approved parts can be used on which vehicles.

2. Collapse of the legal resale market. You'd have to get what would amount to an FFL to sell 3D printers, and any 3D printer that couldn't be demonstrated to pass current compliance could not be sold. You might not even be allowed to buy replacement parts if they weren't certified. Thus you'd have to sell your old machines (working or not) out of state (assuming the other states haven't passed similar laws.).

BTW, folks from other states might not understand, this kind of insanity is standard in California (introduce invasive laws that make no sense) due to the fact that our legislature is FULL TIME.

Yes, we pay them (and their staffs) for 365 days of work (minus vacation and holidays). And this is what they give us.

https://ballotpedia.org/States...

"As of 2017, full-time legislatures generally had larger staffs than other legislatures. A few exceptions to this rule were Florida and Texas, whose hybrid legislatures had larger staffs than a number of full-time legislatures. This meant that not all staff members worked at the State Capitol; some states with full-time legislatures also had district offices and staff.

Among all 50 states, each state averaged 682 staff members. The 10 full-time legislatures averaged 1,250 staff members each. Legislatures that spent more than two-thirds of a full-time job used 469 staff members on average. Legislatures that spent half of a full-time job used 160 staff members on average.[1] "

Your tax dollars at work.

I'd expect this kind of crazy from California and New York. I don't know what happened to Washington.

Real problem:

Mass displacement of white collar workers underway. A lot of careers outside of the white collar world require training and certification, with barriers to licensing (outside of exams) such as minimum number of hours worked before qualifying to sit for an exam. Unemployment hasn't been adjusted to keep up with inflation. Things are not great.

Fake problem:

3D printers could be used to make unapproved machines at home. Better tax people to create a bureaucracy dedicated to keeping people from potentially causing a non-existent public threat. Best case - security theater. Worst case - camel under the nose to start regulating computing devices as well. After all, computers could be used to *gasp* share machine drawings for people to manufacture gun parts without a 3D printer!

Also, g-code is used not just for additive manufacturing, but also for things like routers and mills. If you regulate all software capable of generating g-code for a 3D printer, you're also directly regulating all computing platforms used in those industries. Open source project to generate g-code for a cricut? Could be used as a circumvention device, BANNED. Open source project to build a CNC mill requires a slicer - which now is illegal to run without a government subscription and yearly licensing fee in California. Effectively BANNED.

Great, there goes the in-state manufacturing industry. I guess we'll just have to ship all our work out of state, and those jobs too...

Plea for sanity:

This really feels like rearranging deck chairs on the Titanic for the sake of "doing something". Invent a problem that doesn't exist, and then spend money making it go away. Can we please start laying off politicians instead? Or identifying the lobbyists that are pushing for this so we can rightly tar and feather them before this spreads any further?

There's also the impact of the rampocalypse.

As expensive as Apple originally priced the ram used on Mac Minis, it looks darn right reasonable right now with the surge in DDR5 prices.

Is this news because this happens often, or not often enough (the google manual death penalty)?