There are many python packages that have other dependencies not managed by Python package management. The pain of figuring out what those implicit dependencies are is effectively removed for users when configured as a nix shell.
I've played around with it a little bit, but not enough to make any judgements on it. Something like devbox could be the sort of thing to make nix-shell accessible enough to see wider adoption.
There is definitely a learning investment in order to write good Nix expressions. But, if you write a good nix shell expression for your project, other devs should be able to jump in without really needing to understand those Nix expressions and still get a working environment.
Nix package manager's `nix-shell` is something I wish more people knew about. Nix is gaining some popularity, but people often think of using it has to be a really big commitment, like changing your Linux distro to NixOS or replacing your dotfiles with a Nix-based one (using the Nix package manager).
What I wish more people knew was that you don't need to do those things to get value from Nix. Create project specific dev shells that install the packages (at the correct versions) to work with that project can almost replace 90% of the docs for getting setup to work on a project.
I was using Nim for some of last years Advent of Code problems. I was mostly liking the syntax. Was a bit bother by the standard library have a snake case and camel case reference for each function (if I'm remember that correctly).
At the time nimble also required me to have NPM to install the the Nim package manager, Nimble. This was not ideal, but looking at [the nimble project install docs](https://github.com/nim-lang/nimble#installation) it seems like it is now package with the language.
Might try dusting it off for some AoC puzzles this year :)
It seems hard to imagine a board member that is involved in another tech business not having a conceivable conflict of interests. LLMs are on a course to disrupt pretty much all forms of knowledge work after all. Also big implications for hardware manufacturing and supply chains.
> Separately, a person familiar with the matter told The Verge that the board never received a letter about such a breakthrough and that the company’s research progress didn’t play a role in Altman’s sudden firing.
This isn't a refute. All we can say now is that there are conflicting sources. There isn't a way to determine which one is correct based on this.
So we have sources claiming there is a letter, and another source claiming there is not. Feel like some people would need to start going on the record before anything might reasonably be determined from this.
If they actually have AGI, then being at the helm of could represent more power than any amount of money could. Money just gives you access to human labour, which would suddenly be massively devalued for those with access to AGI.
Sam even recently alluded to something that could have been a reference to this. "Witnessing he veil of ignorance being pulled back" or something like that.
Elon was once "in possession" (influential investor and part of the board) of OpenAI, but it was since taken from him and he is evidently bitter about it.
Depends who gets onto the board. There are probably a lot of forces interested in ousting him now, so he'd need to do an amazing job vetting the new board members.
My guess is that he has less than a year, based on the my assumption that there will be constant pressure placed on the board to oust him.
In my immediate family I have 3 people that have taken multi-year periods away from work for health reasons. Two are mental health related and the other severe arthritis. 2 of those 3 will probably never work again for the rest of their lives.
I've worked with a contractor that went into a coma during covid. Nearly half a year in a coma, then rehab for many more months. Guy is working now, but not shape.
I don't know the stats, but I'd be surprised if long medical leaves are as rare as you think.
They are both just data being made hard to read, though. You could pretty much sum up the "risks" of encryption as: you want to read some data that someone else didn't want you to read. Which means you might fail to detect something, or fail to prove something as easily as if you could read that data. While we could enumerate specific examples of scenarios that fit the generalization, I think we are talking about something pretty narrow. It is also not really a new problem. Historically communication has been impossible to snoop on at scale, and encryption exists to maintain a semblance of past privacy in the present.
Lol not sure where I want to take this and it's getting pretty late...
There are many python packages that have other dependencies not managed by Python package management. The pain of figuring out what those implicit dependencies are is effectively removed for users when configured as a nix shell.