> Ended up building my own thing that is 10x simpler, just a simple main agent you talk to, that can dispatch subagents, they all communicate, wake each other up and keep track of work through a simple CLI. No « refinery » or « wasteland » or « molecule » or « convoys » or « deacons » or …
You won't get 10k stars and a blog post out of that. Obviously you need some Stoats who have Conferences with the Stump Lord to determine whether they are needed at the Silo or the Bilge. They'll then regroup at the appropriate Decision Epicenter and delegate to the Weasels and Chipmunks who actually do the coding (antiquated term) in the Salt Mine.
I don't think it will be cost effective to build humanoid robots to do most tangible work. Why assemble an expensive masterpiece of servomotors, chips, plastic and steel, when billions of desperate humans are right there and only cost 2.5 meals a day and a small shelter?
Of course, intelligence will be a solved problem so "20 years of training" won't be needed. You'll just be the hardware. AI will tell you to pick up that box, place it on that conveyor belt, place the autowelder at that seam and wait for the green light, turn the wrench to install bolt B in part C. If you don't wish to, or no longer can, so be it. Another, hungrier human will replace you. After all more are made every day, and they are capable of doing this type of labor by age 10 or so. And what else would they do with their time, go to school and get a completely useless education?
All of this will of course be in service of our technofeudal lords, the owner class. Some robots will be needed for heavy lifting and for the jobs that are too sensitive to trust a human in, like personal security and strikebreaking. Can't risk trusting a serf for those tasks. But for most physical grunt work humans will be cheaper. Shockingly cheap, when they have no other options.
Humanoid robots are only the intermediary. Eventually processes that use robots will be redeveloped to used something that doesn't look anything like a human robot.
In that sense I see their higher cost as temporary. Another factor: robots will not rise up and blow up your factory. They will always work at the same efficiency for each and every robot produced. They will not go on hunger strikes. They will not kill themselves.
> I don't think it will be cost effective to build humanoid robots to do most tangible work. Why assemble an expensive masterpiece of servomotors, chips, plastic and steel, when billions of desperate humans are right there and only cost 2.5 meals a day and a small shelter
If all you have to offer people is this kind of sad fucking "2.5 meals a day and a small shelter" while you live on yachts and eat like a king, eventually they will gang up and kill you
I keep wondering when the west will get tired of having kings and they keep surprising me. I assume humanity get to The Culture eventually, but I'm starting to doubt that Americans will be leading the way on that front.
But maybe Altmans AI will break out and do it for us.
Me too. I also miss the days when I was proud of my little open source projects. Now I just regret donating fuel, even a miniscule amount in the grand scheme of things, to the soulless lawnmower that has already chopped down so much of my joy in work and promises to eventually shred the paycheck, too.
I hear yah, especially knowing that AI crawlers just don't respect ROBOTS.txt or anything similar, but there's still nothing wrong with writing code for fun.. No need to lose that!
Brilliant clip. :) I'm sure we've all had dreams that feel like that. If I had to put a point on it for this one, the "self-play" game happening here is your brain serving up instantaneous new plausible and unanticipated excuses for why you can't see the object that you're struggling to get a glimpse of!
This reminds me of playing Ecks vs. Sever on the GBA. A raycasted 2.5d doomlike game based on a crappy movie. It was pretty impressive for a GBA game, and it ran well, never stuttering. It had some pretty cool levels, I remember one where you fight through a hotel using IR night vision. It also had a sequel which added a guided missile launcher and some crazy Robocop ED-209 type enemies. As I recall both had multiplayer deathmatch but good luck finding a friend who also had the game and a link cable.
One thing I took full advantage of as a kid was that both games had some cheesy behavior with the sniper rifle scope implementation.
In the first game, while zoomed in with the scope you could use the D-pad to move your view a few clicks left/right/up/down to refine your aim. However, this was not really turning you, it acted more like you were a ghost side-stepping and poking his head up and down. So, you could crouch behind a box, scope in on the box, then D-pad up to look over it and shoot an enemy mob who still couldn't see your character and wouldn't engage you. Or stand just slightly behind a corner, scope in, and D-pad right to shoot around it.
The last level of the first game involves fighting a boss character who has a powerful weapon and a ton of HP, and is surrounded by his infinitely-respawning goons. There's no way kid me would've beaten it without abusing this trick, which reduces the challenge to avoiding his attacks while fighting enough lower-tier enemies to obtain their precious sniper rifle ammo.
In the second game, the D-pad moves a crosshair around a fixed viewport rather than shifting the whole viewport around. So the trick doesn't work exactly the same way. If you zoomed in staring at some obstacle right in front of you, you couldn't move the viewport to see around it like you could before.
However... when you zoomed in, it worked like you were a ghost moving forward in space, instead of narrowing your FOV from your original vantage point. So you'd instead stand about 10 feet back from a corner, zoom in past the edge, and voila: you were able to see more around the corner just as if you'd walked up next to it. Sure enough, you could slide the crosshair over and snipe the enemies now visible in your viewport despite your player character still being safely 10 feet back around the corner.
Good times. They were still great GBA games even with this exploit, it just made the (scarce) sniper rifle ammo even more valuable to the player.
All three are also superficially easy to learn to use, hence they're able to sucker people in initially with the learning curve, then keep them there with the sunk cost fallacy.
Does AI do COBOL yet? Maybe that's where all the jobs will be in a decade. It's not like there are a ton of blog posts about how to do stuff in COBOL to train it on.
I empathize with you. I had a (very small) side business where I was making custom wood grip panels for handguns. On the one hand, these are firearm parts but on the other hand, they are also inert, harmless pieces of wood that aren't needed for the firearms to function. I used Stripe to accept payments. When I originally signed up for the Stripe account I specifically asked customer support whether this would be OK. The response I got (in 2019) was:
> Stripe does have some strict rules over the types of businesses we can and cannot support. Firearms accessories is an area that we split into two. Businesses selling firearms and parts required for the functioning of the firearm are restricted from using Stripe. Businesses selling firearms accessories and parts not required for the functioning of the firearm can be fully supported.
> As your business falls into the second category, I'm pleased to say that you would be able to use Stripe.
In 2022 my Stripe account was closed. I entered an "appeal" quoting that original response and asking whether their policy had changed, or their assessment of the products I was selling. The response I got did not answer that and simply said "we are unable to accept payments for weapons, ammunition, and related products, as mentioned on our restricted businesses list."
To be honest I was kind of done with it anyway, it had gotten to that "not fun" point where a hobby becomes a chore. And it wasn't an income stream big enough to make any difference in my quality of life. So I didn't bother appealing further or even seeking an alternate payment provider. But I was still annoyed that they didn't tell me what changed between when I got approval and when I got shut down.
Lazy loading was a mistake in EF. A lot of apps had awful performance due to lazy loading properties in a foreach loop creating N+1 queries to the database. It would be fine in dev with 50-100 rows and a localhost SQL and blow up in prod with 1000s of rows and a separate Azure SQL.
Also if you relied on lazy loading properties after the DbContext had been disposed (after the using() block) you were out of luck.
With old EF we would turn off lazy loading to make sure devs always got an exception if they hadn’t used .Include() to bring the related entities back in their initial query. Querying the database should always be explicit not lurking behind property getters.
Fortunately with EF core MS realized this and it’s off by default. EF with wise use of .Include and no lazy loading is a pretty good ORM!
You won't get 10k stars and a blog post out of that. Obviously you need some Stoats who have Conferences with the Stump Lord to determine whether they are needed at the Silo or the Bilge. They'll then regroup at the appropriate Decision Epicenter and delegate to the Weasels and Chipmunks who actually do the coding (antiquated term) in the Salt Mine.
The Stump Lord is an owl.
reply