The advantage of American, anecdotally, is most of their planes in the routes I've been flying have the sideway bag bins that don't fill up, so I don't have to play the standing-in-line and boarding group game.
I solved this in 2019 with PyFlow, but no one used it, so I lost interest. It's an OSS tool written in rust that automatically and transparently manages python versions and venvs. You just setup a `pyproject.toml`, run `pyflow main.py` etc, and it just works. Installs and locks dependencies like Cargo, installs and runs the correct Python version for the project etc.
At the time, Poetry and Pipenv were the popular tools, but I found they were not sufficient; they did a good job abstracting dependencies, but not venvs and Python version.
My best guess: I'm bad at marketing, and gave up too soon. The feedback I received was generally "Why would I use this when Pip, Pipenv and Poetry work fine?". To me they didn't; they were a hassle due to not handling venvs and Py versions, but I didn't find many people to also have had the same problem.
Yea! I love the spirit. Compatibility in computing is consternating. If my code is compiled for CPU Arch X, the OS should just provide it with (using Rust terminology) standard library tools (networking, file system, and allocator etc) , de-conflict it with other programs, and get out of the way. The barriers between OSes, including between various linux dependencies feels like a problem we (idealistically thinking) shouldn't have.
Her primary thesis, if I understood correctly, is to clarify that none of the books with Feynman listed as the author were written by him, and that they were transcribed from interviews, lectures etc with editorializing. For example, by Ralph Leighton. Her secondary point was that she hates the "autobiographical" ones, and finds parts sexist, and thinks most of the stories are mostly false/lies/storytelling.
With that in mind, I think we'll agree it's not relevant here, as these seem to be handwritten notes by Feynman himself.
> and thinks most of the stories are mostly false/lies/storytelling.
It's been a while since I read "Surely, you must be joking" but I seem to recall Feynman himself makes the same point. He basically says something to the effect that some of his stories and bon mots are things he wished he said or did rather than stuff that actually happened.
The Cargo example at the top is striking. Whenever I publish a crate, and it blocks me until I write `--allow-dirty`, I am reminded that there is a conflation between Cargo/crates.io and Git that should not exist. I will write `--allow-dirty` because I think these are two separate functionalities that should not be coupled. Crates.io should not know about or care about my project's Git usage or lack thereof.
> The Cargo example at the top is striking. Whenever I publish a crate, and it blocks me until I write `--allow-dirty`, I am reminded that there is a conflation between Cargo/crates.io and Git that should not exist. I will write `--allow-dirty` because I think these are two separate functionalities that should not be coupled.
That's completely unrelated.
The --allow-dirty flag is to bypass a local safety check which prevents you from accidentally publishing a crate with changes which haven't been committed to your local git repository. It has no relation at all to the use of git for the index of packages.
> Crates.io should not know about or care about my project's Git usage or lack thereof.
There are good reasons to know or care. The first one, is to provide a link from the crates.io page to your canonical version control repository. The second one, is to add a file containing the original commit identifier (commit hash in case of git) which was used to generate the package, to simplify auditing that the contents of the package match what's on the version control repository (to help defend against supply chain attacks). Both are optional.
Those are great points, and reinforce the concept that there is conflation between Cargo and Git/commits. Commits and Cargo IMO should be separate concepts. Cargo should not be checking my Git history prior to publishing.
Indeed. I believe the parent commenter should pause and assess why people buy things, and what makes something desirable or a luxury good. We can start with mechanical watches: They are of poorer quality by every utilitarian measure than a crystal-oscillator driven one, but command much higher prices and status.
> They are of poorer quality by every utilitarian measure than a crystal-oscillator driven one, but command much higher prices and status.
But the value of the watch is not reducible to its value as a timekeeping device. (Even here, you could argue that the mechanical watch has more instrumental value as a timekeeping device where batteries are unavailable.)
A mechanical watch has greater value as a mechanical watch; it is mechanically more sophisticated, even if not electronically. It can have greater value as a product of superb craftsmanship or as an object of art. (And here, while tastes vary, I would reject the reduction of beauty to taste.)
> it is mechanically more sophisticated, even if not electronically. It can have greater value as a product of superb craftsmanship or as an object of art.
On any objective measurement axis a $15 Casio is more sophisticated than a $10_000 Rolex. I think what we value is the human scale of the Rolex, it operates and is manufactured at a scale we intuitively understand as humans, and we(or at least some people) value the sacrifices and effort needed to run at that scale.
Consider this, on your cheap Casio, the manufacturing tolerances are so tight and the parts are so complex and fine the only way to manufacture them are fully automated lines requiring a staggering capital investment of many millions, however because these lines have to be fully automated the economy of scale applies hard and the final product is very inexpensive.
All it takes to make a fine mechanical watch is a good watchmaker and several hundred thousand dollars of tooling.
One of my favorite watch repair videos is of a guy who rescues a smashed Casio, It has this fun combination of. it's a Casio, not worth even looking at. It is not designed to be serviced. Everything in it is super tiny, I mean watchmaking is already an exercise in frustration with how small everything is, which is why I enjoy watching them work but I have no real desire to do it myself, however in this Casio they were absurdly small. But this madlad did it. What a heroic fix.
There are various kinds of value and it is a mistake to confuse them or to reduce them to just one kind.
W.r.t. your imputed definition, there is a sense in which everything is irreplaceable, because the identity of two things that are otherwise entirely identical is never the same; that X is never this X.
But I was not making the claim that the value of something is its “ability be itself”. I was claiming that a thing x of kind A is more valuable as an A than a thing y of kind B as an A, where A is not B. This is trivially true.
Consider the utilitarian value of a pencil as an object for writing and consider a particle accelerator. It should be clear that the utility of a pencil as a writing instrument is greater than the utility of a particle accelerator as a writing instrument. The particle accelerator is more complex as a piece of technology, but so what? It has no value as an instrument for writing down your grocery list.
In any case, I was not proposing a comprehensive basis for a theory of value on this notion alone, so I’m not sure how you managed to selectively read that into my comment. It was only listed as one way in which one could say that a mechanical watch is more valuable than a Casio.
That is true, but that doesn't mean Nvidia is not engaging in engineering to intentionally kneecap competition. Triton and other languages like that are a huge threat and CUtile is a means to combat that threat and prevent a hardware abstraction layer.
Hundreds of thousands of developers with access to a global communication network were not stopped by AMD. Why act like dependents or wait for some bright star of consensus unless the intent is really about getting the work for free?
We don't have to wait for singular companies or foundations to fix ecosystem problems. Only the means of coordination are needed. https://prizeforge.com isn't there yet, but it is already capable of bootstrapping its own development. Matching funds, joining the team, or contributing on MuTate will all make the ball pick up speed faster.
>We don't have to wait for singular companies or foundations to fix ecosystem problems.
Geohot has been working on this for about a year, and every roadblock he's encountered he has had to damn near pester Lisa Su about getting drivers fixed. If you want the CUDA replacement that would work on AMD, you need to wait on AMD. If there is a bug in the AMD microcode, you are effectively "stopped by AMD".
We have to platform and organize people, not rely on lone individuals. If there is a deep well of aligned interest, that interest needs a way to represent itself so that AMD has something to talk to, on a similar footing as a B2B relationship. When you work with other companies with hundreds and thousands of employees, it's natural that emails from individuals get drowned out or misunderstood as circulated around.
You can see in his table he calls out his AMD system as having "Good" GPU support, vs. "Great" for nvidia. So, yes, I would argue he is doing the work to platform and organize people, on a professional level to sell AMD systems in a sustainable manner - everything you claim that needs to be done and he is still bottlenecked by AMD.
A single early-stage company is not ecosystem-scale organization. It is instead the legacy benchmark to beat. This is what we do today because the best tools in our toolbox are a corporation or a foundation.
Whether AMD stands to benefit from doing more or less, we are likely in agreement that Tinygrad is a small fraction of the exposed interest and that if AMD were in conversation with a more organized, larger fraction of that interest, that AMD would do more.
I'm not defending AMD doing less. I am insisting that ecosystems can do more and that the only reason they don't is because we didn't properly analyze the problems or develop the tools.
Element web and PC applications are still, in 2025, a mess. I have heard you have to use it on Mobile using the ElementX.
No new complaints: The standard it badgers you to authenticate, then doesn't let you due to errors. Slow to load messages, inconsistent whether edits will show or not, inits channels to an arbitrary time in the past, then you have to click the arrow a few times and wait to get to the latest, the page won't load on mobile, etc.
Yup, work has been going into refactoring Element Web into MVVM components so we can switch out the ancient matrix-js-sdk underpinnings with the same matrix-rust-sdk that is a day-and-night improvement. https://element.io/blog/element-x-web-a-glimpse-into-the-fut... gives an idea.
I don't know if this is still true, or related, but that area used to be (Circa 10-30 years ago) very highly prone to power outages. The reason was lots of old trees near the lines that would inevitably fall; blackouts in local areas were common due to this.
That's an interesting data point, but I don't think it's relevant. The datacenters themselves are designed with a high level of power reliability and can island themselves if needed.
reply