I can only speak for Flatpak, but I found its packaging workflow and restricted runtime terrible to work with. Lots of undocumented/hard to find behaviour and very painful to integrate with existing package managers (e.g. vcpkg).
Yeah, flatpak has some good ideas, and they're even mostly well executed, but once you start trying to build your own flatpaks or look under the hood there's a lot of "magic". (Examples: Where do runtimes come from? I couldn't find any docs other than a note that says to not worry about it because you should never ever try to make your own, and I couldn't even figure out the git repos that appear to create the official ones. How do you build software? Well, mostly you plug it into the existing buildsystems and hope that works, though I mostly resorted to `buildsystem: simple` and doing it by hand.) For bonus points, I'm pretty sure 1. flatpaks are actually pretty conceptually simple; the whole base is in /usr and the whole app is in /app and that's it, and 2. the whole thing could have been a thin wrapper over docker/podman like x11docker taken in a slightly different direction.
I wasn't directly involved, but the company I worked for has created its own set of runtimes too and I haven't heard any excessive complaints on internal chats, so I don't think it's as arcane as you make it sound either.
Well flatpak was started pre oci. But its core is is just ostree + bwrap. Bwrap does the sandboxing and ostree handles the storage and mount. Now there still a few more stuff but these 2 are the equivalent to docker. Bwrap is also used for steam and some other sandboxing usecases. Ostree is the core of fedora silverblue. Runtimes are special distros in a way, but since the official one are pretty building everything from source so the repos tend to be messy with buildscripts for everything.
You can build your own flatpak by wrapping bwrap, because that is what Flatpak does. Flatpak seems to have some "convenience things" like the various *-SDK packages, but I don't know how much convenience that provides.
The flatpak ecosystem is problematic in that most packages are granted too much rights by default.
I also think Qt/QML is a very underrated technology. I have been developing a handwritten notes for Linux/Windows using Qt Quick for quite some time [0]. The experience has been a mixed bag though.
I've encountered tons of bugs (many of them still unfixed) that I had to find very ugly workarounds for.
Also, while a declarative style UI language can have a lot of benefits, it does also have a lot of limitations. For example, in my application I required a (infinite) canvas to rendering the ink strokes, which would be a perfect job for QGraphicsView, but there is no equivalent in Qt Quick. So I had to roll out my own component (which uses Skia under the hood), but that was quite painful. Since Qt 6, the Qt Quick scenegraph is rendered with a custom RHI backend (abstracting over Vulkan, Metal, OpenGL and DirectX) which I had a lot of trouble integrating with third party engines (I really wish they had a WebGPU backend).
Qt Widgets is fantastic, but now dated since it has not been updated for the modern world. Plus it is C++, which a lot of devs dislike.
QML feels like a refresh with great ideas, bringing declarative UI and reactive programming. Where it falls short for me is it does not have feature parity with Qt Widgets, so you end up having to roll up your own components, wasting a ton of time. Dealing with layouts in QML is also an exercise in frustration.
Not having an extra language to deal with and so many features being just a flag away is why I decided to go with QtWidgets for the GUI of a project I am working on at work. And it is so nice to use despite being very old. For the graphically intensive parts I am just using Vulkan. I understand this might not be enough for all types of GUIs though and just wish QtWidgets had some sort of GPU acceleration.
QML is a great language to make GUIs. A few years ago I tried XAML, and it honestly kind of sucked in comparison (the verbosity alone made it painful to work with). I haven't tried Slint UI, but supposedly their DSL is even better since it fully compiles to native Rust code.
I found QML to be a terrible language for making GUIs. I really tried with it. But it just felt so hacky and unfinished. A couple of examples (from like 10 years ago so forgive me if I got some of the details a bit wrong):
1. Child components can magically refer to variables in their parents. This is basic encapsulation 101. The only other language I know of that allows that is SystemVerilog and that's from an era where people didn't know better (especially hardware guys).
2. You can create custom widgets... but they can't display text! There's a class called something like QmlSceneGraphTextNode that is the way that all the provided widgets display text but it's private. I guess they might have fixed this eventually but it stayed private for the ~5 years I tried to use it. They wanted me to just use Label widgets in QML land which sucks.
It also felt like there was a pretty huge impedance mismatch between QML and C++ due to its use of Javascript. E.g. stuff like using 64-bit integers. That reminds me:
3. It uses Javascript.
4. I never found a good way to use dialogs. They seem to push you towards having all possible dialogs exist all the time and just showing and hiding them, which is kind of crazy.
I don't think the idea of a GUI DSL is fundamentally bad, but QML is certainly a pretty miserable implementation. Hopefully the Slint guys have learned all of these lessons.
It uses JS like the early web did: for little pieces of logic here and there. It isn't based or structured around, and certainly not made of, JS. It's fine. I don't like JS neither, but I do like QML.
Also, feel free to use QtWidgets for desktop apps, it's IMO the better technology for that unless your data is simple and you want it to look like a typical touch UI for some reason.
YouTube's educational value can be unmatched, but it doesn't follow that 99% of time spent on YouTube is educational or even useful.
I'd bet the ratio of time I have spent legit learning something useful vs just using it as distraction/entertainment ("educational" channels are often just entertainment for nerds like us)/background, it has to be something like 1000 to 1. I wouldn't need to replace the 999 at all. I guess I would read books a bit more, probably get a lot more done on personal projects, go out a bit more etc.
Not clear at all my life would be worse off except in that pinch where I need to know how to disassemble & fix the thing, right now.
IMO if youtube was an actual paid service, I would also expect a lot of the advertiser driven demonitization actions to go away when your in paid mode, but it isn't so I still miss out on a lot of potentially interesting topics or things that could be talked about, but are not, due to the chilling effects of the demonitization & deboosting police.
Creators avoid making their videos tagged as such because it significantly reduces their reach and promotion by the algorithm. So it doesn't matter if you still get paid by premium views, the chilling effect still exists.
I don't know what I would replace YouTube with, because YouTube is free so I have never needed to consider alternatives.
But for the most part - probably nothing. For everything else, it'd just be either some other free option, or like going back to the internet of the early 2000s, which would be good and bad in its own ways.
Can you elaborate on your learning journey? How did you separate out the worthless content from quality education programs? Very few Unis post lectures anymore, so it’s all hit or miss for me.
I have completely disabled the history feature, so when I navigate to the homepage there's no "recommended" content. I rely on search exclusively to find what I need. Also I don't have the YouTube app installed, if I need it I just use the browser. This helps minimising the distractions a lot.
As for content, it depends what you're looking for. For me, I'm mostly into maths and physics and there are so many channels and lecture series that were immensely helpful. For example, I recently went through this playlist on Lie Groups [0].
I did learn how to diagnose car problems and how to fix them. these were relatively minor tasks - replace the spark plugs and replace light bulbs. Also Subaru Forester has a problem if the battery gets disconnected too long-I found out about that and what to do about it on YouTube. I also learned how to cook some foods.
That being said, lately YT has way too many ads for my liking; thus I am using Reddit more and more for these things.
The vast majority of FLOSS projects are underfunded and we have far more cases of projects that had to shutdown because they lacked funding than projects that were successfully able to fund themselves.
Survivor bias backed examples are not a good argument.
Very interesting experiment. I've been working on a handwriting application [0] for the past couple of years and incorporating the ability to take a picture to convert it into digital ink would be really nice.
I suppose, but you’d be limited to a small number of supported languages, whereas bazel works for just about anything. Like my sibling commenter noted, you only need it if you really need it.
> I don't want to build a complete UI system from the ground up, but there are certain points where I'd like to be able to customize things, like adding new widgets and having some way to render 2D things without needing a graphics API surface -- think HTML canvas. I feel like ImGui does a pretty good job here, giving you drawing primitives.
Yes, Qt may not be super friendly with this. However, it is perfectly possible.
Qt lets you integrate an "external canvas" that you can render with your favourite graphics API (e.g. OpenGL) and integrate it in the Qt Quick scene (or widgets if you prefer). For example, I did this with my notetataking application, Scrivano [1], for handwriting, where the main canvas is a separate OpenGL view that renders content using Skia, while the rest of the UI is standard Qt Quick.
