site
contact
newsPondering some fundamentals
Firstly, about USB "gen1" and "gen2"...
USB gen1 versus gen2
I posted about buying a 4TB SSD and putting it into a USB gen1 caddy, then doing a complete OpenEmbedded compile:
https://bkhome.org/news/202303/oe-compile-1662-packages-in-1-day-16-hours-and-15-minutes.html
...very surprised with how fast it was, but noted that a gen2
caddy will probably be even faster.
The terms "usb3.0", "usb3.1" and "usb3.2" just muddy the waters. All that we need to know, is the USB interface "gen1", "gen2" or "gen2x2", as these latter specify the speed; 500MB/sec, 1,000MB/sec or 2,000MB/sec.
Although gen1 seems an ok match for the SATA SSD, I thought that throughput might be improved with a gen2 caddy, so bought one of these, Simplecom SE229:
https://www.ple.com.au/Products/649967/simplecom-se229-tool-free-25-sata-hddssd-to-usb-c-enclosure
Transferred the SSD to it, booted Easy 5.1.1 which is on the SSD.
I was using Geany to edit a file in the 3.5TB partition of the
SSD, and when I saved the file, "File -> Save" from the menu, I
started to notice a delay. At first, it wasn't noticeable, but
after a while it was a delay of 4 - 5 seconds. That is, I would
choose "File -> Save" and nothing would happen for 4 - 5
seconds, then the save would occur and I would see the activity
light flash on the SSD.
EDIT:
Re-reading this blog post, need to clarify the above paragraph. It is
not just that there is a delay writing to the SSD; Geany actually
freezes, with the menu still up, for 4 - 5 seconds. Then the menu drops
away, Geany unfreezes and there is a flicker on the SSD activity light.
This was happening consistently, so I swapped the SSD back to the gen1 caddy, and the problem has gone away. Incidentally, the gen1 caddy is a Simplecom SE221:
So, what is going on? Does Linux kernel have a problem with gen2? Anyway, the next ponderable...
Apps running as own-user or in container
I have been ruminating over this for quite some time. The idea of running each app as its own user, for example, run Chromium as user "chromium", comes from Android. That's how Google achieves isolation between apps. As time goes on, I have realized what a good mechanism this is, potentially almost as secure as running an app in a container.
So, running an app as it's own user, or in a container, are competing security mechanisms, and I am increasingly asking, why have both?
Many users do not understand the difference, and having both is causing confusion. I am increasingly leaning toward disabling container support. Yes, I know that containers has been a main feature of EasyOS, but what does it bring to the table that will justify keeping it?
There is the "wow factor" -- you can click on an icon on the desktop, and up pops a complete new desktop, running either the same distro desktop in a container, or a different distro. You can run a different distro and use its package manager to install packages, which is pretty neat.
But then, ongoing, who actually does run another distro in a container? I don't.
woofQ has a global variable, EOS_SUPPORT_CONTAINERS. If that is set to "0" then EasyOS is created without container support. Yes, I have been considering deprecating containers for a long time, and builtin this global variable. Although that variable disables containers, it can be toggled in a running EasyOS and containers brought back.
I'm thinking of non-technical users. Simplicity is important. Too many choices can become just plain confusing. If you have any thoughts either way, let me know in the forum, the "2023 wish list":
https://forum.puppylinux.com/viewtopic.php?t=7696&start=40
A clarification about running an app as it's own user. As mentioned above, Chromium will run as user "chromium". The home path is /home/chromium, and Chromium will create all its files in there. Chromium will not be able to write outside /home/chromium, with one exception, it can write into /files folder.
That's the basic situation, but there can be considerable further tightening of security, on a per-app basis. For example, the new AppImage Installer installs each app to run as it's own user, take Audacity for example. /files/apps/audacity is created, as a convenient place to save files -- and permissions are such that no other app running as its own user is able to see into that folder.
Tags: easy