The dependency chain for building the entire kernel depends on what you included in the feature set. The reason it probably worked on Ubuntu is because the build-essential package covers the most common deps needed to build the kernel.

Need output to be able to tell you anything. Post the errors.

Regardless, if you’re building something without a purpose, assign it a dedicated purpose instead of just making it some other running machine.

You literally say in your post you’re building another machine.

Make it a single purpose machine that does the thing you need it for.

Separate the use-case here:

1. For your desktop, whatever works. There is no one distro that gives you some leg-up on performance or anything else. You can install the same software on all, and the kernel is largely the same.

2. Just get or build a NAS for hosting media. A Synology or Qnap has a bit of added cost, but the maintenance overhead is reduced by a LOT versus running TrueNAS, OMV, or similar. That being said, choose the right tool for the job, and don’t just run Debian for this purpose because it just adding admin overhead you don’t need. This probably has been solved from your specific angle. What you want is simplicity in maintenance. Being able to hotswap and repair a failed drive means a huge win.

Zone aware networked alarms exist for a reason. This sounds kind of sketchy to me…

You can do this much simpler with the HA app registering back with your network when home or BT proximity to a location.

🤣

My gawd. The hoops you jump through. Just take the L and walk on, slugger.

This right here.

An example:

Application Payload = 100MB AppImage all inclusive image with deps = 175MB Flatpak App Layer = 101MB Flatpak Deps = 75MB

Now say you’re shipping 1000’s of similar applications with the same general dependency chains in bulk operations to things like end-user devices.

Flatpak wins. That’s the point.

This isn’t a discussion about an average Desktop user saving some disk space.

Can you give more specifics about device drops? Have you looked at the mesh layout in HA to see what connections are being made between devices?

You may not have a distance issue that a new adapter will fix. You might just need a repeater/router.

Linux has been the most prolific OS on devices for 25 years, friend.

Go back 20 years. See how many times this prediction has been made 🤣🤣

The only shift now is Microsoft shitting the bed so hard that people don’t want to deal with them. The difference this time is the MacBook Neo.

People would gladly pay Apple $600 for a working machine WITH support and stores everywhere to get help if they have hardware issues. It’s the new iPhone business model. They’ll be taking more desktop market share than people even imagine on the price point alone.

I don’t really get the point of the blog, honestly, because in the first part they are railing against one angle, then reverse and argue FOR it in a sense by saying Flatpak just works. Of course it does. That’s it’s job.

AppImage also just works, but there is a fundamental difference in the delta of what you get as a payload. AppImage has EVERYTHING the image needs to run. Flatpaks only contain the running code and custom dependencies, then it’s manager solves for shared libraries and generics from commonly available layers to download and run to solve for those deps.

Both make sense depending on how you feel you need to tackle the problem.

Where the author kid of goes off the rails is complaining that somehow either camp is somehow responsible for their product being popular enough to survive and be taken up by Valve. In this specific case, Valve is intending to include simple packaging for games and libraries they intend to ship to millions of cross platform devices. Flatpak makes sense from a bandwidth and storage standpoint for end-users.

AppImage does not. No idea why this person is taking issue with that.

Flatpak makes more sense for how Valve will be using it for all their new devices. Simple as that.

They “shit” money into ALL kinds of development that pushed lots of projects forward a decade in maybe a years time, and are doing it again with FEX. Are you taking issue with allmof that, or just this because they have a business use-case?

If you’re getting file verification errors, it probably means there are issues with files on one end of the other.

So a few things:

1. What’s this remote machine, and have you checked the filesystem recently?
2. Have you checked the filesystem on your local machines you’re copying files from?
3. Have you tried copying to an empty remote.traget directory and seeing if you still get these errors?
4. If 1 & 2 are fine, and then 3 works without problems, make a short list of some of the files that are throwing errors. Do they happen every single time at these same files? What’s unique about these files?

Versions should be fine. Your options matter though, so send the full command you’re using.

Also try this:

1. Open one terminal window and run a ping at your remote machine and let it keep running
2. Open another term and run your sync. See if ping lags or delay issues start when the rsync issues start in both windows

Jaguar with 4GB of RAM. It’ll do all the normal desktop stuff and games up through maybe PS2 no problem.

Make sure you add at least 4GB of swap though.

deleted by creator

It won’t work.

Like every these, repetition is key, and also stepping through each idea to get to an outcome.

Good luck to you though.