To be fair, it is a very long-winded post. I think it’s not an uncommon use case, though, and so deserved a robust sketch of the desired solution; Farmville and chat are sideshows, and what the people left on Facebook are really there for are the Walls.

There are some excellent apps out there, and by and large they look and work better than commercial apps, IME. So I disagree with the assertion that I have to stay with commercial software.

What I was asking for, in my post, was not which apps have better UX than Facebook, but rather which of the very many OSS, federated (although, not necessary for my use case), self-hosted platforms fit the specific use, and ideally with a straightforward iOS mobile app. Doesn’t have to be pretty; just has to be able to quickly take and post photos to a private channel/community/wall.

Circles really is quite nice in all respects. I think they’re hindered by their choice of backend. I’ve been using Matrix for years, and key management has always been a hot mess. I wouldn’t be surprised if the issues we encountered were related to Matrix’s god-awful and buggy PK negotiation & management process.

It’s true some things are harder to do in the container configuration; it’s easier installed as an OS, especially integrations like Z-Wave, ZigBee, RTSP, Eufy, ESP, and so on. All of these require running other software, and in containers it’s a fair bit of fussing with port and host OS device connections.

I’ve always run it in a container, without issue. It works fine, but I’m comfortable with the command line and LXC. That said, flashing an ESP hardware device and getting it connected to HA running in a container has so far defeated me, because I have to give access to the device in the configuration of the container before I run it, but the device flashing process itself is time limited and expects a process to be waiting on it when it is connected. It’s a chicken/egg problem I haven’t yet figured out which wouldn’t be a problem if I were running the HA OS.

HA isn’t the only software that just works better when it controls the while OS. Kodi is another that encourages users heavily to running it as an OS.

Regardless, it runs fine via

podman pull ghcr.io/home-assistant/home-assistant: latest

and there’s a package in AUR that wraps the container up with a systemd service - it’s as close to a bare package install as you’re likely to get.

What’s a little funny to me is that, despite that I’ve been running HA in a container for the past 4 years, I’m working towards getting a dedicated device and running HA OS on it. If we ever move out of this house, I’m not going to spend weeks going around replacing all of the hardware - smart sockets, lights, garage door opener, security, etc etc - with dumb devices; and for any of that to be worth anything, it’s going to need a controller configured for it, which means, I’m planning on selling the HA server device with the house. For that case, I don’t want anything but HA running on that device, and for that, it’d just be easier and smoother to run HAOS.

My advice is to run HA in a container until you are sure that’s the direction you want to go, but not for so long that it’s going to be a PITA to migrate to a dedicated server. But - hey, just IMHO - plan on running HAOS. If I knew then what I know now, that’s what I would have done.

This guy is looking at the long view. If you read it to the end, he’s starting his own garlic farm and is going to constantly undercut Jim’s prices, so that Jim won’t make any (or many) sales, until Jim goes out of business. He’s doing this even if it means a loss for himself; his goal is to ruin Jim’s business.

Now, this is what’s known in Birdman culture as “a Dick Move,” but Jim seems a bit of a dick himself. However, while it might screw up the beginning of my season, if I were Jim I’d simply pivot to onions.

It all comes down to how far OP’s poster is willing to take it. He certainly seems petty enough to pursue all paths, at whatever cost, to prevent Jim from being able to still produce at that farmer’s market; changing crops as Jim changes crops. If Jim’s invested enough, he could rotate his crops between a half-dozen different root stocks and the odds Vengeance Boy would happen to match whatever he’s selling that season would be slim and spoil his plan.

You mean, they’re mounting something that isn’t an SD card to the /sdcard directory? Like something truly evil, such as mount -t btrfs -o subvol=@home / /sdcard? Or do you think there’s not anything mounted there; it’s just a directory in the root partition? None of that would make any sense.

If they’re letting whatever automount tool (eg udevil) do its thing, this is practically impossible. And if they know enough to do it by hand, I think they’d have answered the direct question of “which filesystem” with a filesystem rather than a mount point. Don’t you think? We still don’t know what filesystem they’re working with, since they haven’t answered the question.

I agree; it probably didn’t occur to them. But it was a fairly common job in IT in the 90’s. Not a career or job description, maybe, but a duty you got saddled with.

I can see that, although TBH I almost never have to “admin” EndeavourOS. I just upgrade every once in a while.

Most important to me is being able to find and install whatever software I want, and I have a string preference that it either be installed in my ~, or be managed by the package manager. I really dislike sideloading software globally. And Arch does this better than most. AUR is massive, and packages are trivial to write and install in the rare event something isn’t in AUR.

It doesn’t matter. FAT filesystems - which are usually the default on SD cards, simply do not support ownership or file permissions. Linux emulates these attributes at mount time, but they apply to the entire SD card. You can mount an SD card and tell Linux to act as if root owns everything on the card; you that you own everything on the card; and it will be so until you unmount it and remount it with a different ownership.

These are filesystem level attributes, not device attributes. If you have a modern internal nvme drive and you format it with vfat, you will not be able to set permissions or ownership at the file level, but only at mount time, for the entire drive.

I have to completely avoid mirrors, myself. Walking down a city street on a sunny day is downright hazardous, lest I catch a glimpse of my reflection.

A lawyer. A lawyer might be able to help. Probably not, but it’s better than asking Facebook.

What they really got wrong was the clothing: so much anime/hentai.

This is a techno-goth.

Base Arch can be fussy, but that’s because there’s a lot to set up, so many opportunities to forget things and only discover them later.

I ran Artix on a laptop for about a year; that was a constant PITA, although I still value their goals.

But EndeavourOS has been an entirely different matter. It’s a “just works” Arch derivative.

I had so many fewer problems with Arch that I went through the effort to convert my 3 personal cloud servers from Debian to it. I went through a lot of work to replace thee default Mint on an ODroid to Arch, and it’s been so much better. I put Endeavor on the last two non-servers I installed. So, yes, I personally find out far more reliable and easier to work with than Ubuntu, Debian, or Mint.

That said, I had dad install Mint on a new computer he bought because I had to do it over the phone and he never, ever, upgrades his packages, and almost never installs anything. If all I’m going to do is install it once and then never change anything, Mint is easier. But for a normal use case where I’m regularly updating and installing software, Arch is far easier and more reliable.

A studio should be able to afford a good LTO tape drive for at least one backup copy; LTO tapes last over 30 years and suffer less from random bitrot than spinning disks. Just pay someone to spend a month duplicating the entire archive every couple of decades. And every decade you can also consolidate a bunch of tapes since the capacity has kept increasing; 18TB tapes are now available: $/MB it’s always far cheaper to use tape.

They could have done that with the drives, but today you’d have to go find an ATA IDE or old SCSI card (of you’re lucky) that’ll work on a modern motherboard.

But I’d guess their problem is more not having a process for maintaining the archives than the technology. Duplicating and consolidating hard drives once a year would have been relatively cheap, and as long as they verified checksums and kept duplicates, HDs would have been fine too.

But did you get their number?

I’ve had an Aeropress for about a decade, and for the price I think it’s a great tool to have in the cupboard. It has positives and negatives.

On the plus side, it’s portable, fast, and makes a single serving.

On the downside, it’s single serving, and it produces mediocre cups (IMO, YMMV).

I use mine to make my wife’s once-weekly decaf, and when I run myself out of cold brew and am not in the mood for an espresso drink. Maybe 5x a month. I’m really glad I have it; I’d be unhappy if it were the only thing I had.

If you do get one, look on YouTube for best Aeropress method. Aeropress runs a competition and declares a winner for best method; the current winner is a rather fussy inverted method - but given the design, “fussy” for an Aeropress really isn’t hugely different in effort from Hoff’s “simplified” method. It’s a pretty simple process and you really have to go out of your way to make it hard, unlike pour-over which can be fractally and infinitely fussified.

F-Droid

Most of the apps I have and use are installed via Droidify. The ones that aren’t are company apps, like banking or airline. I could just used the web sites for those; they’re only conveniences.

My phone isn’t rooted, and I didn’t read the article so I don’t know how this will affect me. If push comes to shove, I’ll simply bite the bullet and get a phone I can install Linux on next time, regardless of how polished for daily driving it is.

Github is full of lists of things. There are even several lists of “awesome lists”. Far more than I can list here, and it starts to get painfully recursive (an awesome list of awesome lists of awesome lists?). Just search for “awesome list” on github; some live outside of github, so you could search for “awesome list” in Ecosia, or DDG, or whatever you use.

• https://github.com/athityakumar/awesome-awesomes
• https://github.com/topics/awesome-list
• https://github.com/bayandin/awesome-awesomeness

It sucks the same way Python sucks. Some people just really don’t like indentation-based syntax. I’m one of them, so I dislike both formats. However, if you groove on that sort of thing, I don’t think YAML is any worse than any other markup.

Oddly, I get along with Haskell, which also used indentation for scoping/delimiting; I can’t explain that, except that, somehow, indentation-based syntax seems to fit better with functional languages. But I have no clear argument about why; it’s just an oddity in my aesthetics.

Oh, no. I hate Pumpkin Spice. Pumpkin Pie at Thanksgiving is my bane. It’s probably why I hate Pumpkin Spice. I could live with the stink it for a couple of days, but after StarFucks came out with Pumpkin Spice, it started getting everywhere starting October and running through Christmas.

And it really does smell more strongly than other things. It’s invasive.

How about you having to work next to someone who slathers himself in surstromming every morning for three months, and then come tell me how OK it is for people to invade your space with “a little smell.”

I’m designing off the top of my head, but I think you could do it with a DHT, or even just steal some distributed ledger algorithm from a blockchain. Or, you develop a distributed skip tree – but you’re right, any sort of distributed query is going to have a possibly unacceptable latency. So you might – like Bitcoin – distributed the index itself to participants (which could be large), but federate the indexing operation s.t. rather than a dozen different search engine crawlers hitting each web site, you’d have one or two crawlers per site feeding the shared index.

Distributed search engines have existed for over a decade. Several solutions for distributed Lucene clusters exist (SOLR, katta, ElasticSearch, O2) and while they’re mostly designed to be run in a LAN where the latencies between nodes is small, I don’t think it’s impossible to imagine a fairly low-latency distributed, replicated index where the nodes have a small subset of peer nodes which, together, encompass the entire index. No instance has the same set of peer nodes, but the combined index is eventually consistent.

Again, I’m thinking more about federating and distributing the index-building, to reduce web sites being hammered by search engines which constitute 80% of their traffic. Federating and distributing the query mechanism is a harder problem, but there’s a lot of existing R&D in this area, and technologies that could be borrowed from other domains (the aforementioned DHT and distributed ledger algorithms).