Does R515 belong to the same numbering scheme as 510.60.02 (this is my current installed driver version)?

Is this connected to the recent ransomware incident? Wasn't opensourcing the drivers one of the demands? :thinking_face:

Woah. What? Can you add a link?

https://arstechnica.com/information-technology/2022/03/cybercriminals-who-breached-nvidia-issue-one-of-the-most-unusual-demands-ever/

Yeah, I found it too: https://blog.malwarebytes.com/ransomware/2022/03/nvidia-the-ransomware-breach-with-some-plot-twists/

from what i've seen of insiders on twitter, it has nothing to do with the security breach, and the security breach actually made this harder

from what i've heard, this was a long effort and has a lot to do with the fact that nvidia has moved a lot of functionality to firmware on the chip itself rather than have it live inside kernel modules

https://twitter.com/never_released/status/1524482785800601602

Nice summary of where things are and where they're heading. Thanks @UK0810AQ2 The next LTS is still 18 months away so it'll be interesting to see what gets completely baked in by that point (I can see us using the Loom features quite a bit but I'm not sure yet whether that alone will tempt us to migrate to a non-LTS version for production).

I'm just excited to see what people will build with loom

Everything pertaining to Clojure's core wrt Valhalla is far off

I'm looking forward to core.async having a fiber function on top of thread and go. That just runs over an unbounded green thread pool.

And in standard Clojure you can just use that for everything

Also a loom backed future and all that

Would you even need channels at this point? Won't blocking queues be enough? The only question mark I have here is regarding alts

The channel-as-synchronization-point model seems useful for coordination, in and of itself. Perhaps the real Q is: would you even need core.async at that point? Wouldn't you just write code in a different style? What would coordination/synchronization between fibers look like though?

That's what I meant, you could use queues instead of channels and get all the synchronization between fibers you need The model is still good, I just wonder if you'll need all the associated implementation overhead

Do you queues offer equivalents for all the core.async channel operations: take!, put!, offer!, poll!, and especially, alts!?

Alts is the missing bit, I think, still, implementing it could be much simpler. Ron Pressler mentioned they want to implement channels down the line

alts! is usually the hard part and one of the reasons I think core.async better supports difficult async code.

Since core.async is based on CSP, I'm not sure loom makes it less relevant. My intuition is that it it just provides more options for core.async to take advantage of since it can bridge OS threads, loom threads, and go threads.

Lots of really cool stuff happening in jvm land though!

If you find core.async useful with thread today over using threads directly, or using future, or blocking queues, than you'll find it useful with fibers as well

Personally, I just think core.async offers really nice ergonomics for moving data between threads and coordinating their use of it. Transducers on channels for example, alts, mix, mults, pipeline, etc.

Maybe someone builds an even nicer API over fibers, but I think the change to support fibers to core.async is minimal, and lots of people already know how to use core.async which is nice.

I would also find it more portable arguably, since core.async can also work where you don't have fibers, or you don't have threads, etc.

Valhalla and the promise of more performance and less memory that maybe it could bring to Clojure is the one I'm most excited though. The others all have satisfiable workarounds for me right now, but no way to workaround Valhalla.

historically I've used xchat aqua and limechat

I used Colloquy for years and always liked that. Used to be free, now it seems to be $1.99 (still cheap). I also used Adium for a long time. But I gave up on IRC a few years back so I don't know how those are, feature-wise, these days...

I use a matrix client (element) for irc and this slack. Free ZNC too

If you're using Emacs, there's always ERC

I completely forgot that I have irccloud that I can use and just avoid the whole client issue