No, it's that the average unpaid human doesn't care to read closely enough to provide signal to improve AI models. Not that they couldn't if they put in even the slightest amount of effort.
Firstly, paying is not at all the correct incentive for the desired outcome. When the incentive is payment, people will optimize for maximum payout not for the quality goals of the system.
Secondly, it doesn't fix stupidity. A participant who earnestly takes the quality goals of the system to heart instead of focusing on maximizing their take (thus, obviously stupid) will still make bad classifications due to that reason.
> Firstly, paying is not at all the correct incentive for the desired outcome. When the incentive is payment, people will optimize for maximum payout not for the quality goals of the system.
1. I would expect any paid arrangement to include a quality-control mechanism. With the possible exception of if it was designed from scratch by complete ignoramuses.
Same experience - I've had it fail at the same reasonably simple tasks I had opus 4 and sonnet 4.5 and sonnet 4 fail at when they aren't carefully guided and their work check and fixed...
I'd interpret this as a proposal for two new laws:
1. No non-invited display of paid messaging, period. If you go to a directory and ask for a list of people who paid to be part of that directory, it can show it. If you play a game, watch a movie, take the bus, or search a non-paid directory of sites they simply cannot show you things they were paid to show you. I think I'd call this making attention-theft a crime.
2. No payment for priority placement in paid directories. A paid directory has to charge the same (small, nominal) fee to everyone involved.
> No non-invited display of paid messaging, period. If you go to a directory and ask for a list of people who paid to be part of that directory, it can show it
How would you distinguish someone asking for the directory versus asking for something else with said directory (which are totally not ads, pinky promise) displayed alongside?
> I'd call this making attention-theft a crime
Someone standing up to make a political speech in a public square is now a criminal?
> A paid directory has to charge the same (small, nominal) fee to everyone involved
This is just ads with a uniform, "small, nominal" fee. Uniformity is objectively measurable. Smallness and nominalness is not. Presumably you mean these directories have to be published at cost?
> How would you distinguish someone asking for the directory versus asking for something else with said directory (which are totally not ads, pinky promise) displayed alongside?
You making sending the directory with something else unconditionally illegal, you either get the directory or the something else, not both at once. This is also necessary for the second part where you require everything in the directory paid the same amount.
> Someone standing up to make a political speech in a public square is now a criminal?
Only if they were paid to do so.
> This is just ads with a uniform, "small, nominal" fee. Uniformity is objectively measurable. Smallness and nominalness is not. Presumably you mean these directories have to be published at cost?
Personally I think uniform is more important than either small or nominal. It means that the person creating the directory can't be bribed to direct your attention to certain parts of the directory - i.e. steal it. Rather it's your choice to get the directory in the first place and pay attention to it, and everything inside it is at an equal playing level. I don't really care if it's at cost or if making directories is a profit making venture.
I'm not entirely sure what the original proposers intent was with the "small and nominal" part though. They might have wanted something more like "at cost".
Fixed fee highly favors big players. Not even sure why you want fixed fee. Either remove fee at all or charge higher for bigger players or charge based on sale rather than listing.
By the same I mean equal non-discriminatory pricing - not necessarily "fixed" rather than "by sale" or "by view" or what have you but that if it's "by view" then it's "x cents per view" with the same x everyone and if it's "3% of referred sale revenue" it's that for everyone.
The purpose being that because every item in any paid directory has paid the directory the same, the directory has no (monetary, at least) incentive to direct your attention towards sub-optimal listings. As an attempt at forcing the directory to sell itself as a useful directory of services, rather than as an object which sells its users attention to the highest bidder.
Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C.
> I know one C++ library that caches data but never evicts. Instead, the library author expects you to restart your app every 24 hours.
It may not be as simple as "that's our policy". I worked at one place (embedded C++ code, 2018) that simply reset the device every 24h because they never managed to track down all the leaks.
Finding memory leaks in C++ is a non-trivial and time-consuming task. It gets easier if your project doesn't use exceptions, but it's still very difficult.
Use Valgrind? Or are we talking projects that have become far too big for their own good, cause leaks aren't hard at all to find with the right tools and a bit of profiling... now crossing thread boundaries and weird dynamic programming tricks maybe, but thats a very different case and not really refecting on C++ itself, would likely trip up a GC lang as well.
Was not available for that specific device, but even with Valgrind and similar tools, you are still going to run into weird destructor issues with inheritance.
There are many possible combinations of virtual, non-virtual, base-class, derived-class, constructors and destructors; some of them will indeed cause a memory leak, and are allowed to by the standard.
In my experience that is usually the result of years and years of accumulation of shit code. The results is thousands of leaks. That makes detection of incremental leaks much more difficult. If you start with clean code and use ASAN or Valgrind then leak detection is not difficult.
> Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C.
What are you talking about? Every allocation must be checked at the point of allocation, which is "the default"
If you write non-idiomatically, then sure, in other languages you can jump through a couple of hoops and check every allocation, but that's not the default.
The default in C is to return an error when allocation fails.
The default in C++, Rust, etc is to throw an exception. The idiomatic way in C++, etc is to not handle that exception.
> Every allocation must be checked at the point of allocation, which is "the default"
C doesn't force you to check the allocation at all. The default behavior is to simply invoke undefined behavior the first time you use the returned allocation if it failed.
PS. The current default in rust to print something and then abort the program, not panic (i.e. not throw an exception). Though the standard library reserves the right to change that to a panic in the future.
> > C doesn't force you to check the allocation at all.
> No one ever claimed it did;
You specifically said
> Every allocation must be checked at the point of allocation
...
> the default is to check the returned value from memory allocations.
Default has a meaning, and it's what happens if you don't explicitly choose to do something else.
In libc - this is to invoke undefined behavior if the user uses the allocation.
In glib - the library that underpins half the linux desktop - this is to crash. This is an approach I've seen elsewhere as well to the point where I'm comfortable calling it "default" in the sense that people change their default behavior to it.
Nowhere that I've ever seen, in C, is it to make the user handle the error. I assume there are projects with santizers that do do that, I haven't worked on them, and they certainly don't make up the majority.
> : a selection made usually automatically or without active consideration
See that "without active consideration" there? The default usage of malloc includes, whether you want to acknowledge it or not, checking the returned value.
C doesn't have anything done automatically, so I am wondering why you would choose to think that by "default" one would mean that something automatically gets done.
I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code. Of course things do happen automatically all the time in C, like bumping the stack pointer (another case of unhandled OOM) and decrementing it after the fact. And pushing return addresses - and returning at the end of functions. And so on.
"Ubiquitous" is a different word than default, checking the return code of malloc isn't even that. As an example - I've been having some issues with pipewire recently (unrelated) and happen to know it uses an unwrapped malloc. And it doesn't reliably check the return code. For example: https://github.com/PipeWire/pipewire/blob/6ed964546586e809f7...
And again, this isn't cherry picked, this is just "the last popular open source C code base I've looked at". This is the common case in C. Either you wrap malloc to crash, or you just accept undefined behavior if malloc fails. It is the rare project that doesn't do one of those two.
> I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code.
Right. But this is what you initially responded to:
> You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C.
How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures?
> As an example - I've been having some issues with pipewire recently (unrelated) and happen to know it uses an unwrapped malloc.
Correct. That does not mean that the default way of writing allocation in C is anything other than what I said.
Do programmers make mistakes? Sure. But that's not what asked - what was asked is how do you handle memory errors gracefully, and I pointed out that, in idiomatic C, handling memory errors gracefully is the default way of handling memory errors.
> How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures?
I think you might want to reread the line you quoted directly above this,
That way of writing code, i.e. "write[ing] code that handles OOM conditions gracefully" "is the default [...] in C".
This is what I am saying is not the case. The default in C is undefined behavior (libc) or crashing (a significant fraction of projects allocator wrappers). Not "handling OOM gracefully" - i.e. handling OOM errors.
I have programmed in C plenty. Your assertion that unchecked allocations are few and far between is simply entirely incorrect. That they are treated as bugs when reported is incorrect in most C software.
For good reason. Most C software is not designed to run in a situation where malloc might fail.
I, unlike you, have provided evidence of this by pointing to major pieces of the linux desktop that do not do so.
because of OS-level overcommit, which is nearly always a good thing
It doesn't matter about the language you are writing in, because your OS can tell you that the allocation succeeded, but when you come to use it, only then do you find out that the memory isn't there.
Of course it matters, because you (the system admin) can tell your OS not to do that. Which is only helpful if your app knows how to handle the case. Most don't, so overcommit, in general, makes sense.
> You can't really on linux. There's no way to do sparse allocations then because when you turn off overcommit MAP_NORESERVE still reserves memory...
Sure, but ... what does that have to do with this thread? Using `mmap` is not the same as using `malloc` and friends.
If you turn off overcommit, malloc will return NULL on failure to allocate. If you specifically request mmap to ignore overcommit, and it does, why are you surprised?
> If you specifically request mmap to ignore overcommit, and it does, why are you surprised?
You misunderstand, you specifically request mmap to ignore overcommit, and it doesn't, not does.
What it has to do with this thread is it makes turning off overcommit on linux an exceptionally unpalatable option because it makes a lot of correct software incorrect in an unfixable manner.
As much as I'd like to claim the values [1] that Wikimedia (the foundation behind wikipedia) supports as a progressive - I think they're quite independent of the progressive/conservative spectrum.
well I guess if they claim it themselves. I heard Israel doesnt think its comitting genocide, that Russia is rightously doing gods work. Whom did i hear it from? well, themselves of course!
Your point is that... Wikpedia editors choice to have articles about sex acts is morally inconsistent with a choice not to have direct links to a site a based around harassing, stalking, doxing, etc that has been directly tied to multiple suicides?
I don't see the connection frankly.
PS. English Wikipedia also does not appear to have an "Anal Creampie" article, let alone one with an animation.
The picture clearly depicts--and believe it or not I never thought I'd write these words on the Hacker News internet forum sponsored by YCombinator--a vaginal creampie, not an anal one, nor does it seem to be, as you'd previously implied, animated.
I yield to the kernel to allow other threads that do some kind of background work to run. Do I want my application's async tasks to yield every 10ms? I assume that is what is being meant here.
Configurability: We absolutely plan to make the 10ms yield interval configurable (or opt-out) in the runtime settings. It is currently a default safety rail to prevent async starvation, not a hard constraint.
Concurrency Options: It is important to note that LOGOS has three distinct execution primitives, and this yield logic doesn't apply to all of them:
Simultaneously: (Parallel CPU): This compiles to rayon::join or dedicated std::threads. It does not use the cooperative yield check, allowing full blocking CPU usage on separate cores.
Attempt all: (Async Join) & Launch a task: (Green Threads): These compile to tokio async tasks. The cooperative yield is specifically here to prevent a single heavy async task from blocking the shared reactor loop.
So if you need raw, uninterrupted CPU cycles, you would use Simultaneously, and you wouldn't be forced to yield.
with cooperative scheduling, yes. This is indeed something missing from the Rust async ecosystem, tasks are meant to be IO-bound and if they become CPU-bound accidentally they will starve other tasks (async-std tried to fix this, but had some backlash due to overhead IIRC). Go actually puts a yield on every loop body (or used to), to prevent starvation. A 10ms thing will have negligible impact
Also: yielding to the kernel is very costly. Yielding to another task in your own thread is practically free in comparison
It's also widely acknowledged that elections in Russia are rigged, and yet the US was quite angry at Ukraine over Russia's (false, as it turned out) claim that Ukraine attacked Putin...
Because that wouldn't benefit Putin personally as much as the status quo? And he's the decision maker. Dictators routinely make decisions where they hurt their country to keep a much bigger slice of the pie for themselves...
reply