Ran across this while writing the Quxlang compiler frontend. Was wondering how GCC/Clang solved this problem... turns out at least with regard to GCC... they don't!
GC was removed from the C++ standard in C++23 because all the compilers were like "hell no" and it was an optional feature so they could get away with not adding it. So this optional feature never actually existed and they removed it in later standards.
The C++ standard has never included a garbage collector. It only provided mechanisms intended to facilitate the implementation of a GC, but they were useless.
There are ways to do GC without language support. They are harder, but have been around in various forms for decades. They have never caught on though.
A document proposing terminology to describe 0-based indexes in unambiguous language.
For example, considering a sequence like [5, 4, 7, 8, 2]
What is the 4th element? 8, but if I asked what is the "0th element", you would answer 5, but that is the 1st element. The document introduces the terminology of the zerid element (0id element), oneid element (1id), etc. to handle 0-based indexing.
I think this honestly has more to do with moslty Chinese sellers engaging in review fraud, which is a rampant problem. I'm not saying non-Chinese sellers don't engage in review fraud, but I have noticed a trend that around 98% of fake or fraudulently advertised products are of Chinese origin.
If it was just because it was cheap, we'd also see similar fraud from Mexican or Vietnamese sellers, but I don't really see that.
There are various ways to do the trick, sometimes they ship out rocks to create a paper trail, sometimes they take a cheap/light product and then replace the listing with something more expensive and carry over all the reviews (which is just stupid that Amazon allows but apparently they do)
If you think about it there is basically no scalable way for Amazon to ensure a seller is providing the same product over time - and to all customers.
Random sampling can make sure a product matching the description arrives. But someone familiar with it would have to carefully compare over time. And that process doesn’t scale.
One thing Walmart does right is having “buyers” in charge of each department in the store. For example fishing - and they know all the gear and try it out. And they can walk into any store and audit and know if something is wrong.
I’m sure Amazon has responsible parties on paper - but the size and rate at which the catalog changes makes this a lower level of accountability.
I actually disagree. I think that people will pay more for higher quality software, but only if they know the software is higher quality.
It's great to say your software is higher quality, but the question I have is whether or not is is higher quality with the same or similar features, and second, whether the better quality is known to the customers.
It's the same way that I will pay hundreds of dollars for Jetbrains tools each year even though ostensibly VS Code has most of the same features, but the quality of the implementation greatly differs.
If a new company made their IDE better than jetbrains though, it'd be hard to get me to fork over money. Free trials and so on can help spread awareness.
That does not describe the current subscription-based software market, then, because we do try it, and we can always stop paying, transaction costs aside.
There are two costs to software: what you pay for it, and the time needed to learn how to use it. That's a big different to the original Lemon paper. You don't need to invest time in learning how to use a car, so the only cost to replacing it is the upfront cost of a new car. Worse "Time needed to learn it" understates it, because the cost replacing lemon software is often far more than just training. For example: replacing your accounting system, where you need to keep the data it has for 7 years as a tax record. Replacing a piece of software will typically cost many times the cost of the software itself.
If you look around, notice people still use Microsoft yet ransomware almost universally attacks Windows installations. This is despite everyone knowing Windows is a security nightmare courtesy of the Sony hack 2014: https://en.wikipedia.org/wiki/2014_Sony_Pictures_hack
Mind you, when I say "everyone", Microsoft's marketing is very good. A firm I worked lost $500k to a windows keyboard logger stealing banking credentials. They had virus scanners for firewalls installed of course, but they aren't a sure deference. As the technical lead for many years, I was asked about my opinion of what they could do. The answer is pretty simple: don't use Windows for banking. Buy an iPad of Android tablet, and do you safety critical stuff on there. The CEO didn't believe a tablet could be more secure than a several thousand dollar laptop when copy of Windows cost more than the tablet. Sigh.
So the answer to why don't people move away from poor quality subscription software is by the time they've figure out it's crap, the cost of moving isn't just the subscription. It's much larger than that.
> but only if they know the software is higher quality.
I assume all software is shit in some fashion because every single software license includes a clause that has "no fitness for any particular purpose" clause. Meaning, if your word processor doesn't process words, you can't sue them.
When we get consumer protection laws that require that software does what is says on the tin quality will start mattering.
This is a simple problem I have met and dealt with before.
The issue is the lack of synchronization between cancellation and not handling cancel failure.
All cancellations can fail because there is always a race when calling cancel() where the operation completes.
You have two options, synchronous cancel (block until we know if cancel succeded) or async cancel (callback or other notification).
This code simply handles the race incorrectly, no need to think too hard about this.
It may be that some io_uring operations cannot be cancelled, that is a linux limitation. I've also seen there is no async way to close sockets, which is another issue.
> You have two options, synchronous cancel (block until we know if cancel succeded) or async cancel (callback or other notification).
> This code simply handles the race incorrectly, no need to think too hard about this.
I still think the race is unnecessary. In the problematic code, there’s an operation (await accept) that needs special handling if it’s canceled. A linear type system would notice the lack of special handling and complain. But I would still solve it differently: make the sensitive operation impossible to cancel. “await accept()” can be canceled. Plain “accept” cannot. And there is no reason at all that this operation needs to be asynchronous or blocking!
(Even in Rust’s type system, one can build an “await ready_to_accept()” such that a subsequent accept is guaranteed to succeed, without races, by having ready_to_accept return a struct that implements Drop by putting the accepted socket back in the queue for someone else to accept. Or you can accept the race where you think you’re ready to accept but a different thread beat you to it and you don’t succeed.)
