That's totally subjective. Windows takes the cake, since it ignores user agency when it wants. It's not your operating system. macOS is not as bad, but it does what Apple wants. If your use of computers fits within what Apple wants, then I suppose it's smooth sailing. Otherwise, there are endless distractions of fighting the OS to make it do what you want, and make it NOT do what you don't want it to do. Refreshingly, Linux is all yours. That power comes with responsibility, its greatest advantage and disadvantage.
Did you actually read the article? Multiple times, they talk about how they're just trying to find a smooth, comfortable workflow and don't need every detail perfect (at least initially).
The core initial setup here took about 2h30 from getting the laptop out of its packaging to being able to run and develop my main project's code within the environment I described.
Even if it takes you a full 2 days, that's literally 0.1% of your time over the 5-year life of a machine. Sharpen your axe before you go into the woods.
It’s likely that the models don’t need to get much smarter, but rather the ux for providing needed context needs to improve drastically. This is a problem that we’ve worked on for decades with humans, but only single digit years for AI. It will get better and that tediousness will lessen (but isn’t “alignment” always tedious?)
Yes, drastically. This means I'll have to wear Zuck's glasses I think, because the AI currently doesn't know what was discussed at the coffee machine or what management is planning to do with new features. It's like a speed typing goblin living in an isolated basement, always out of the loop.
Perhaps there are more qualifying statements that you meant to include? The certification and type rating requirements certainly differ between agencies, but in terms of raw number of flight hours it’s easy to find that this statement is false.
Unfortunately, no. Only `uv.lock` gets updated, but the dependencies in `pyproject.toml` are frozen at their original constraints.
What I want is, if my project depends on `package1==0.4.0` and there are new versions of package1, for uv to try install the newer version. and to do that for a) all the deps, simultaneously, b) without me explicitly stating the dependencies in the command line since they're already written in the pyproject.toml. an `uv refresh` of sorts
If you specify your constraints in pyproject.toml like this: `package1==0.4.0`; then that is the latest (and only) version satisfying your constraints. Not upgrading is expected behavior, because upgrading would violate constraints.
pyproject.toml’s dependency list specifies compatibility: we expect the program to run with versions that satisfy constraints.
If you want to specify an exact version as a validated configuration for a reproducible build with guaranteed functionality, well, that’s what the lock file is for.
In serious projects, I usually write that dependency section by hand so that I can specify the constraints that match my needs (e.g., what is the earliest version receiving security patches or the earliest version with the functionality I need?). In unserious projects, I’ll leave the constraints off entirely until a breakage is discovered in practice.
If `uv` is adding things with `==` constraints, that’s why upgrades are not occurring, but the solution is to relax the constraints to indicate where you are okay with upgrades happening.
> ... the solution is to relax the constraints to indicate where you are okay with upgrades happening.
Yeah, that's pretty much what I've been doing with my workaround script. And btw most of my projects are deeply unserious, and I do understand why one should not do that in any other scenario.
Why not depend on package1>=0.4.0 rather than specifying an explicit version? Then uv will upgrade it to the latest version.
pyproject.toml is meant to encode the actual constraints for when your app will function correctly, not hardcode exact versions, which is what the lockfile is for.
Because then you don't get to use the new features in 0.5.0.
Though I do think with Python in particular it's probably better to manually upgrade when needed, rather than opportunistically require the latest, because Python can't handle two versions of the same package in one venv.
I think this is a bad take because I don’t think the core issue of the platform was that it was based on web tech. The web tech basically worked fine. However the bugginess and challenging user interface (which is actually standard today) was a huge issue. The leadership decision that was needed wasn’t to kill the touchpad 49 days after launch, it was to kill it before launch.
Palm was a raccoon backed into a corner and it was using all its cleverness to get out. But it was willing to ship stuff that wasn’t ready and couldn’t be ready with the resources we had. HP had the resources. They could have taken a good start and given it the space to become great. Maybe.
webOS really needed low-level help. It took over forever to boot because (seemingly) nobody ever bothered to optimize even the low-hanging fruit. The webkit version used was slow and way behind standards and (as was the JS JIT). This was crippling for a web-first system.
That aside, the actual UX of webOS itself is still better than anything we have today and I liked my Touchpad despite the flaws.
Yeah, there's a lot of context there that isn't obvious from the outside and is behind my feelings that Palm just had too little too late. They shouldn't have been blindsided by the iPhone, but with that happening they really did the best they could. I'll make some brief points, but maybe I should write a blog post at some point.
- Kernel talent was never a problem at Palm. The ex-Palm folks lead or are technical leaders at many mainstream unix-ish OSes today, plus Fuschia (Android, Apple, Chrome, Fuschia)
- Boot times weren't the highest priority (though we did spend time on it since they were _so bad_). Battery life was. We didn't even do that well by launch date, but if Android hadn't mainlined their power-management framework before the Pre launched it would have been a joke. It was all hands on deck to get that stuff integrated in time for launch.
- The webOS platform was actually a thin UI layer on top of an Android-like Java-based platform that never launched. The Java-based OS wasn't derivative of Android (it predated Android), but it had no differentiating features with Android already live. Booting the Java runtime _and_ the JS engine and webkit was a lot.
- We knew we couldn't have Java running on this phone long-term, so tons of effort was going into nascent node services instead of Java ones. So all those were launching too.
- Your memory is incorrect on the JS jit, or mine is. My memory is that we were adopting the latest v8 engines as fast as they would come out (although not as fast as chrome) because they were the only ones that could keep the thing performant.
- Webkit was a mess, I'll give you that, but I'm surprised you noticed. Were you at palm too? Did you build apps? We generally provided UI components that were the way to build apps that, hopefully, allowed you to ignore the intricacies of exactly which webkit version you were on (at least to build an app).
Boot times for alternative kernels were a lot faster. I can't recall exactly (it's been years), but I seem to remember that there were some simple config settings in the bootloader that could cut boot times by a lot.
Was battery life the reason stock clocks were 1.2GHz instead of Qualcomm's recommended 1.5GHz? I used to run mine at 1.7-2GHz without any trouble (aside from battery life).
Maybe I'm wrong about the JIT, but as I recall, the JS benchmarks under webOS were significantly worse than Android (preware ultimately wasn't enough to keep up with things and LuneOS wasn't really viable without a lot of effort, so dual-booting to Android extended the life of the tablet for quite a while).
I wasn't at Palm, but it was noticeable during browsing (especially vs Android) and was extremely noticeable when it came to missing features. I did some EnyoJS work, but that was actually targeted at web apps rather than a webOS-specific app.
No, this is not how it works. They can still deduct the entire first year of salary even if the person is let go, as that salary is considered a capital expense. There is no incentive to keep the person on payroll because of this policy.
If you want to copy/paste, try taking the first example and asking the llm to refactor the code to run in a browser with no dependencies. It should be able to strip out the react stuff, or at least get it close and you can fix it from there.
I have tried that a bunch of times and a bunch of ways and did not get ffmpeg to work.
It might have to do with these two strange comments at the top:
// import { FFmpeg } from '@ffmpeg/ffmpeg';
// import { fetchFile, toBlobURL } from '@ffmpeg/util';
The rest of the code seems to assume "FFmpeg", "fetchFile" and "toBlobUrl" are somehow magically available. Neither me nor any LLM have yet managed to get these into existance.
OK to your credit your original request was to get this all working in a single html file. That is not possible with the easy paths documented on ffmpeg.
By default, the build relies on web workers which need to load their code from somewhere (and usually it has to be the same origin as the code making the request)
Through much mastery of JS build systems that I would not wish on my enemies, I bet you could get it working on localhost, but you’ll have a much better time of it if you set up vite or something for a local build. You can still easily do a “serverless” deploy with GitHub pages or similar but you do need an http server correctly configured for asset requests.
reply