What would it take to run pytorch on the M4 GPU efficiently? Is there still a gap between what MPS offers and this driver (if properly hooked into Pytorch)?
is it supported to have it propose a command for approval rather than running autmatically? in the YT video it looks likw it ran the cpu temp command on its own
Yep he runs on its own when the command is non-destructive, like checking the CPU temperature, it does ask for permission if the command is potentially destructive. I agree it is so cool, it looks sci-fi :)
to his credit he did say he skimmed the paper, and it's honestly standard practice to do a first pass of skimming a paper before you'd go deeper into reading it anyways
The posted paper does use supervision to find alignments. I need to do a little more math to figure out how well the supervision critique applies, but I think it does. And although the current paper mentions DAS, it fails to discuss recent critiques of supervised abstraction methods (the various citations, including my own, that I provided).
Probably cerca 2014 as that's when AlexNet was released, demonstrating that neural networks could beat traditional ML models at image recognition tasks. I recall the researchers used Cuda to optimize their training setup.
AlexNet kicked off a new wave of research around neural networks by demonstrating they could be scaled well and trained on GPUs.
I thought the attack itself was version controlled via a tracked blob file used in a unit test. I believe the attack was performed by running the test suite (which modified the source code) and then compiling?
If that's the case, then anyone that ran the tests prior to building from source would be vulnerable if my understanding is right
It was in the uploaded tar.gz file to the releases page. The vulnerable code bypassed code review, at least for those distros that trusted the human made source snapshots more than git which was a poor choice.
In the context of microcontrollers and electronics, the likeliest intended meaning was shipping from China, South Korea, Taiwan and perhaps Japan, because that’s where the bulk of the fabs are.
> No, I'm sorry but who on earth installs random software from random strangers, without a single step of validating before giving it access...
Realistically most users?
It's already quite a technical barrier to run Arch Linux, and the knowledge to further know about/understand PKGBUILD can only comes with time and is yet another layer filtering people's ability to know how to even try to catch something malicious.
Now consider the layer of even experienced user that's in a bit of rush and doesn't have time to review the full diffs they're upgrading to.
Ralistically it's nearly statistically impossible that 100% of users would be able to all catch and block a given exploit themselves. A shared responsibility model of security [1] comes to mind, and while it's great for users to be active participants in their security, their action/awareness should be a last resort. I wouldn't blame the user.
> It's already quite a technical barrier to run Arch Linux
People are supposed to clear that barrier by studying the Arch Wiki and other technical materials so that they understand what they are doing, why they are doing it, and the risks involved.
When they install random software pushed by random people they know nothing about much less trust without even so much as a glance at the PKGBUILD, they're not overcoming any barriers, they're YOLOing their personal computers and hoping it turns out fine.
Taking the same example as above, if you have any nVidia card pascal or older, you have no other choice than using AUR for your driver; it was literally advertised as such on the Arch Linux home page :
>Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support:
> Install nvidia-580xx-dkms from the AUR
And those are packages very difficult to thoroughly review. At some point, just saying "users have been warned, too bad" might hold from a _legal_ point of view, but I feel like it is deflecting the blame a bit too much.
> doesn't have time to review the full diffs they're upgrading to.
Again, why are people expecting that you need to review the entire thing? You don't have to, you have to look at the download source (a github organization or a domain name or a cdn bucket) and look at what dependencies/other junk it pulls in. Usually this is 3-5 lines at max, and usually only the binary/source is taken from github/server, the rest is from official Arch repositories.
Of course it's unrealistic to expect users to review 100% of the code they run on their machine, that's why no one is expecting this, nor claiming that users should do this. But reviewing 3-5 lines when installing software from literal strangers on the internet, isn't so much to ask.
Many packages are _way_ more complex than 3-5 lines to review. To take an example (perhaps a bit extreme, but realistic as many nVidia users _have_ to install it), check nvidia-580xx-dkms
Every patch (which runs in kernel space) may of course contain backdoors, so you'd have to review them. Every install line in the PKGBUILD may be installing a malware.
Of course it is _possible_ to review all of it, but clearly not simple, even for a fairly technical user.
Sure, if you assume that every attack would be as glaring as the ones we've seen before, that makes it easier. But think of an attack at the level of the xz one and virtually no one would catch it.
Keeping discussion local is the key, as someone could acquire Wheesper one day and anything could happen at that point - just as browser extensions change hands and things can head south fast.
reply