414 karma · joined April 11, 2018
Also, if they were genuinely responsible, why can a child's parents be held accountable for them developing an addiction? The company was responsible, not the parent... do you see how ignorant that sounds?
Who would be responsible if a child developed alcohol addiction? A nicotine problem? Any other addiction?
Exactly. The same people that should be responsible for giving them unfettered access to an internet that is no longer safe. Even adults have to be wary of getting hooked on scrolling, and while I agree that the onus is on the companies, it has been demonstrated over and over again that they will not be held to account for their behavior.
So the only logical choice left that actually preserves freedom is for parents to get off their ass and keep their child safe. Parent's that don't use filtering and monitoring software with their children should be charged with neglect. They are for sending a kid into the cold without a coat, or letting them go hungry, why is it different sending them onto the internet?
And to your last point: You are dead wrong. No government anywhere in the world has demonstrated that they have the resources, expertise, or technical knowledge to solve this problem. The most famously successful attempt is the Chinese Great Firewall, which is breached routinely by folks. As soon as a government controls what speech you are allowed to consume, the next logical step for them is to restrict what speech you can say, because waging war on what people access will always fail. I mean, Facebook alone already contains tons of content that's against its terms of service, and they have more money than God, so either they actually want that content there, or they are too understaffed to deal with the volume, and the volume problem only ever increases.
So in my view, you are the one against freedom by advocating for the government to control the speech adults can access for the sake of "protecting the children" when the actual people that are socially, morally, and legally culpable for that protection are derelict in their duties.
I wanted to use UEFI, but my orangepi cm5 modules don't seem to have the SPI chip needed to store the UEFI there, so I'd have to load it on a partition and lose out on some features like persisting variables across boot.
The arm ecosystem really needs to settle on some sort of universal boot loader / firmware layer and stop just hacking up the linux kernel and not contributing back to it.
But yes, all of my personal projects are in Godot now, and I'm planning to use it for some tooling at work, just because it's UI system is nicer than Unity's as well as it having better support for re-using editor UI components in an application.
The codebase is dense, hard to compile, using outdated dependencies, and doesn't play nice with anything else. Documentation is sparse, often incorrect, and severely lacking in anything like a new user guide. Everything assumes you work for Pixar already and know the ins and outs of their pipeline.
Infant mortality rates were dramatically higher in the past and drag that average way down, for instance, say I have a 1 day old infant, and a 100 year old person and they both die, they have a combined 'average life expectancy' of 50 years old. But, once you made it out of the 'childhood illness' mortality stage, most folks could expect to see 70 years old.
https://sc.edu/uofsc/posts/2022/08/conversation-old-age-is-n...
From the Godot 3.2 docs on C#: > Exporting Mono projects is supported for desktop platforms (Linux, Windows and macOS), Android, HTML5, and iOS. The only platform not supported yet is UWP.
And from a recent Github discussion for 4.2: https://github.com/godotengine/godot/pull/73257
The problem is, it's a massively difficult undertaking to make a custom 3D game engine. Rendering alone is a huge topic without getting into the specifics of interfacing with GPU drivers. Window management is incredibly complex, especially if you want to support multiple platforms, or multiple modes of input. And then once you have all of that figured out, you still have to make some system to integrate the state of your game with all of those systems, and then finally, add your game logic on top. All while still building out those lower level systems as you go.
This is way easier to do in 2D than it is in 3D, largely because most people have a better grasp of 2D geometry than 3D, but even just making something OG Mario Bros. needs a fairly substantial game engine. Sure you can code golf it into something tiny, but then you don't have an engine, you have a game program. Engines need a certain level of flexibility to explore.
And sure, there are libraries for doing all of those things, but wiring them up together often ends up with piles of adapter code between the libraries to let them all use each other's data structures, at which point natural groupings of libraries form, and you're effectively back to having a game engine, just by defacto standard instead of intentional assembly.