Plus he outright stole government money, not even the pretense of some kind of pass-through contracting entity or something, just brazenly stole cash. And later went on a PR tour lying about being destitute to get Congress to give him a big pension (presidents didn’t get one before that; and he was doing quite alright financially without it).
Whatever the party affiliation, he was an actual thief and scam-artist at the public’s expense, so wouldn’t be a great example of some high water mark for public service.
Similar to the longer cycle times, I'm curious if there is the equivalent for HN. I like this site, https://www.daemonology.net/hn-daily/, but it's once-per-day. I'd at least like once-per-week.
Running Zotero (directly) is the big requirement for my next e-reader. Yeah, I can sync pdfs from my library with webdav or something else. But I want the full Zotero interface.
This is a very misleading statement; most of those physicians are using LLMs to transcribe notes from visits and/or for billing purposes (e.g., proper billing codes).
The problems isnt LLMs per se, it is the shift to trusting the output of the machine coupled with a decline in verifying that the output is reasonable. It's basically what your teachers warned you about with wikipedia in eight grade except applied to all areas of life, including medicine. Dictation is already high-stakes and LLMs do not automatically reduce that risk.
Here is an example. My provider sent me this note. I'm quoting verbatim here from my MyChart record:
"Your liver enzymes are high, I would like to order acetaminophen containing medication like Tylenol, I would like to order liver ultrasound I placed ultrasound order in the system, make an appointment for radiology, I would like you to get hepatitis panel lab work done, obtain blood work order, please schedule a well visit to get it done"
When I queried it, this is what I got back. It was a dictation error. You could almost hear the panic in the message:
"Sorry for wrong message earlier, I was dictated message- so could not realize that it was written to take Tylenol type of medicines- I DO NOT RECOMMEND ACETAMINOPHEN CONTAINING MEDICINE - LIKE TYLENOL AND ALCOHOL DUE TO ELEVATED LIVER ENZYMES."
Again the problem is not dictation, or LLMs. The problem is humans ignoring their responsibility to check the output of a machine.
> Again the problem is not dictation, or LLMs. The problem is humans ignoring their responsibility to check the output of a machine.
100%. Also, management.
I wish someone would go ahead and coin an AI version of Amdahl's law that states the work speedup from AI is dependent on amount of unverified AI output used.
Iow, if you 1:1 verified everything, there would be no time savings.
Ergo, you get management saying (1) we demand time savings due to AI & (2) we demand you fully check anything you use AI for.
End result? People skip (2) to hit (1).
Then management burns anyone at the stake whenever inevitable mistakes happen.
But that’s trivially false. There is an entire category of work where it is hard to come up with an answer and easy to verify the answer, which means that if you verified everything there would still be a large time savings.
But if you want to keep it in the realm of the everyday: you're asking if it is easier to write an email than to read it and check it covers what you wanted to say? Is it easier to search for something or to look at what's been found and say that it's what you were looking for?
Which is itself a problem as (in my partners evaluations as an optometrist), LLMs used for clinical notes has a bad habit of dropping clinically important information, and the biggest providers don’t give you a copy of the raw transcript or a recording
Which means she ends up spending just as much time as if she’d done it herself as it needs to be verified for accuracy every time…
OpenEvidence is specifically meant to help clinicians make evidence-based decisions in the diagnosis and treatment of patients, not note transcription.
Don’t spread lies. Several states also allow same day registration. And all of them set the ballot aside until the registration is verified. This means it isn’t even counted until verified.
And, no, I’m not going to “trust me, I’ve seen it before. [I just have no evidence.”
I'm not sure why that 2022 number is so much higher than the previous years listed.
I guess the stimulus checks and stock market movements during the pandemic brought the median and average closer together for a year? Regardless it didn't hold, it's back below 2007's level again today by any measure.
I mean kind of? I feel like other than allies of necessity (to counter other great powers) there isn't really a point in pretending to be friendly to countries that are different to us in practically every way.
Is the cultural difference really that big? Bigger, then say, the difference between NYC and rural Kansas?
Me and my generation (born in the 80s) of Western European have grown up admiring the US. Listening to your music, watching your movies, wearing your brands. And we still do, mostly.
The unease seems to have started some time after 9/11 though. European countries joined various wars, that turned out to be mostly a grab for control of oil states. (WMD anyone?)
And the US basically just stopped leading the way on international cooperation. Instead of cofounding the Internation Court of Justice, the US threatened to invade The Hague because of it. Instead of leading the way on averting climate change, having the tech, the global power and the money to do so, the US chose to block much of the initiative coming from elsewhere. And there've been many similar things.
So yeah, to me at least the US feels kind of like an old friend that's been derailed. By 9/11, perhaps.
I'd love to be proven wrong. I'd love to come back to visit the US more often in the future. But with this administration, I just won't risk it. And also.. I just don't want to, at the moment. :-/
Honestly fair enough. And for the record, I do not want the US and Europe to stop cooperating, I just think that we have lost much of the intrinsic cultural reasoning for allying in the first place. But at the same time, your statement about the urban/rural culture gap kind of refutes my point anyways. Either way, we still have much bigger fish to fry with Russia and China on the horizon, so we definitely have more in common with each other government wise compared to the rest of the world.
I'd say many people in the EU have similar views and ideas to about 2/3rds of the US (maybe I'm being generous on the US size), the half of the US that doesn't think the world is flat, that global warming might be happening, that following the rule of law is a good thing and we don't need to destroy the US to fix it.
Europe is more alike most Americans then you are to other Americans. Why pretend to be friendly with other states why not breakup. Cities in states should break apart from rural areas. We can all go back to tribal hunting groups.
Can someone explain a non-project based workflow/configuration for uv? I get creating a bespoke folder, repo, and uv venv for certain long-lived projects (like creating different apps?).
But most of my work, since I adopted conda 7ish years ago, involves using the same ML environment across any number of folders or even throw-away notebooks on the desktop, for instance. I’ll create the environment and sometimes add new packages, but rarely update it, unless I feel like a spring cleaning. And I like knowing that I have the same environment across all my machines, so I don’t have to think about if I’m running the same script or notebook on a different machine today.
The idea of a new environment for each of my related “projects” just doesn’t make sense to me. But, I’m open to learning a new workflow.
Addition: I don’t run other’s code, like pretrained models built with specific package requirements.
`uv` isn't great for that, I've been specifying and rebuilding my environments for each "project".
My one off notebook I'm going to set up to be similar to the scripts, will require some mods.
It does take up a lot more space, it is quite a bit faster.
However, you could use the workspace concept for this I believe, and have the dependencies for all the projects described in one root folder and then all sub-folders will use the environment.
But I mean, our use case is very different than yours, its not necessary to use uv.
FYI, for anyone else that stumbles upon this: I decided to do a quick check on PyTorch (the most problem-prone dependency I've had), and noticed that they recommending specifically no longer using conda—and have since last November.
I personally have a "sandbox" directory that I put one-off and prototype projects in. My rule is that git repos never go in any dir there. I can (and do) go in almost any time and rm anything older than 12 months.
In your case, I guess one thing you could do is have one git repo containing you most commonly-used dependencies and put your sub-projects as directories beneath that? Or even keep a branch for each sub-project?
One thing about `uv` is that dependency resolution is very fast, so updating your venv to switch between "projects" is probably no big deal.
> The idea of a new environment for each of my related “projects” just doesn’t make sense to me. But, I’m open to learning a new workflow.
First, let me try to make sense of it for you -
One of uv's big ideas is that it has a much better approach to caching downloaded packages, which lets it create those environments much more quickly. (I guess things like "written in Rust", parallelism etc. help, but as far as I can tell most of the work is stuff like hard-linking files, so it's still limited by system calls.) It also hard-links duplicates, so that you aren't wasting tons of space by having multiple environments with common dependencies.
A big part of the point of making separate environments is that you can track what each project is dependent on separately. In combination with Python ecosystem standards (like `pyproject.toml`, the inline script metadata described by https://peps.python.org/pep-0723/, the upcoming lock file standard in https://peps.python.org/pep-0751/, etc.) you become able to reproduce a minimal environment, automate that reproduction, and create an installable sharable package for the code (a "wheel", generally) which you can publish on PyPI - allowing others to install the code into an environment which is automatically updated to have the needed dependencies. Of course, none of this is new with `uv`, nor depends on it.
The installer and venv management tool I'm developing (https://github.com/zahlman/paper) is intended to address use cases like yours more directly. It isn't a workflow tool, but it's intended to make it easier to set up new venvs, install packages into venvs (and say which venv to install it into) and then you can just activate the venv you want normally.
(I'm thinking of having it maintain a mapping of symbolic names for the venvs it creates, and a command to look them up - so you could do things like "source `paper env-path foo`/bin/activate", or maybe put a thin wrapper around that. But I want to try very hard to avoid creating the impression of implementing any kind of integrated development tool - it's an integrated user tool, for setting up applications and libraries.)
That's my main use case not-yet-supported by uv. It should not be too difficult to add a feature or wrapper to uv so that it works like pew/virtualenvwrapper.
E.g. calling that wrapper uvv, something like
1. uvv new <venv-name> --python=... ...# venvs stored in a central location
2. uvv workon <venv-name> # now you are in the virtualenv
3. deactive # now you get out of the virtualenv
You could imagine additional features such as keeping a log of the installed packages inside the venv so that you could revert to arbitrary state, etc. as goodies given how much faster uv is.
So this is probably just me not understanding your use case, but surely this is a nearly identical workflow?
1. uv init <folder-name> # venv stored in folder-name/.venv
2. cd <folder-name> # running stuff with uv run will automatically pick up the venv
3. cd .. # now you get out of the virtualenv
The UX improvement would be to have a centralized managemend of the venv (centralized location, ability to list/rm/etc. from name instead of from path).
I've worked like you described for years and it mostly works. Although I've recently started to experiment with a new uv based workflow that looks like this:
To open a notebook I run (via an alias)
uv tool run jupyter lab
and then in the first cell of each notebook I have
!uv pip install my-dependcies
This takes care of all the venv management stuff and makes sure that I always have the dependencies I need for each notebook. Only been doing this for a few weeks, but so far so good.
Why not just copy your last env into the next dir? If you need to change any of the package versions, or add something specific, you can do that without risking any breakages in your last project(s). From what I understand uv has a global package cache so the disk usage shouldn't be crazy.
Yeah, this is how I feel too. A lot of the movement in Python packaging seems to be more in managing projects than managing packages or even environments. I tend to not want to think about a "project" until very late in the game, after I've already written a bunch of code. I don't want "make a project" to be something I'm required or even encouraged to do at the outset.
I have the opposite feeling, and that's why I like uv. I don't want to deal with "environments". When I run a Python project I want its PYTHONPATH to have whatever libraries its config file says it should have, and I don't want to have to worry about how they get there.
I set up a "sandbox" project as an early step of setting up a new PC.
Sadly for certain types of projects like GIS, ML, scientific computing, the dependencies tend to be mutually incompatible and I've learned the hard way to set up new projects for each separate task when using those packages. `uv init; uv add <dependencies>` is a small amount of work to avoid the headaches of Torch etc.
