I disagree that it’s so simple, 10 is different because for a long time it was unclear 11 was ever going to happen, the biyearly releases were the new versions. For most of the other Windows versions they didn’t stop receiving security update until well after the next version or two were out. 11 will have only been out for 4 years when support for 10 theoretically stops.

At least I attempted to looked it up, rather than everyone else who assumed it just can’t happen at all while also knowing nothing about it.

No, what I’m saying is that a quick Google suggests you can get jail time for this in Colombia even if Apple is the one suing. Obviously I’m not an expert, but my point is that Apple’s threat of possible jail time is not completely unfounded, you can’t assume it just works like the US legal system.

I think you might be making too many assumptions about the Colombian legal system.

It’s not quite what you’re getting at, but in Bubble Bobble Revolution you can’t pass level 30 because the boss doesn’t spawn. It’s a soft lock but there’s nothing you can do to avoid it, and the game is on the DS so there’s no updates to fix it :D

The only makes sense if they actually wanted to keep him that long after he tried to quit. We don’t know for sure but potentially they just wanted to keep him around long enough to find a replacement (since he just told them he’s quitting).

Much of what she was brought on to do (negotiating with advertisers I guess) isn’t really public facing, so from that respect it’s not that surprising that she appears to be doing nothing. I also think she’s not taking the L yet, if things get even worse Musk may blame her as an excuse to walk things back (“I was following her advice” or whatever).

Maybe, but there’s a market out there for CEOs who are willing to take the blame for some unpopular decisions and then walk away. There’s also something to be said that “-50%” might actually be an improvement over where it was before she was hired, and the bad decisions weren’t hers.

I feel like you ignored their chief issue, which is that if your original server (IE. lemmy.world) goes down then nothing works for you. In that situation you have to switch to a new server to be able to view anything, and likely need to create a new account on that server. There’s some other catches to this as well that makes it more problematic than just that.

They were definitely told the “it doesn’t matter what server you choose” line when they looked at lemmy, but in reality that’s not entirely true if a server isn’t that stable.

My point is that the data on here is purposely shared with every other federated instance, there’s no semblance of privacy and your data is shared with hundreds or likely thousands of admins by the time it’s done (more and more as the network grows). There’s no reason to trust that every admin will keep that information private, some people are already talking about putting up services to expose all the hidden information (in the name of “transparency”). It’s simply trivial for Meta or anybody else to get copies of the data because there’s no real protection from it unless you’re making your instance an island (and that’s an island from everybody, not just one specifically known to be Meta).

What’s the point of downloading a game if not to experience it?

“Nobody deserves to get paid for creating the games I enjoy”.

Ehh, you might as well waste as much of the admins time as possible.

Fundimentally none of the data on here is private, it’s not designed to be private.

I haven’t used Zig myself but I think it could have its place. IMO Rust has moved too far away from C to be something many existing users will move to (and using both in the same project is messy), but Zig seems to integrate well enough that it might.

I haven’t personally written a NES emulator but I have a friend who did and it seemed like a comparable level of difficulty to the GB. It did sound like emulating the cartridge hardware was harder because games didn’t tell you what they used (compared to GB where a cart tells your that info in the header), but I’m guessing you can cover most games by only implementing a small subset of the options anyway.

Lol the funny thing is that this isn’t even close to my longest project :P I have one with a first commit close to 10 years ago (and I of course started it a while before the first commit). It’s my favorite just for how fun the result is. IMO the best projects tend to be ones you actually like to use when you’re done.

That said I also wouldn’t put too much stock in that 1 year, I think I worked on it a lot for about a month and then moved onto other things after having trouble with it. I came back about a year later and managed to more or less finish it. It’s definitely a long time to devote to a project, but if you stayed focused on it you could do it in a couple months I think.

If you’re on Linux then I’m pretty sure the confusing behavior you’re seeing is due to the line buffering the kernel does by default. Ctrl+D does not actually mean “send EOF”, and it’s not the “EOF character”, rather it means “complete the current or next stdin read() request immediately”. That’s a very different thing, and sometimes it means EOF and other times it does not.

In practice what this means is that, if there is no data waiting to be sent on stdin then read() returns zero, and read() returning zero is how getchar() knows an EOF happened. The flow looks like this:

1. Your program calls getchar().
2. getchar() calls read() on stdin and your program blocks waiting for input.
3. The user presses Ctrl+D on the tty, having not typed anything else.
4. The kernel immediately ends the blocked read() call and returns zero bytes read.
5. getchar() sees that it got no bytes from read() and returns EOF.
6. Your program sees that and exits the loop.

However, in practice it doesn’t work that cleanly because the tty is normally operating in “cooked” mode, where the kernel sends input to your program line by line, allowing the user to edit a single line before sending it. The way this works is by buffering the stdin contents and sending it when the user hits enter. Going back to Ctrl-D, you can see how this screws things up, leading to the behavior you see:

1. Your program calls getchar().
2. getchar() calls read() on stdin and your program blocks waiting for input.
3. The user types some input, but does not hit enter. This data sits in the kernel’s stdin buffer and is not send to your program yet.
4. The user presses Ctrl+D on the tty.
5. The kernel immediately ends the blocked read() call and starts returning the currently buffered stdin input, without waiting for an enter press.
6. getchar() sees that it got a byte from read() and thus returns it.
7. Your program starts getting all the previously buffered bytes and keeps running until getchar() has seen all of them.
8. getchar() calls read() on stdin. There’s now no bytes in the buffer so you block waiting for input, the same as before. The previous Ctrl+D was already “used up” to end the previous read() call so it doesn’t matter any more.
9. The user types Ctrl+D.
10. Because there is currently no input in the line buffer, read() returns zero. getchar() sees this and returns EOF.

In the above case Ctrl+D doesn’t work as expected because of the line buffering. The read() call ended early without waiting as expected, but your program just starts receiving all the buffered input so it doesn’t have any idea you pressed Ctrl+D and never gets the read() == 0 EOF condition. Additionally the Ctrl+D is a one-time deal, it ends one read() call early and sends the buffered input. When you call read() again with nothing to send it just blocks and you have to do another Ctrl+D to actually get read() to return zero.

You can see the line buffering behavior if you add a putchar() inside your loop. The putchar() doesn’t actually print while you type the characters, it only prints after you hit either enter or Ctrl+D, showing that your program did not receive any of the characters until one of those two actions happened.

Starting with Gameboy might be a bit daunting but if you’re reasonably comfortable with C then I don’t think it’s too bad. If you’re not too familiar with the hardware side of it then that might be a challenge, but the advantage with the Gameboy is that there’s tons of documentation and tutorials out there which can probably help you work though the details. Really the big thing is to just be ready to do lots of reading XD You need to get a base-level of understanding of the system before you start coding. git says it took me around a year to get it functional and playing most ROMs, but that was with some big breaks in-between.

Also, that’s a very good question. For performance, it was never an issue. I started it with a focus on keeping the code clean vs. worry about performance and it turned out fine, I’ve run it on a cheap 1.6GHz machine and it didn’t even reach 25% CPU usage, so IMO I wouldn’t worry about it. This also doesn’t vary that much ROM to ROM.

For the ROMs I tested, for the most part every ROM tended to uncover something new, but the Gameboy has a pretty nice progression of “easy” to “hard” ROMs if you just sort by the MBC type, and also the BIOS is a pretty good test of basic functionality. Additionally there are a few different test suite ROMs out there that are fantastic, they’ll run through every instruction or piece of functionality and check for the correct results, they saved me tons of time.

I totally agree with you that a typical CEO would not put up with this at all, but then I don’t think this is a very typical situation :D I would assume she knew what she was getting into. He named himself CTO so it’s not like he’s no longer involved in the company, and the CEO can’t really ‘overrule’ him on any product decisions or anything else since he’s technically also her boss.

Now, if he’s smart he will hopefully at least take her opinions/guidance into consideration, but 🤷