Yeah I agree with that as well, the unsafe keyword takes on a double-duty which makes it unclear how it's actually intended to be used. The idea that you might mark a function that's only made of safe code as 'unsafe' is not that obvious and not always agreed upon, I've seen plenty of debating about it.
The fact that 'unsafe' also enables all unsafe operations in the function body just makes it even messier, since you definitely _don't_ want that unless the entire body is really nothing but unsafe operations. Thus the "mark a safe function as unsafe" has a clear downside since it allows all the unsafe operations you didn't want to use.
> But the bug is still almost always in an unsafe block.
That's entirely dependent on how you write your Rust code. If you're derefing an invalid pointer then the bug is usually in how you calculated that pointer value, but the only part that actually requires 'unsafe' is the deref, not the bugged pointer calculation.
Now in properly written Rust code you should be marking all of that code as 'unsafe' in that case and documenting what invariants need to be maintained, but that's entirely on you to do. The only part the compiler actually enforces is that you mark the specific spots where you make use of the operations that 'unsafe' allows.
> A leap-hour, meanwhile: That kicks the can so far down the road that we'll probably lose track of it completely. 600 years is a very long time; society will be a very thing by then. Leap-hours seem to me to be moral equivalent to the "fuck it, let's just give up" option.
Something to consider: The use of timezones in mostly 1-hour increments over inconsistently placed areas means that the vast majority of people are already living many minutes off from the "actual" time at their precise location, in some cases even more than an hour. "Giving-up" implies that this is something important worth maintaining, where-as for the vast majority of people they gain nothing from leap seconds or even leap minutes. The most important thing for people is simply that everybody agrees on what time it is, which is easier when leap-Xs aren't done.
That said it's also probably true that a leap-hour would never actually happen, but that's not some big issue. By the time we got to the point that a leap-hour would make sense people would have already adjusted their habits and it probably wouldn't be worth it.
For me the problem is that the target performance is in a weird spot - low enough that it's not amazing, but high enough to still be very expensive if you don't plan to play games that actually require that performance.
A cheap $300 mini-PC is a lot weaker but it can still play plenty of indie and other games just fine, ultimately that's what matters. For me, I would have considered buying one of these if they had one at a $300 to $400 price point even though it would have been significantly weaker, but at $1k it's just impossible for me to justify.
The government will release it with all the copyrighted code and assets that's owned by a bunch of third-parties?
Ex. if I license my artwork, music, characters, code library, etc. to a game developer and they don't create a legally releasable version of their server, then the government will forcibly break our licensing agreement and I just get screwed?
> Wouldn’t it only require action from you if you were trying to kill multiplayer in the first place?
It's a question of when, not if - you're not going to pay to keep the servers online forever. What are the legal consequences of not releasing a functioning server if for some reason you can't? If they're bad enough then plenty of people will not be interested in taking that risk by making such games.
That doesn't sound that unlikely to me personally, not everybody has the best tech habits and some life events can result in losing access to both very quickly. It doesn't have to happen often for it to still be a common event in support cases.
The point is that at a minimum you're supposed to bubble the `unsafe` up if the API does not guarantee safety is maintained for all cases (and documents the invariants that have to be kept by the caller), otherwise the system breaks down.
> Assuming the port is actually 1:1 without any behavioral changes
It's not, that's clear from this kind of bug popping up. Functionally this bug exists because `PathString` was converted into a "safe" Rust API but still works the same internally as the original Zig code did (via using `unsafe`), that introduces UB that wasn't there in the Zig code.
If it was attempting to be a 1:1 with no behavior changes (like c2Rust attempts to do) then this would not have been turned into a "safe" Rust API like this.
Sellers what? You generally don't just drop stuff off at a fulfillment center, when you get to that size you're dealing with large amounts of inventory and you ship it to them.
If you're saying sellers could come into a GameStop to have their individual items packed and shipped out, I suppose, but:
1. They don't really have the space for much shipping volume at any of their stores.
2. You can walk into any USPS, UPS, FedEx, etc. store and do that already, you don't need an 'EBay' store. GameStop would presumably get the packages picked up by one of those carriers so it's not saving any shipping time or expense.
For buyers, in many cases there's already alternative drop-off locations similar to GameStop Ex. For UPS deliveries I can get them shipped to a bunch of different convenience stores near me. GameStop stores might be a nice addition to that list but it's not enabling something you couldn't do before, and I would think for most people they already have a closer location than a GameStop.
> Obviously they're going to need to liquidate a lot of this stuff.
If you read online employees have talked about how they donated it or threw it all out, presumably there is very little of that stuff left at this point (and probably nothing left of any real value).
No, why does it matter? I also don't know where my local GameStop is since the few by me closed a couple years ago :P
Plenty of stuff on EBay offers me 2 day shipping clearly via fulfillment centers, as far as I'm concerned that's all that matters. Do you think the addition of GameStop stores would mean EBay can offer faster shipping than that on a significant number of items?
Yeah this is the funny part to me - if you thought EBay was an amazing business then you could have just bought that stock months or years ago. Maybe the combined company will really be worth more than both companies individually, but for the most part this is just GameStop deciding how you should have invested your money months ago.
Well let's be clear, the "trade-in anything" day was a fancy discount day. They gave everybody $5 for whatever they brought in, online you can read from employees that they just donated or threw it all away, no attempt to actually keep any of it to sell.
That said IMO the biggest difference in the two situations you're describing is that EBay is not in the business of buying the items to then sell later, they just facilitate transactions between two parties and some of the logistics (depending on the seller). They're similar as far as dealing with "used goods" but the actual design of the business and risk being taken on is very different.
EBay also not really lacking what you're describing - there are fufillment centers that can be used for EBay listings, there's the EBay "Authenticity Guarantee" program for cards, they already own TCGplayer which does all of this for trading cards way better than GameStop does, etc.
Perhaps somehow these things could be improved by GameStop but I can't imagine it being significantly better than it currently is.
Well I'd add to that - the real core feature is that the teacher and usually the textbook show you exactly how to use it, that's why it gets listed specifically as a course requirement.
That unfortunately is also why they can charge so much and people buy them anyway, because at best you'll be on your own to learn how to use anything else (and at worst you won't be allowed to use it at all for tests and such).
It all depends on the CPU architecture, if it supports something like out-of-order execution then both parts of the CPU could be in use at the same time to execute different instructions. Realistically any CPU with that level of complexity doesn't care about SUB vs XOR though.
I think you're somewhat missing the point - if the code from A and B only works if joined with C, then you should squash them all into one commit so that they can't be separated. If you do that then the problem you're describing goes away since you'll only be rebasing a single commit anyway.
Whether this is valuable is up to you, but IMO I'd say it's better practice than not. People do dumb things with the history and it's harder to do dumb things if the commits are self-contained. Additionally if a feature branch includes multiple commits + merges I'd much rather they squash that into a single commit (or a couple logical commits) instead of keeping what's likely a mess of a history anyway.
The fact that 'unsafe' also enables all unsafe operations in the function body just makes it even messier, since you definitely _don't_ want that unless the entire body is really nothing but unsafe operations. Thus the "mark a safe function as unsafe" has a clear downside since it allows all the unsafe operations you didn't want to use.