The concept of "landlords do nothing while collecting passive income, therefore not creating any value but instead are just exploiting that they own the land" would be correctly described as "rent-seeking behavior".
This equally applies to any investment income wouldn't it? Dividend, loan interest would all be classed as "unearned income" by a certain economic theory I won't name that keeps causing people suffering a century later. Don't do that.
Investment is generally considered profit-seeking behavior (i.e. not rent-seeking). Building an apartment and renting it out is clearly profit-seeking behavior, but if you were continuing to rent it out doing the bare minimum to keep it from falling over 40 years later, that would be pretty clearly rent-seeking.
From this, we can conclude that there must be some point after an investment is made where continuing to benefit from it transitions to rent-seeking behavior.
Predatory loans were maligned as "usury" long before "rent-seeking" or Scary Marxists came along. For good reason. They're bad for society and the economy writ large.
Classing all loans as usury help Europe back for a long time.
I guess you could class some rent as predatory as well, allowing others to use your property for a fee is not necessarily predatory (unless you're of "property is theft" kind).
Criticising landlords is fine, but words (and phrases) have actual meanings, and the term "rent seeking" has literally no place in a discussion about landlords.
I am well aware of what the phrase means, and I re-read the Wikipedia article to be sure. Maybe you read the use of the word in a different way than I did, but I helpfully included my precise interpretation of it in my comment to clarify the meaning.
> the term "rent seeking" has literally no place in a discussion about landlords
Having "literally no place" is certainly a strong choice of words, particularity as it was introduced in this thread as being a inaccurate label to apply to landlords.
Personally, I first learned about the term applying it to Feudalism, in which the (land)lords' only contribution was their ownership of the land. That example alone seems to pretty handily disprove your claim of "literally no place", in fact it's specifically cited in the Wikipedia article as the Georgist interpretation of economic rent.
Your own wiki link disagrees with you, most of the article uses landlordism as the base-level example. You've just discovered how "rent seeking" is used as a more broad term to describe many phenomena, but they're still describing them essentially in the metaphor of landlordism.
> So I am extremely sceptical of any claims of BSODs because of a game.
Generally speaking, I am too. That is unless there is kernel-level anticheat. In that case I believe it's fair to disregard all other epistemological processes and blame BSODs on the game out of principle
> In that case I believe it's fair to disregard all other epistemological processes and blame BSODs on the game out of principle
I am sorry but that is asinine and unscientific. You should blame BSODs on what is causing them. I don't like kernel anti-cheat but I will blame the actual cause of the issues, not assign blame on things which I don't approve of.
I am a long time Linux user and many of the people complaining about BSODs on Windows had a broken the OS in one way or another. Some were running weird stuff like 3rd party shell extensions that modify core DLLs, or they had installed every POS shovelware/shareware crap. That isn't Microsoft's fault if you start running an unsupported configuration of the OS.
Similarly. The YouTubers that were most vocal about HellDivers problems did basically no proper investigation other than saying "look it crashed", when it was quite clearly their broken hardware that was the issue. As previously stated their CPU had a burn mark on one of the pins, some AM5 had faults that caused this IIRC. So everything indicated hardware failure being the cause of the BSOD. They still blamed the game, probably because it got them more watch time.
During the same time period when people were complaining about BSODs, I didn't experience one. I was running the same build of the game as them and playing on the same difficulty and sometimes recording it via OBS (just like they were). What I didn't have was a AM5 motherboard, I have and older AM4 motherboard which doesn't have these problems.
Well, yes. I did say something to that effect. Blaming BSODs on invasive anti-cheat out of principle is a political position, not a scientific one.
> During the same time period when people were complaining about BSODs, I didn't experience one. I was running the same build of the game as them and playing on the same difficulty and sometimes recording it via OBS (just like they were). What I didn't have was a AM5 motherboard, I have and older AM4 motherboard which doesn't have these problems.
I understand what you're saying here, but anyone who does a substantial amount of systems programming could tell you that hardware-dependent behavior is evidence for a hardware problem, but does not necessarily rule out a software bug that only manifests on certain hardware. For example, newer hardware could expose a data race because one path is much faster. Alternatively, a subroutine implemented with new instructions could be incorrect.
Regardless, I don't doubt that this issue with Helldivers 2 was caused by (or at least surfaced by) certain hardware, but that does not change that given such an issue, I would presume the culprit is kernel anticheat until presented strong evidence to the contrary.
> Well, yes. I did say something to that effect. Blaming BSODs on invasive anti-cheat out of principle is a political position, not a scientific one.
When there are actual valid concerns about the anti-cheat, these will be ignored because of people that assigned blame to it when unwarranted. This is why making statements based on your ideology can be problematic.
> I understand what you're saying here, but anyone who does a substantial amount of systems programming could tell you that hardware-dependent behavior is evidence for a hardware problem, but does not necessarily rule out a software bug that only manifests on certain hardware. For example, newer hardware could expose a data race because one path is much faster. Alternatively, a subroutine implemented with new instructions could be incorrect.
People were claiming it was causing hardware damage which is extremely unlikely since both Intel, AMD and most hardware manufacturers have mechanisms which prevent this. This isn't some sort of opaque race condition.
> RI would presume the culprit is kernel anti-cheat until presented strong evidence to the contrary.
You should know that if you making assumptions without evidence that will often lead you astray.
I don't like kernel anti-cheat and would prefer for it not to exist, but making stupid statements based on ideology instead of evidence just makes you look silly.
The splash page on that website seems to be primarily AI-generated images. It looks cheap to say the least - such an obvious corner cut it's hard to have confidence in the product.
Still doesn't change the reality that few people know of this org exists, and fewer people still will associate it with the word "Handmade" in this context.
Alive2 does not handle loops; don't know what exactly it does by default, but changing the `shl i32 %and, 1` to `shl i32 %and, 2` has it still report the transformation as valid. You can add `--src-unroll=2` for it to check up to two loop iterations, which does catch such an error (and does still report the original as valid), but of course that's quite limited. (maybe the default is like `--src-unroll=1`?)
That seems super far fetched given that 37%[1] of the world's population does not have internet access. You could reasonably restrict further to populations that speak languages that are even passably represented in LLMs.
Even disregarding that, if you're making <3000 euros a year, I really don't think you'd be willing or able to spend that much money to let your computer gaslight you.
Ironically, I'm considering installing Bazzite alongside NixOS because it's proven to be nearly impossible to run SteamVR properly with how Steam is packaged
From what I’ve seen so far from people I know who run Valve Indexes, Linux SteamVR performance is pretty poor compared with Monado+OpenComposite. Hopefully this situation changes with the release of the Frame, in which case I (and likely others) will be revamping the SteamVR package and NixOS modules as Monado may not fully support it for some time.
Tl;dr: Run Monado w/ OpenComposite for the Index, it runs way better.
Dropping back here to say that I have been playing around with Monado + OpenComposite + WlxOverlay and while it's been plenty janky, it has actually usable performance when it works.
It’s more like adding a runtime handle to the struct.
Modulo that I’m not sure any langage with a sync/async split has an “async” runtime built entirely out of sync operations. So a library can’t take a runtime for a caller and get whatever implementation the caller decided to use.
> I’m not sure any langage with a sync/async split has an “async” runtime built entirely out of sync operations.
You get into hairy problems of definition, but you can definitely create an "async" runtime out of "sync" operations: implement an async runtime with calls to C. C doesn't have a concept of "async", and more or less all async runtime end up like this.
I've implemented Future (Rust) on a struct for a Windows operation based only on C calls into the OS. The struct maintains everything needed to know the state of the IO, and while I coupled the impl to the runtime for efficiency (I've written it too), it's not strictly necessary from memory.
> You get into hairy problems of definition, but you can definitely create an "async" runtime out of "sync" operations: implement an async runtime with calls to C. C doesn't have a concept of "async", and more or less all async runtime end up like this.
While C doesn't have async OS generally provide APIs which are non-blocking, and that is what async runtimes are implemented on top of.
By sync operations I mean implementing an "async" runtime entirely atop blocking operations, without bouncing them through any sort of worker threads or anything.
From my perspective, not having to deal with strings is one of the big benefits, but I believe the main argument is actually that it trivializes alpha equivalence.
As for renaming, if you're going to be looking at every binding anyway, changing most of them is no big deal (unless of course that entails doing many deep copies)
I used De Bruijn indices when attempting to prove correctness of a toy language of mine. It's an elegant solution, but I found them exceedingly difficult to reason about both intuitively and in proofs. That being said, I've yet to find a better system (that isn't just augmenting De Bruijn indices) for implementing any sort of lambda calculus.
The concept of "landlords do nothing while collecting passive income, therefore not creating any value but instead are just exploiting that they own the land" would be correctly described as "rent-seeking behavior".
reply