I don't trust commodity-manufacturers who need to keep rapidly iterating their products to maintain profits to supply me with something intended to be affixed for the long term.

Even though Apple might do a better job than many vendors, they still release products that stop receiving updates and other maintenance long before the physical hardware is worn out. Something that's going to be with me for a very long time, like something permanently installed in my house, or something integrated into my car, is not something that I want from a commodities-supplying tech firm.

the game's uncommon method of generating galaxies of incomprehensible scale on device consistently for all players from a single-seed happening on a phone is remarkable for those of us who remember phones performing far behind consoles or desktop PCs.

No it isn't. Your phone is a supercomputer by 1980s standards, and seeded generation (whether from a PRNG or hashing coordinates or whatever) goes back to at least then (and probably '60s/'70s). I'm not slamming the game, and seeded generation is often a good idea, but the idea that you can do it on handheld supercomputers is not remarkable, even the tiniest little bit.

You wanna see something super-fucking-impressive on an iPhone? Go back to the very first model and behold that it runs a truly-remarkably decent web browser. That was way more futuristic than this.

Reading his wiki entry he reminds me of Bergholt Stuttley Johnson.

Without buying into the conspiracy theory, but this is why I dislike these short lifetimes. It makes my otherwise 100% autonomous website dependent on an external party. I think I'll go back to also offer the site on unencrypted http instead of making an https redirect.

I could not speak to the cost/benefit ratio in Europe, but in the United States, 1.544Mb on a Frame Relay would cost more than 1Gb on a Metro Ethernet fiber connection. I know because I retired a Nortel Meridian telephone system using T1 links specifically because it was costing more than the 1Gb and later 10Gb Metro Ethernet L2 MPLS connection and had far, far less flexibility. We migrated over to VOIP phones and saved a ton of money on the ~75 service entrances we were taking care of, and the VOIP traffic was a drop in the bucket on that network.

The only thing I could think of after my original post would be to contract with a cellular provider for a private APN (think similar to a VLAN or VRF for a subscriber with a ton of individual cellular endpoints, doesn't route to the outside like normal cell carriers' endpoints can) and then bringing that APN into a cloud instance with firewalling to prevent unauthorized traffic from the Internet from being able to hit the APN in the first place, but that still requires IT security practices.

The annoying thing about a private APN and using cellular is when the carriers change-up their gear it becomes necessary to replace the cellular endpoint equipment. I've seen this happen with security system cellular (no private APN) where the 2G gear had to be replaced, they went with 3G gear, only for that to also have to be replaced when the carrier wanted to go to a minimum of 4G LTE.

I expect that Yandex is hiding behind statements in their contracts and Russian laws governing liability due to armed conflict to try to skate any responsibility to their customers.

Given how quickly America came to disliking datacenters, seemingly as a real grassroots thing through hatred of techbros, hatred of higher energy prices to their own households, and hatred to water scarcity, seems like any complaint that Trump would make about it would simply lead to more backlash upon him.

I could see a fire starting in an electrical distribution panel if, once the problem was discovered, someone set all of the fridges in the building back down to proper temp and the startup demands exceeded the panel's ability to supply power, but that's more of an electrical equipment fault in being faulty or undersized rather than an IT fault.

I'll bite, what sort of remote control can you do that isn't, some how, some way, using the Internet? You gonna lease RF spectrum and set up some kind of radio controls?

This is realistically where the failure sits, but it's unlikely that in an IPv4 network, that the IPs of the IoT endpoints would be directly exposed to the Internet as they'd normally be RFC1918 addresses and would require someone to explicitly set up inbound NAT rules to forward to those endpoints for them to be directly exposed. So the question then becomes, what as the method of exposure? Were they on Internet-routable IPv6 addresses where someone screwed up setting up security? Was some other method used to get into a private network, and from there they hopped through to these endpoints? Was the network security for the LAN the fridges were on actually done right, but the vendor's management tool breached and the tampering from "the cloud"?

We don't really know if they actually got to 50C, just that they were set to that. For all we know they just shut off when the actual thermostat realized that the commanded temperature was higher than the actual temperature. But the point about liability still stands, and we don't know if they have any sort of privilege escalation based on type of administrator.

I did give it a skim. It looks to me like despite this being a supposedly industrial system, the company behind it neither understands IT security practices, no do their customers. This isn't exactly surprising, as HVAC technicians who are used to troubleshooting blown fuses, bad compressor pumps, and clogged heat exchangers are busy and the nature of IT security is shifting. It sounds like both the company behind the products and the customers made serious errors, very likely in the guise of keeping costs down by simply not addressing vulnerabilities.

I'm personally against industrial controls that connect back via normal outbound NAT like any other internal endpoint would that use destination port 443 for their communications. This is becoming increasingly common as BACnet traffic (typically on port 47808 and up) is replaced by BACnet Secure, which just uses normal SSL. Don't get me wrong, the old way on BACnet isn't exactly secure even when an enterprise customer sets up a VPN tunnel and forces all traffic from the particular equipment to the management cloud tool that traffic is unencrypted on the customer's network, but the SSL model along with cloud endpoints' IPs changing regularly as their various cloud hosts switch between AWS, Azure, and other providers means it's more difficult to determine if someone's internal endpoint is communicating with the only hosts that it should, or if it's compromised and connecting to some command-and-control server that looks superficially the same as normal traffic.

If I were investigating this, I'd start by getting the operational topology from the vendor that made the equipment and presumably the control software, and I'd start at the point most in-common among the victims. If the vendor itself was compromised then there's the problem. If the vendor wasn't compromised, I'd start to look at how the protocols on these systems work and what sort of opportunity there was for interception to learn of the endpoints in order to build out the profile used for the attack. I'd then want to review the actual faults that the vendor supposedly warned their customers about.

Unfortunately good IT security is expensive, and I expect that most businesses adopted these supposedly smart commercial refrigerator controls to save money, not to spend more on it. They might well have been better off to just install Internet-connected temperature sensors that had no actual control capability, where a central monitoring room could call the customer if a fridge was being reported as outside of the proper temp range, so that the customer could engage a technician to troubleshoot. But instead they tried to go even cheaper by centralizing all of it, to a fault.

Of course people should beware. Anyone who has a problem with Flock is surely aware that they are only a fraction of "the problem," though among the more visible.

I'm concerned that some Flock haters might take us down a slippery slope to where you can't have a camera in your house if it looks out onto the street, or that you shouldn't be allowed to record cops, or that I shouldn't be allowed to have a camera attachment on my Manhattan apartment balcony telescope that I normally just use to furiously goon to the good people of NYC who don't close their curtains. (Oops, forget that third example.)

I can't say I'm a fan of Flock but if their rights are infringed in a way that might possibly expand to everyone else, then they will need to be defended.

That said, I have a modest proposal for the law-enforcement-related problems of surveillance vendors. Require non-warrant sharing with LE to be unreliable. For every geo search, remove a random half of the applicable results and replace them with deliberate, randomized false positives, so that LE will know the data shouldn't be taken too seriously on its own. If cops act without confirmation while KNOWING it's _at least_ 50% likely to be wrong, that'll help with the civil suits for false arrests.

No, not at all. The gender pay gap is in the training data thousands of times, from online comments, studies, news articles, etc. Since AI is a dumb machine replicating what it has in its training data, it replicates that.

I'm pretty sure you can find religious believe, superstitions of all kinds, human fallacies and whatever in AI if you provide it with the right setup.

HEIC is worthless because it's illegal to implement unless you get permission. Maybe in 20 years it'll be usable.

Don't like that fact? Then we need to find and support (oh no, and be?) political candidates who oppose software patents.

You shouldn't need anyone's permission to write a computer program. It's infuriating.

This. No good game was ever created from a single prompt. Not to an AI, not a human development team. Every single person writing those damn "look which game my AI built from a single prompt and $x in tokens!" postings is a newbie and almost certainly has never actually shipped a single game.

Game development can be summed up as endless iterations. Every system you build, every visual you create, every sound, text, button, movement, weapon, skill, powerup needs polishing, refinement and changes. It is never, never good enough the first time.

No it is not, but it IS a very successful platform for a specific subclass of games. If I were in it for the money, I could probably AI refactor some of my earliest games and publish them on Roblox and make a quick buck. If your thing is the kind of games you played on your C64 back in 1793, then Roblox got you covered. Well, if you ignore the scams and money-grabbing.

*sigh* I wish Unity would actually complete some of their dozens half-finished sub-systems instead of constantly chasing the latest trend. It's become really, really annoying. The engine used to be really good. These days, it falls apart if you look at it the wrong way, and at least from the responses to my bug reports it's clear that fixing issues is way down on the agenda.

Maybe this is their attempt to regain grounds in the indie game market - the very market they pushed away by focussing on AAA requirements for years and ignoring the single devs and small teams. If so, I can already tell them that it won't work. We collectively laugh about all the "look what my AI built for me from a single prompt" postings on reddit, where people proudly show off some AI slop that would get them last place at a game jam.

Their AI efforts so far: Tried to build and sell their own AI tools, to a collective yawn from the audience. Built a barely-working MCP server, then deprecated it before it was even finished in order to push a CLI interface to the editor instead, which only works if it's run as the same user as the editor on the same machine. And completely ignores every single advise on workflows and good development practices you can think of.

Unity, I love your engine, I despise your management. Please return to when you were actually good and stop chasing butterflies.

The target audience for this particular rule of the AI Act isn't the producers or users of AI. It is the consumers of content that might be AI generated.

And frankly, letting people know if they see AI content or not is a fair thing to ask.