I would argue that DRM free downloads are much closer to truly owning your games, since your "ownership" isn't tied to a media that will wear out or decay, and which likely cannot be backed up
In theory perhaps. In practice you can get physical media on second hand markets long after it is out of print but for digital media the publisher effectively controls availability (which also means they can keep the price high). There is effectively no right of first sale in practice for digital media which IMO makes it clearly not ownership.
In practice physical media also has a longer lifespan than the average persons handling of digital media. And wheter you are allowed to make backups of your physical media very much depends on your country.
The things that make C++ unforgiving is not the things that blow up at compile time. Those are trivial to deal with, comparatively, since you have the error right there. It's the things that compile, but then blow up in weird, and often unpredictable ways that make C++ unforgiving. Or to put it another way, it's the lack of undefined behavior in most situations that makes Python more forgiving.
Yes, Python may still blow up at runtime if you don't get it exactly right, but it'll blow up in very predictable ways: Off by one errors accessing arrays doesn't work some of the time, maybe, except on Tuesdays, instead you always get an IndexError. And some cases, like overflows/underflows, doesn't even blow up, instead you just get bigger/smaller numbers.
Type-hints also does a lot (but still not enough, IMO) to reduce the amount of blowing at runtime up that you might experience when working in Python. Though that obviously wont help with poorly written code, which is unlikely to have proper type hints
> The things that make C++ unforgiving is not the things that blow up at compile time. [...] It's the things that compile, but then blow up in weird, and often unpredictable ways that make C++ unforgiving.
While I agree that the Python standard library contains a lot of stuff, I am surprised that you have never heard of the unittest module. Sure, pytest is a very popular replacement, but its documentation frequently refers back to unittest, and the unittest module is also one of the top hits if you search for "python testing".
It has also been in there since Python 2.1, as far as I can tell [1], though the mock module is somewhat newer [2], but still quite old at this point. In all that time, have you never skimmed through the list of modules in the standard library? I'd recommend doing so once in a while, since a lot of the stuff in there is quite useful: https://docs.python.org/3/library/
It looks like 18 of the 30 issues listed in table 4 had already been fixed when that paper was released, and there is activity in most of the rest. One was recently flagged as being fixed by -Znext-solver, and another has the submitter write that it is fixed, but the issue is not closed. And that's before you consider the impact of the individual issues; how many of the remaining issues impact "real" code?
So I don't think it's fair to claim that "no-one cared".
I'm not so sure that the argument that some humans will survive would placate anyone who is worried about a catastrophic outcome from AI development. You could make the same argument for climate collapse or global nuclear war, but I also don't think that's gonna make anyone feel better about those scenarios
And since you should probably be running a modern CoW filesystem then you probably shouldn't be using swapfiles ... is the conclusion I arrived at anyway. Either install multiple times more RAM than you need and enable zswap or else set aside a swap partition as has always been done.
Swapfiles on BTRFS seem to work great if you allocate them early (with the command linked in your article) and put them in a different subvolume than the rest of your system.
BTRFS in general seems more I/O constrained than ext4 or xfs so it's probably still worse to put a swapfile on a BTRFS partition, but so far my systems are doing fine.
> BTRFS in general seems more I/O constrained than ext4 or xfs so it's probably still worse to put a swapfile on a BTRFS partition,
AFAIK, on Linux swap bypasses the filesystem. It asks the filesystem for the extents which are used by the swapfile, and does the I/O directly on the block device. This explains the many restrictions swapfiles have on btrfs (the file can't be copy-on-write, can't be mirrored, etc), but it also means the speed for a swapfile will be the same on btrfs as on ext4 or xfs (assuming a similar layout, that is, the file is not too fragmented; IIRC, the kernel prints the number of extents when you do a swapon, so you can see when it's too fragmented).
While a Steam account is supposed to be personal and non-transferable, it obviously isn't so in practice. So unless you provide additional information to prove that the owner is still the same person, then it is probably not sufficient to prove the current owner's age.
Looking at the "marketplace" G2A, about 15% of the Steam games sold there are sold in the form of accounts: Instead of a key or a gift, you get a login and a password for an account owning the game being sold. Making the account age a form of identification would no doubt also create a market for aged accounts without games.
reply