README: correct Linux install guide, add needed config change

[secretmango]

I hope the sharing config will not be needed anymore soon, but for now might be good to add.

Also added a general sandbox note but will add better docs for Linux specifically

Summary

Test plan

[got3nks]

Thanks for the contribution. There's a mix-up worth fixing before this lands:

Sharing IS enabled by default in aMule. Anything placed in the configured shared folders (default: ~/.aMule/Incoming, plus any folder marked as shared in the Shared Files tab) is automatically uploaded to peers requesting it. New users don't need any "enable sharing" step — it's on out of the box.

What I think you may be referring to is the "Who can see my shared files" radio in Preferences → Security: Everybody / Friends / No one (default: No one). This controls whether other users can request a full listing of your shared files via the right-click → "View shared files" menu — a privacy / library-browsing toggle, not a sharing on-off. Most users should leave it at the default, so this isn't a "first-day setup" step either.

The Linux/Flatpak sandbox note is a fair concern (sandboxed installs do need --filesystem access for non-home folders), but it probably belongs inside the existing AppImage / Flatpak section rather than as a standalone "enable sharing" step.

The other change — flatpak install ./appname.flatpak syntax for the Quick start — looks fine on its own.

Want to rework, or pull this back to just the install-syntax fix?

[secretmango]

thanks for the clarification, that was indeed confusing. Might be UI text to improve in the future.

I would also add to change the per slot bandwidth restriction which seems to be capped at 10kpbs which is extremely slow. I would preset this to 1mbps and document that users would like to change this

[got3nks]

On the bandwidth thing — heads up before changing that default, the "Slot allocation" value is a bandwidth-per-slot divisor, not a per-slot upper cap. The label in the UI is misleading (agreed on "UI text to improve in the future").

From UploadQueue.cpp:307-327:

float kBpsUpPerClient = (float)thePrefs::GetSlotAllocation();
...
nMaxSlots = (uint32)floor((float)thePrefs::GetMaxUpload() / kBpsUpPerClient + 0.5);

The semantics are: total upload limit ÷ slot allocation = number of concurrent upload slots. So:

• SlotAllocation = 10 KB/s with MaxUpload = 100 KB/s → 10 concurrent slots, each can use whatever share of the 100 KB/s is available at the moment (peers compete for bandwidth, not pinned to 10 KB/s each).
• SlotAllocation = 1000 KB/s (your proposed 1 Mbps default) with the same MaxUpload = 100 KB/s → 0-1 slots, clamped up to MIN_UP_CLIENTS_ALLOWED. Most users on a typical home upload (50-200 KB/s effective) would end up sharing with effectively one peer at a time, which is worse than today's behaviour.

Raising the value reduces concurrency; lowering it increases it. The default of 10 is tuned so a user with a few hundred KB/s of upload gets several parallel slots and the ed2k peer credit accounting (which rewards short, fast, varied connections) works as designed.

If the UI text is the real friction, that's a separate fix worth filing as its own issue — "Per-slot bandwidth: 10 KB/s" in Preferences should probably read "Target bandwidth per upload slot (used to compute number of concurrent uploads)".

Want to drop the bandwidth-default suggestion from this PR and keep the scope on the install-syntax fix you already had? Filing the UI-label issue separately makes sense — I'd back that.