This weekend I gave Zed another chance, this time it didn’t make me uninstall it after one hour or so. It’s much more polished, there are a few wrinkles but overall it’s finally pleasant to use. I’m actually surprised how my muscle memory from VSCode is of use, kudos to devs for making the transition easier instead of reinventing the wheel. I hope to eventually get rid of VSCode, this AI everywhere at all costs is turning the editor (that wanted to be an IDE) into something (most?) users don’t want or need.
After many years playing on Linux, first struggling with Wine then with Proton when it came out, had to install Windows on my gaming pc. I mostly play Overwatch 2 with friends on my very short free time, thanks to a Steam bug (https://github.com/ValveSoftware/steam-for-linux/issues/1028...), on every single evening I had to wait forever (seriously, 15+ min) for shaders to compile or start the game immediately but suffer on every match beginning (different map) with stuttering.
That’s a deal breaker for me, I tried a fresh Bazzite install (from Arch) before giving up, exact same issue.
I wish Valve comes around one day and fixes that, I’ll kick Windows out of life in a heartbeat.
How old is your GPU/does it/the driver support async shader compilation? I've turned off shader pre-comp like two years ago because of this bug, never had any problems/lags with any games.
RTX 3060 mobile, nvidia blobs, default settings from the distro. Indeed, I disabled the shader cache at some point, for most single player games it was a good workaround, that was not the case for OW2 for some reason.
I play OW2 on Linux with Steam + Proton and I was having this issue a while back but somehow fixed it. I think it was by increasing the shader cache size! Happy to find the exact instructions that I did to fix it once I’m back on that PC.
If handbrake scares them, don’t you dare to demonstrate how to use ffmpeg. I remember when I used handbrake for the first time and thought “wow, it’s much more convenient than struggling with ffmpeg”.
I think GUI tools lend themselves more to being able to discover functionality intuitively without needing to look anything up or read a manual, and especially so if you’re coming back to a task you haven’t done in a while. With CLI I constantly have to google or ask an LLM about commands I’ve done many times, whereas with a gui if I do it once I can more easily find my way the next time. Anyway both have their place
> I think GUI tools lend themselves more to being able to discover functionality intuitively without needing to look anything up or read a manual
Well, there are different issues.
Reading a manual is the best you can do, theoretically. But Linux CLI tools have terrible manuals.
I read over the ssh man page multiple times looking for functionality that was available. But the man page failed to make that clear. I had to learn about it from random tutorials instead.
I've been reading lvm documentation recently and it shows some bizarre patterns. Stuff like "for more on this see [related man page]", where [related man page] doesn't have any "more on this". Or, here's what happens if you try to get CLI help:
1. You say `pvs --help`, and get a summary of what flags you can provide to the tool. The big one is -o, documented as `[ -o|--options String ]`. The String defines the information you want. All you have to do is provide the right "options" and you're good. What are they? Well, the --help output ends with this: "Use --longhelp to show all options and advanced commands."
2. Invoke --longhelp and you get nothing about options or advanced commands, although you do get some documentation about the syntax of referring to volumes.
3. Check the man page, and the options aren't there either. Buried inside the documentation for -o is the following sentence: "Use -o help to view the list of all available fields."
4. Back to the command line. `pvs -o help` actually will provide the relevant documentation.
Reading a manual would be fine... if it actually contained the information it was supposed to, arranged in some kind of logically-organized structure. Instead, information on any given topic is spread out across several different types of documentation, with broken cross-references and suggestions that you should try doing the wrong thing.
I'm picking on man pages here, but actually Microsoft's official documentation for their various .NET stuff has the same problem at least as badly.
We're going full-circle, because LLMs are amazing for producing just the right incantation of arcane command-line tools. I was struggling to decrypt a file the other day and it whipped me up exactly the right openssl command to get it done.
From which I was able to then say, "Can I have the equivalent source code" and it did that too, from which I was able to spot my mistake in my original attempt. ( The KDF was using md5 not sha ).
I'm willing to bet that LLMs are also just as good at coming up with the right ffmpeg or imagemagick commands with just a vague notion of what is wanted.
> I'm willing to bet that LLMs are also just as good at coming up with the right ffmpeg or imagemagick commands with just a vague notion of what is wanted.
they are. ive only used ffmpeg via llm, and its easy to get the LLM to make the right incantation as part of a multi-step workflow.
my own lack of understanding of video formats is still a problem, but getting ffmeg to do the right thing only takes a vague notion
One of the things LLM shines.
For double checking the command explanations, I ask commands to grep the sections from manual instead of relying LLM output blindly.
Come on. "type ffmpeg, then hyphen i then the input filename then the output filename". I would've understood this when I was 8. Because I was super smart? No, because I was making a genuine effort.
The portion you've overlooked is there is an entire population of users out there who have never seen, nor used, a command line, and telling them to "just type this out" ignores all the background command line knowledge necessary to successfully "just type this out":
1) They have to know how to get to a command line somewhere/how (most of this group of users would be stymied right here and get no further along);
2) They now have to change the current directory of their CLI that they did get open to the location in their filesystem where the video is actually stored (for the tiny sliver who get past #1 above, this will stymie most of them, as they have no idea exactly where on disk their "Downloads" [or other meta-directory item] is actually located);
3) For the very few who actually get to this step, unless they already have ffmpeg installed on their PATH, they will get a command not found error after typing the command, ending their progress unless they now go and install ffmpeg;
4) For the very very few who would make it here, almost all of them will now have to accurately type out every character in "a-really_big_filename with spaces .mov", as they will not know anything about filename completion to let the shell do this for them. And if the filename does have spaces, and many will, they now need to somehow know 4a) that they have to escape the spaces and 4b) how to go about escaping the spaces, or they will instead get some ffmpeg error (hopefully just 'file not found', but with the extra parameters that unescaped spaces will create, it might just be a variant of "unknown option switch" error instead).
They are using text inputs, where you press enter to send stuff daily. Most of the hurdle is just overcoming the preconception that at black in put window means hard mode.
They can right-click in the folder view of their OS file viewer. On Windows they can also just type the command into the path bar.
When you tell them the command, you could also just install it. Also you could just tell them to type the name of the app 'ffmpeg' into the OS store and press install. They do this on their phone all the time.
Well, you're cheating a bit here. You're basically assuming the user has never seen a text prompt before. Which is a good assumption.
But, if we assume the user has never seen a graphical application before, then likely all GUI tools will be useless too. What is clicking? What does this X do? What's a desktop again? I don't understand, why do I need 1 million pixels to change an mp3 to an avi? What does that window looking thing in the corner do? Oh no, I pressed the little rectangle at the top right and now it's gone, it disappeared. No not the one with the X, I think it was the other one.
Pretty much all computer use secretly relied on hundreds if not thousands of completely arbitrary decisions and functionality you just have to know. Of all of that, CLI tools rely on some of the least amount of assumptions by their nature - they're low fidelity, forced to be simple.
The difference is a lot of "computer education" (as opposed to computing education most in this forum have) has happened with GUIs. "Simple" CLI tools doesn't mean they're understandable or even user-friendly.
Heck, even computing education (and the profession even!) has been propped up by GUIs. After my first year in CS, there were like only three to five of us in a section of forty to fifty who could compile Java from the command line, who would dare edit PATH variables. I'm pretty sure that number didn't improve by much when we graduated. A lot of professionals wouldn't touch a CLI either. I'm not saying they are bad programmers but fact of the matter is there are competent professional programmers who pretty much just expect a working machine handed to them by IT and then expect DevOps to fix Jenkins when it's borked out.
Remember: HN isn't all programmers. There are more out there.
> But, if we assume the user has never seen a graphical application before, then likely all GUI tools will be useless too.
We don't even need to assume, we just need to look at history. GUIs came with a huge amount of educational campaigning behind it, be it corporate (i.e., ads/training programs that teach users how to use their products) or even government campaigns (i.e., computer literacy classes, computer curriculum integrated at school). That's of course followed by man-years upon man-years of usability studies and the bigger vendors keeping consistent GUI metaphors across their products.
Before all of this, users did ask the questions that you enumerated and certain demographics still do to this day.
> Of all of that, CLI tools rely on some of the least amount of assumptions by their nature - they're low fidelity, forced to be simple.
"Everything should be made simple, but not simpler." Has it occurred to you that maybe CLI tools assume too little?
I agree with pretty much all of this, I think where the divergence is what to do about it. IMO, tool wise, nothing - this is an education issue.
And onto your point about CLI tools often making too little assumptions: this is 100% true, and also a superpower. There's a reason that a tool like ffmpeg can spawn 1000 GUI programs from it, each with their own draws. It's a generic tool, not necessarily an application. Many CLI programs are like this.
That can raise the complexity but it's a tradeoff. Many GUIs are too "happy path" centralized, and that happy path is different for different people, so they become cumbersome and unintuitive in too many use cases. A great example would be just about everything Microsoft makes.
To add on to this, there's no standardized way of indicating what needs to be typed out and what needs to be replaced. `foo --bar <replace me>` might be a good example command in a README, but I had to help someone the other day when they ran `foo --bar <test.txt>`, not realizing they should have replaced the < and > as well as just the text.
This describes me somewhat. I use FEA software and only recently started using it to execute jobs in CLI. I still trip over changing directories. Fortunately notepad++ has an option to open CLI with the filepath of the currently open file. I also didn't know right-click is paste in CLI. Don't use ctrl+c accidentally. But ctrl+v does work in powershell (sometimes?). "Error, command not found" is puzzling to me. Where does the software need to live relative to the directory I am using? This is all still very foreign to me, and working in CLI feels like flipping light switches in a dark room.
To answer your last question, on your operating system there is something called “PATH”. It is a user- or systemwide variable that dictates where to look for programs. It basically is a list of directories, often separated by “:”
Further reading: https://www.java.com/en/download/help/path.html (this may have Java references but still applies)
The GP here appears to be on Windows, given their reference to PowerShell. And on Windows, the path separator is ";", not ":".
One of the things I've noticed is that people trying to help the true beginners vastly overestimate their skill level, and when you get a couple of people all trying to help, each of them is making a completely different set of suggestions which doesn't end up helpful at all. Recently, I was helping somebody who was struggling with trying to compile and link against a C++ library on Windows, and the second person to suggest something went full-bore down the "just install and use a Linux VM cause I don't have time to help you do anything on Windows."
The reality is that we've been infantilizing users for far too long. The belief that people can't handle fundamental concepts is misguided and primarily serves to benefit abusive tech companies.
Two decades ago, users understood what "C:\Documents and Settings\username\My Documents" meant and navigated those paths easily. Yet, we decided they were too "stupid" to deal with files and file paths, hiding them away. This conveniently locked users into proprietary platforms. Your point #2 reflects a lie we've collectively accepted as reality. Sadly, too many people now can’t even imagine that a straightforward way to exchange data among different software once existed, but that's a situation we're deliberately perpetuating.
This needs to change. Users deserve the opportunity to learn and engage with their tools rather than being treated as incapable. It’s time we started empowering users for a change.
This is an interesting position because that's only simple if you already know it. From the perspective of discoverability, it's literally the worst possible UI, because a string of that length has, say, 30^30 possible combinations, among which only one will produce the desired effect, and a bash prompt gives you no indication of how to arrive at that string.
Handbrake's UI is in the uncanny valley for me -- too complicated for use by laymen, and way too limiting for use by people who know what they're doing...
A "normal person" is just someone whose time and mental energy are focused on something other than the niche task your app is aiming to solve. With enough time and focus, anyone can figure out any interface. But for many, something which requires a smaller investment to achieve the results they need is preferrable.
Also, even the most arcane and convoluted interfaces become usable with repetition. Normal people learn the most bureaucratic business workflows and fly through them if that is their job. Then if you dare to "improve" any aspect of it you will hear them complain that you "broke" their system.
Well yes you force them to find other workarounds because their current workaround are no longer relevant. Because no system will ever fit everyones usecase.
Was he able to use it correctly though to be able to digitize video with exacltly the correct setttings so that no notable loss of quality was introduced? How long did it take him to randomly test settings?
Actually I think this is a killer use case for local LLMs. We could finally get back to asking the computer to do something without having to learn how to string 14 different commands together to do it.
Linux shells, and that was an exaggeration. The shell is about as general purpose as it gets, but it’s hard to know a priori how to do a certain use case. But if you can explain it in plain language the LLM can do that for you. And at that point maybe you don’t need a gui except to present and manipulate visual output of the shell.
The last thing we want for a user-friendly interface is nondeterminism. Some procedure that works today must work tomorrow if it looks like you can repeat it. LLMs can't be the answer to this. And if you go to the lengths of making the llm deterministic, with tests and all, you might as well code the thing once and for all and not ship the local llm to the end user at all.
Sorry, I see how my post lacked sufficient clarity.
The idea behind a cheap UI is not constant change, but that you have a shared engine and "app" per activity.
The particular workflow/ui doesn't need to ever change, it's more of a app/brand per activity for non-power users.
This is similar to how some apps historically (very roughly lotus notes springs to mind) are a single app but have an email interface/icon to click, or contacts, or calendar, all one underlying app but different ui entry points.
I actually think ffmpeg’s UI is simpler than Handbrake for those at all acquainted with the command line (i.e., for those who understand the concept of text-is-everything-everything-is-text). Handbrake shows you everything you can possibly fiddle with whether or not you plan on fiddling with it. Meanwhile ffmpeg hides everything, period, and you ask for specific features by typing them out. It's not great for discovery but once you get the hang of it, it is incredibly precise. One could imagine taking someone for whom Handbrake was too much and showing them “look, you just type `ffmpeg -i`, the input file, and the output file, and it does what you want”. I imagine for many people this would be a perfectly lovely interface.
FFMpeg's command line is practically a programming language.
Someone who only wants to convert from one format to another, and isn't accustomed to CLIs, is far better served by "drag the file here -> type an output filename and extension in the text box".
The problem (and the reason both FFMpeg and Handbrake exist) is that tons of people "only" want to do two or three specific tasks, all in the same general wheelhouse, but with terrible overlap.
It's funny: "in my head," Handbrake and ffmpeg are two different tools, with very different purposes. Even though they "do the same thing," the context when I use one over the other is very different.
Handbrake is easier in that I don't have to think too hard about how to use it; but that I think a lot more critically about the options that I choose.
FFmpeg is easier when I go in knowing the exact options I want; often pulled from notes that I've stored away, or combined with scripts.
Yes. It's been a few years since I regularly used Handbrake, but I remember thinking of it as very simple, especially with its presets-based workflow. I was used to stuff like various CLI tools, mkvmerge and its GUI, and avidemux at that time.
It struck me as a weird example in the OP because I don't really think of Handbrake as a power user tool.
Using ffmpeg to convert one file to another remains probably my main use of general LLM web searches. This isn't to say it does a good job with that, but it's still ahead of me.
Just like with regexes I've yet to get a wrong result by doing "give me an ffmpeg command that does this and this" with an LLM, with Handbrake I'm never quite sure what I'm doing, too many checkboxes and dropdowns with default values already filled in.
After not having a Samsung device for many years, I reluctantly bought a fridge from them (price was the decisive factor). Anyway, almost immediate regret, it features an always-on wifi network begging to be connected to the web, the only way to turn it off is to disconnect a cable from a circuit board, unbelievable.
Any opinion on why Immich instead of Photoprism? I’m considering to pick one of them for my media library and Immich not being labeled as stable scares me a bit.
IIRC, Immich started as a project after Photoprism changed their licensing to restrict several features, and then picked up a ton of momentum very fast. They've pledged they won't ever pay-gate features, which isn't always a positive as those features help sustain a project long term, but they have so much community support and love that I'm not worried about that in this case.
Feature wise I think they are pretty comparable (vs the paid version of Photoprism), and I like the UI of Immich slightly more. Immich also supports singe sign on via OIDC easily, which I rather appreciate so my family doesn't have to remember 10 different passwords.
Regarding stability it's actually pretty reliable. I've been running it for a long time via Docker in the form of the TrueNAS plugin and have never had any issues, like ever, so I think it being marked as unstable was a bit overly cautious. I think they have also recently moved to a new phase of development that is also going to be even more stable. Even if it does break, all of your media is stored in a nicely organized directory structure on the filesystem so you're not going to lose anything.
Fair 'nuff, my memory is a bit fuzzy as that was a while ago. That was definitely part of the reason it got so much initial momentum, however, even if it was just a coincidence.
I tried both ~1,5 years ago, Immich won the "spouse test" as I could get my partner to use the app on her phone (with her own profile) instead of the native gallery.
Photoprism didn't support profiles or have an app (back then at least, don't know about today), and I couldn't convince her of using some other gallery in the browser...
I for myself liked the Photoprism GUI, but I could never get the face recognition to work well, and manually tagging people/places (or basically doing anything) on thousands of pictures was quite painful.
Also interested in this. I've been running photoprism for several years now using their docker image and don't really have much to complain about but always open to other alternatives.
One thing Immich supports which Photoprism doesn't is multiple user accounts. That doesn't really bother me too much but it's a pretty big advantage.
Edit: Actually one thing I can complain a bit about is the object recognition accuracy. Face recognition I think works decently enough but objects are frequently not identified in my photos. How's Immich in this regard?
I was using PhotoPrism for a few years and switched over to Immich and am very glad I did.
- There was no good mobile backup story. State-of-the-art was WebDAV sync and import delays which would truncate files and other issues on back connections. It also made deletion risky.
- The UI had lots of things that felt very opinionated for a very specific workflow that seems niche. Things like auto-adding generated titles and other things.
- The face recognition is much worse, especially for non-white faces. Even detection didn't seem to have a good setting that would reliably identify what is a face without way too many false positives.
- Immich's semantic image search is way better than what was on PhotoPrism where it seemed to just find a few tags.
- PhotoPrism had lots of UI quirks like the persistent selection that almost never worked how I wanted it to.
Lots of other odds and ends as well. There isn't anything that I actually miss from PhotoPrism.
I’m also going to return an MX Master 3S (to my employer though). I could only fix its weird scrolling behavior with Logitech’s bloatware, still, for the life of me I couldn’t improve the cursor precision on macOS, it’s was simply maddening to use it. Strangely on Linux the precision issue isn’t so bad.
Valve has done an amazing job turning Linux gaming a reality, I really admire their efforts. Unfortunately I had to switch back to Windows on my gaming rig due to a Steam bug which unnecessarily downloads the shader cache of several game every single day, disabling the cache hurts the performance. That’s been plaguing many users for years and surprisingly Valve hasn’t fixed it: https://github.com/ValveSoftware/steam-for-linux/issues/1028...
I think point 3 is completely off. That's not cherry-picking, that's comparing apples to oranges, those generated Makefiles are not meant to be readable, if you want to compare, look at configure.ac and Makefile.am. I also dislike CMake, but just saying it sucks is poor argumentation. Finally, in the title Ninja and Meson are mentioned, just to be completely ignored. I'm having a great experience with Meson, I would like to learn how the Zig build system is better than it, this piece unfortunately does not provide that.
I would go even further: showing the generated cmake file is like showing the disassembly from the zig snippet shown.
I still think the point stands though: zig's build system is nicer. Still bad IMHO as I despise build systems where you describe the build in the same language. Most of the time, it's much better to have a declarative rather than imperative build system. All in all, Ninja/Meson/Cargo/etc are much better in this regard.
(and yes, I think build.rs was a mistake, a necessary evil. Definitely not a feature)
I have never once had to make a build.rs file, except to make python bindings for some of my own rust libraries. Are people out here using build.rs for everyday driving?
Bindings, and generally any form of code generation, is the most common form of build.rs I see in the wild.
One such example of "daily driving" is for gRPC, where the canonical way to generate the protobuf and gRPC bindings using Tonic+Prost is through build.rs. Another is C-to-Rust bindings, for all of those -sys crates.
Though I've also seen it used to circumvent limitations of Cargo, e.g. for invocations of dependent cargo build steps, etc. Overall, it's less common (or more robust?) than it used to be 5-ish years ago.
I have a RPi 2 that’s more than enough for my home server needs and I’ve tried to migrate from docker to podman, it simply failed miserably with weird errors, on my laptop everything worked fine, so maybe that’s an issue with Arch ARM or the 32-bit version of it, but really, I wish they could abstract away quadlet, service files generation and so on.
If you install the `podman-docker` package, you get compatibility with docker commands. If you have errors during runtime, it's probably something in your container/config that's assuming a docker socket/runtime. Some of which can be remedied by pointing `DOCKER_HOST` to your podman socket, etc.
The problem wasn’t running the containers with plain podman, they worked. Auto restart is something podman delegates to quaqlet/systemd, I tried to migrate my docker-compose files to quadlet’s config, the containers were up, supposedly listening to the bound ports but connecting simply didn’t work. I tried rootless, slirp4netns and pasta, nothing worked, then I gave up, some other day I might try again.
Running a very similar setup here, also have issues with networking. Pasta worked, but has bugs and replied UDP packets on the wrong ports. The pasta version from debian packages is too old. Also, I tried making the networking work but now I just slap --network=host on everything and call it a day--works perfectly.
reply