Well, we’re here on a web site discussing it, and the top two recommendations are “build one yourself from parts” and “buy a used one in cash”.
Seems to me that it’s the very definition of unrealistic if the real world has almost no examples that do it.
Or just use their built in sync and sign in one time, and all your addons will be installed and enabled for you.
If your argument boils down to “none of the browsers are exactly pre-configured for me, one of the 7 billion not special people on the planet”, I’m not sure there’s a productive conversation to be had here.
That’s definitely not the norm. Used to be that installing Windows would wreck Grub, but you just needed to but a rescue disk and reinstall Grub one time to fix it. Most people dual booted for decades without any issue there.
It’s been a while since I’ve had a Windows machine, but doesn’t Windows index the content of files as well as their names? If so, that would have fairly profound differences from slocate.
So your solution on Windows requires me to move all my files out of where they belong to process them? How do I get them all back when I’m done?
I knew how to write that find command. Didn’t need to search for anything. And because I know how to do that, I can also search for every pdf file modified since last month. I can spit out a list of the gps coordinates for every photo I’ve taken, ordered by latitude. I can find every Python script on my computer that uses Pandas. I can do a million things that boil down to “find every file that matches some complex filter and do something to it”, and I learned one tool. I don’t need to learn one point and click app that converts comics, one that messes with photo metadata, etc.
I can sympathize with the idea that there’s a high learning curve. And there’s nothing wrong with trying to provide ways for people to use their computer that require less knowledge. But recognize that you’re asking for a crutch here.
You can set MAKEFLAGS in /etc/makepkg.conf to something like “-j8” (where “8” should be something like the number of cores you have or maybe number of cores minus one or two if you want to leave some CPU capacity available.
However, the build instructions for a specific package can override these defaults. You’d have to look at the resolve-davinci package files to see if it does that for some reason that might be important.
Mostly you’re paying so that never getting any resolution is someone else’s fault.
I’m a bitter, stagnant, arrogant old man. That this guy also can’t write for shit is coincidental.
I use Arch because it is generally the easiest one I’ve found to pretend it’s 2010 again. Most Linux distributions are fine, but they’ve all been busy trying to solve problems I don’t have and accepting that some niche corner cases are fine to break. I’m just a niche corner case in general.
I have nothing against Wayland trying to modernize the UI stack, but if their answer to half the things I need is “well the compositor should do that” and the compositor doesn’t in fact do that yet, then I don’t want to use Wayland yet. I have nothing against Flatpak trying to modernize application packaging, but their current story for making applications available from a shell is effectively “why do you want to do that”, and well…I do want to do that, so I guess I don’t really want to use Flatpak yet.
That’s just me. Like I said…I’m a corner case. I understand that everyone else wants their computer to be an appliance that does what most people need without requiring any tinkering. And I’m not opposed to getting rid of the need to tinker. I’m too old to view tinkering to make something work as I think I look forward to. I just view tinkering as a one-time cost with perpetual returns. I’m OK editing an xkb file to make some obscure input device work the way I want it to, because that might take me an afternoon, and then I just have that device do exactly what I want for the rest of its life with no further effort. Make it so that I never have to edit another xkb file again and I’ll be just fine. But you can’t do it by just saying, “no more needing xkbcomp because it doesn’t work anymore, and if you needed it, go see if the compositor vendor will write some code for you”.
It’s not that I’ve never had any problems. It’s more that those are infrequent one-time problems, and if something happens once every two years that takes me 30 minutes to solve, I’m willing to do that if it makes the day-to-day use of my system smoother. Flatpak feels like I’m rubbing just a little bit of sandpaper across my face 20 times a day, and the promise is, “yeah, but look how you’ll never have to solve this minor one-time things again”, and that’s just not a trade I want to make.
And in a way, everything is a CLI tool on most normal systems. Evince or Acroread or whatever you prefer to read PDFs is not “a CLI tool”, but if I want to use LaTeX to create a document, I want to be able to do something like
$ xelatex myfile.tex
$ evince myfile.pdf &
I don’t want to have to build my document, bring up my app launcher, click on the Evince icon, hit Ctrl-O, navigate to my pdf file, and double click it.
/var/lib/flatpak/app/org.gnu.emacs/current/active/export/bin/org.gnu.emacs is not what I expect a Unix system to want me to type if I want to run Emacs. Nor is flatpak run org.gnu.emacs. These are tools built by someone whose mental model of running Unix software is “click the icon in the Gnome launcher”. That’s one aspect what I’m describing as not being “simple”. I don’t want my mental model of how to run Unix software to include “remember how you installed it and then also remember the arbitrary reverse-FQDN-ish string you need to use to tell flatpak to run it”. If I’m honest, that alone is sufficient to signal it wasn’t built for me. I could work around it for sure with shell aliases, but I could also just not use it, and that seems fine for me.
You’re correct that Flatpak solves that problem, and there’s some value there. But you can also solve the problem by just having two versions of Python or two version of libjpeg or whatever installed, and then you as the user/admin manages ensuring that each program uses its correct dependency. That’s certainly more difficult, but I’ve just not found it to be problem that is both frequent enough and difficult enough to solve that I would personally value the tradeoff in overall complexity of adding Flatpak to the way I manage and use my systems.
I accept that I’m in the minority on these things, but I value simplicity really highly, and I mean “simple” as a very specific concept that’s different from “easy”. It can be harder to resolve library dependencies on a system where everything is installed using the native package manager and common file systems, but nothing is as “simple” as ELF binaries linking to .so files. Nested directories branching off of / is “simpler” than containers.
Do I have any practical reason for preferring things this way? Not really. There are some ancillary benefits that come from the fact that I’m old and I already know how to do more or less anything I need to do on a Unix system, and if you tell me I need to use flatseal or whatever, I’d rather just use users and groups and tools that have been fine for me for 25 years. But that’s not really why I like things this way. I have no issue with embracing change when it otherwise appeals to me --I happily try new languages and tools and technology stacks all the time. What it really is is that it appeals to the part of my brain that just wants to have a nice orderly universe that fits into a smaller set of conceptual boxes. I have a conceptual box for how my OS runs software, and filling that box with lots of other smaller little different boxes for flatpack and pyenv and whatever feels worse to me.
If they solved practical problems that I needed help solving, that would be fine. I have no problem adopting something new that improves my life and then complaining about all the ways I wish they’d done it better. But this just isn’t really a problem I have ever really needed much help with. I’ve used many Unix systems and Linux distributions as my full-time daily use systems since about 1998, and I’ve never really had to spend much effort on dependency resolution. I’ve never been hacked because I gave some software permissions it wouldn’t have had in a sandbox. I don’t think those problems aren’t real, and if solving them for other people is a positive, then go nuts. I’m just saying that for me, they’re not upsides I really want to pay anything for, and the complexity costs are higher than whatever that threshold is for me.
That’s not all that different than a traditional package manager. You’re downloading the dependencies either way. With Flatpak, they’re bundled in. With a traditional package manager, it just fetches all the dependencies and shows you that they’re being installed one-by-one. Either way, it’s one command to install.
If you’re on Wayland, you’re probably on your own, but Xorg almost certainly can support anything except stuff like RGB lighting and DPI switching and that sort of thing. “Normal” mouse buttons should just be generating events that you can see with xev, and then remap them with xkbcomp or xmodmap.
I use a Razer Naga Trinity with the MMO buttons on the side, and I configure it exactly how I want with a script that calls xkbcomp when my window manager starts.
Certainly it’s possible to be a Linux user without learning the things that we would say mean you “know Linux”, but I think the most effective way to learn them also requires being a “user”. Using Firefox on Ubuntu instead of Windows doesn’t teach you Linux, but If you don’t have X11/Wayland and a browser and you can’t do your online banking and social media and Youtube, then you won’t actually learn the “real” stuff, because you’ll spend all of your time in Windows and Linux will feel like homework. Instead, get a full Linux desktop experience that you can do all the things you want to do with, and as you’re doing those things, also seek out opportunities to learn the shell and userland utilities, etc.
Mostly good advice. I disagree on the headless server part though. Most people who are interesting in learning "Linux” have a much less reductive idea of what that means than you do, I think. Specifically, I think becoming a comfortable, fluent speaker of a typical Unix/Linux environment and userland is probably the most important thing. I think the best way to start doing that is to just live in Linux, and you’re not going to do that on a headless server. Learning the GUI that your distribution uses to add users isn’t important, but having a GUI where you can run standard browsers and photo editors and such is important, because otherwise, you’ll spend all your time in Windows and never have the chance to develop fluency in all the stuff that is actually important.
Limiting yourself to only using command line stuff I suspect does more harm than good, unless you’re hyper-motivated to learn fast. For most people, the smoother path is probably more gradual. Start with Gnome or whatever and just use the computer. Over many years, you’ll learn a lot of piecemeal things just by becoming frustrated with some problem and learning how to solve it. I do think it’s good advice to do as much from a shell as you can from day one. Instead of using the GUI to copy files, learn to do it from a shell. Just don’t feel like you aren’t allowed to use Firefox to browse the web.
I’m not in front of a computer to test, but the man page would suggest that chown -HR would do the trick.
As an internal implementation detail, it’s fine and pretty standard. Exposing it to the end user so that they have to know whatever janky-ass domain and capitalization you picked to run your application is braindead.