I miss more on iOS because if that. The eight things I cared about are mixed in with the 94 that I don’t.

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.

I feel like this would result in so many broken phones that most companies would not want to enter this market. Wouldn’t be surprised if you could find something on Alibaba or Amazon, but I doubt it’s much of a market.

I agree with you. There’s nothing wrong with not knowing how to do something. We all start basically every endeavor not knowing how to do it. My complaint is specifically with people who march into that thing they haven’t learned yet with an attitude of “and you’re all wrong and stupid for not fixing it for me”.

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.

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.

I think the main issue with Arch comes if you try to use it like Debian Stable. Like, if you don’t run pacman -Syu for a year, you probably won’t have a bootable system the next time you try. How about six months? My guess is you’d still be stuck fixing shit. Where is the safe “X” in “as long as I update every X, I’ll be fine?” Who knows. That’s not a very well-defined problem.

I sort of understand the issue here. I use Arch because I’m picky about system things, and it seems to require going against the fewest strongly held platform opinions in order to get it the way I want it. In an ideal world, I’d get it set up that way and not need to touch it very much afterwards. Arch requires frequent touches. Fortunately, almost none of them require any real mental energy, and I’m willing to do the occasional bit of “real work” if needed to keep it going, but that’s a trade-off that may be more painful for some than others.

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.

That all depends on Apple’s ability to run it effectively, and they have basically no demonstrated ability to do that.

App Review is an absolute joke. Listen to last week’s Accidental Tech Podcast. One of the hosts is developing an IMDB competitor app, and he’s been rejected three times as of that episode. One rejection was for playing copyrighted video without permission – in an app that doesn’t have any code that can play a video. One was for not having a link to his T&Cs in a field in the app store that can’t render links. And the third was for displaying copyrighted media in his screenshots (maybe? no one really knows), and that media was the cover art for movie and TV shows. None of those even pass the sniff test. We all know that you’re allowed to show the cover art for a movie in an app that has information about movies. We all know that’s Fair Use, but beyond that, a third grader knows that literally everything in the world that presents information about movies does it. At the exact same time that all this is happening, Apple happily published some scammer’s app called “Threads” and let it collect 300,000 people’s information who thought they were downloading the actual Threads app from Meta.

It’s always been this way. I personally wrote the original iPhone app for a large US retailer in 2008 – the first year the App Store existed. App Review’s only purpose then was to detect your use of private APIs, usually because that would let you build things Apple didn’t want you to build. That’s the only purpose it serves today, 15 years later. Everything else is random noise that just punishes you unpredictably for no reason. I had an update of that app rejected once for using our own company logo as the icon. They don’t catch obvious scams. They never have. The people doing these reviews know nothing or are given so little time that the way to game their metrics is to just randomly reject sometimes without analysis. Unless they change something, it’ll just be a thing that scammers fill out however they want with no consequence to them at all, and a random 5% of legitimate developers will waste a few weeks arguing over when it’s applied to them with no logical basis in reality.

I think there are probably some ways to cross over a bit, but really, LLMs aren’t necessarily aimed at the kind of things we want a virtual assistant to do today. Siri falls down mostly on its ability to correctly do things quickly and reliably. Generating 5000 words of convincingly human sounding explanations isn’t what I want from a thing I quickly trigger on my phone. What I want is very short or no reply accompanying the action I wanted to take. Call this person. Start navigation to an address. Turn on the lights. Play the version of a song I like from this specific live album. Some of those things are things Siri really sucks at today, and none of them are likely to get a lot better with an LLM in place. Maybe playing music benefits from a more robust understanding of the language of my query, but the rest of it are things where the suckage is more that Siri takes 8 seconds for the server to respond or just inexplicably decides that today it doesn’t know how to turn on a light.

At this point it feels like a great LLM would let Siri fail to respond to a much more varied set of ways for me to ask my question in English, but that’s not really the target we’re shooting for here.

You could do it with custom development work – write your own iOS and/or Mac app that uses Apple’s Maps API, but this becomes a fairly substantial software project that you need a programmer to create. It’s not doable just using the Maps app on your device as a user.

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.

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.

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.