Hi Morgano.
I would recommend to remove the steps/chapters/hints regarding MGA6 and MGA7. They are EOL and unsupported. If you don't have time for it, give me a shout and i will clean up this site from it (only if you want).
Regards sturmvogel
2022-04-28 19:43 CET:
Hi
It is a good thought and I was pondering a bit about it. I decided to keep it as sometimes one would like to use elder systems, and Live mode is then a safer way then a regular install. As they are already there, why not keep?
I will be going trough the four new pages I launched for link fixing and updating, then post on QA and doc they are ready for further scrutiny :)
I see you are already at it, tanks, but you can hold of a day until I feel I am finished myself :)
Best Regards /Morgan
morgano (talk) 23:23, 30 April 2022 (UTC)
Done.
Next, I will be linking to and from them with other wiki pages.
encrypted live persistent versus simply installing
Hello,
iso-dumper is a very good tool to create an encrypted persisten liveUSB.
It should be noted that because of the nature of USB flash drives: easily lost or left somewhere it is a very good idea to encrypt just in case your USB is lost or stolen. Otherwise, on an un-encrypted LiveUSB it is quite trivial to gain root access and then to find interesting user logins and all their associated credentials: for example: gmail login.
It is safer to encrypt and protect your digital identity.
Another issue I found with using a persistent (encrypted or not) LiveUSB is the nature of updates which are done as deltas to the ReadOnly copies of files from the Live ISO image.
This means that the disk space needed to accomodate both the original ReadOnly ISO files and the ReadWrite deltas for all updates is used up space very quickly. It tends towards halving the space you may think you have.
For this reason, I tried installing a USB just as if it was a disk drive using the Classic Install ISO. The effect of this is to not have both RO copies from the LiveISO plus the RW deltas for all the system updates which means having more usable space on the USB.
Classic Install on a USB works very well and you can maximise the limited space on your USB flashdrive.
Cordialement Kind Regards Paul [tree|wiki|code|news]gazer
morgano (talk) 07:10, 19 June 2023 (UTC)
Right, I now added a line encouraging encryption due to security. Without encryption you need not even gain root access, just plug the stick it into another system and read the persistence partition...
Yes if you want to keep size down, a normal install directly to the USB stick is better. I link to that under the header [[Persistent_live_systems#Alternative_methods|Alternative_methods] - as well as making ones own updated and special Live ISO.
One big advantage with Live is that if the updates or settings foul up (been there), (i.e by glitchy connector) you can boot without the persistence.
We could add the following in the "Tips" section:
- If you have more than 2GBs of RAM available in your old computer, you could install firejail to run certain programs on the RAM. It is significantly faster than the USB stick (especially USB 2.0). But it also means that you will not be able to save almost anything.
Example commands: "firejail --private falkon" "firejail --private firefox" "firejail --private --appimage ~/apps/librewolf/LibreWolf.x86_64.AppImage"
morgano (talk) 08:31, 10 December 2025 (UTC)
Thank you for the tip Nikos.
But are you sure it really is noticeably faster? It need to load the program from the USB anyway.
I guess(have not tested) you need more than 2GB RAM for this method to work nicely, especially with a non minimalistic DE (think Plasma) and hungry program like Firefox?
BTW, if you want to update or improve the page, please go ahead :) I do not have much time anymore. Just make sure you test things first :)
Also, by now, I think we now can remove the stuff that is elder than Mageia 8, like suggested by sturmvogel earlier, see top post above.
It will save you a lot of waiting and freezing. For example, opening a youtube page will certainly lead to freezing when using the standard method, in my live system (USB 2.0 connection). But when having everything working on the RAM, I can actually watch youtube videos. I have only tested this with lightweight window managers.
Unfortunately, time is a luxury I don't have either.
I just added the tip about firejail.
morgano (talk) 10:31, 11 December 2025 (UTC)
Thanks.
I believe the benefit comes from restricting the programs to write to the USB - writing is the slowest bottleneck, especially with some USB. (I guess it will also speed up Firefox a bit on old slow spinning disc computers.)
If you can come up with a trick to enable users to i.e save files from Firefox, it would be a great addition to that tip :-)
> writing is the slowest bottleneck
A constant reason for freezing and just waiting...
> If you can come up with a trick to enable users to i.e save files from Firefox...
The only solution I came up with was to copy the download link (in some cases while it was still "hot", meaning that this often is a temporary link that will expire after, let's say, the connection with the webpage is finished by closing the browser tab). Then I would open a terminal and use the command...
wget DOWNLOAD_LINK
or...
wget "DOWNLOAD_LINK"
if the link address was complicated.
It is not the best tip for beginners though. That's why I was reluctant to add it in the first place. For example, a beginner in linux might not know the "cd" command and would be trying to find the downloaded file all over the place.
morgano (talk) 08:44, 15 December 2025 (UTC)
>> writing is the slowest bottleneck
> A constant reason for freezing and just waiting...
I wonder if it is possible to implement a large write buffer, that dynamically use all free RAM to swallow writes and then write lazily to USB.
> I wonder if it is possible to implement a large write buffer...
That would be far beyond my abilities (no programming knowledge whatsoever). Also, this is far beyond my time schedule. The opposite direction would be to write less: for example use a "mobile" User Agent for the browser that would direct the user to the "lighter" mobile version of a site. That type of tricks...
morgano (talk) 12:01, 16 December 2025 (UTC)
No programming needed. Maybe just pass some parameters to kernel to cache more an write more lazy, maybe setting in fstab, though I am not sure if that really works on Live. Backside of course is that the more we delay writes, the mare are lost and also more risk of filesystem failure if power are cut or the USB suddenly is plugged put. https://www.ecosia.org/search?q=disk+write+cache+linux gives some ideas. Firefox is slow to even launch also on my Thinkpad T3, single core 32 bit with spinning disk. I have tried light weight browsers, Falkon and some other, but they do not work at all on that system (if I and packagers had more people I would have raised bugs).
32bit is a problem nowadays. We have a 32bit Microsoft Windows system -- portableapps has 32bit versions of programs for Microsoft Windows, maybe you can find some cross platform tools there.
I use SeaMonkey with javascripts disabled by default, and open another browser (maybe with "firejail --private") when I must use javascripts. I just skip most sites that need javascripts -- there are plenty of fish in the ocean.
