is this stackless?
anyway, that’s interesting! i was under the impression that they eschewed os threads because of the gil. i’ve learned something.
is this stackless?
anyway, that’s interesting! i was under the impression that they eschewed os threads because of the gil. i’ve learned something.
no, they’re just saying python is slow. even without the GIL python is not multithreaded. the thread
library doesn’t use OS threads so even a free-threaded runtime running “parallel” code is limited to one thread.
apparently not!
the thread library is aping the posix thread interface with python semantics.
nothing about any of those libraries dictates an OO approach.
yup, that’s true. most meaningful tasks are io-bound so “parallel” basically qualifies as “whatever allows multiple threads of execution to keep going”. if you’re doing numbercrunching in pythen without a proper library like pandas, that can parallelize your calculations, you’re doing it wrong.
python has way too many ways to do that. asyncio
, future
, thread
, multiprocessing
…
all programs are single threaded unless otherwise specified.
you are framing a fundamental issue with the system as a positive, which is confusingly common for crypto advocates.
i’m not interested in this conversation.
this reads like a mad rant.
first of all, bitcoin in its original form was meant to be used as a transaction log between banks. it was never meant to be a currency on its own, which can be seen in the fact that efforts in scaling up to more than a few million users consistently fail.
in practice, all cryptocurrencies result in a centralisation of power by default, whether they use proof of work or proof of stake, because they are built so that people with more resources outside the network can more easily get sway over the system. by either simply buying more hardware than anyone else (for pow) or pooling more of the limited resource (for pos) they can control the entire thing.
cryptocurrencies are a libertarian solution to the problem of capitalism, which is to say, a non-solution. the actual solution is to limit the use of financial incentives. i’d wager most people on lemmy would rather abolish currency altogether than go to crypto.
in the case of anubis one could argue that the goal is to save energy. if too much energy is being spent by crawlers they might be configured to auto-skip anubis-protected sites to save money.
also, i’d say the tech behind crypto is interesting but that it should never have been used in a monetary context. proof of stake doesn’t help there, since it also facilitates consolidation of capital.
okay, git using the same algorithm may have been a bad example. let’s go with video games then. the energy usage for the fraction of a second it takes for the anubis challenge-response dance to complete, even on phones, is literally nothing compared to playing minecraft for a minute.
if you’re mining, you do billions of cycles of sha256 calculations a second for hours every day. anubis does maybe 1000, once, if you’re unlucky. the method of “verification” is the wrong thing to be upset at, especially since it can be changed
the hashing part? it’s the same algo as here.
the functional difference is that this does it once. you could just as well accuse git of being a major contributor to global warming.
hash algorithms are useful. running billions of them to make monopoly money is not.
putting a Spartan in there is a low blow.
i mean, it’s also a security issue. sms is plaintext all the way from them to you.
hand-optimized SIMD-instructions probably
didn’t know donny was a forth programmer
eos is as close to vanilla arch as you can get while still being plug-and-play, basically. they have a remote for all their own stuff and if you remove that from pacman, you’re running normal arch. the main thing that’s different is they ship with common-sense configs and a graphical installer. no manjaro-like “kernel update service”.
it’s honestly perfectly stable. if you’re worried about things breaking when the kernel updates, run a LTS kernel.
the main thing is that the system end-users interact with is static. it’s a snapshot of all the weights of the “neurons” at a particular point in the training process. you can keep training from that snapshot for every conversation, but nobody does that live because the result wouldn’t be useful. it needs to be cleaned up first. so it learns nothing from you, but it could.