Difference between revisions of "PinePhone UBports OS Design Discussion"

Jump to navigation Jump to search
m (Add to PinePhone category)
(style fixes)
Line 1: Line 1:
==Why this page==
==Why this page==
As I saw a lot of bad things said about the UBPorts OS shipped with their Community Edition, and a lot of people were ready to give up on it, I asked UniversalSuperBox and the rest of the UBPorts people to help the general PinePhone community out, providing answers to some misunderstandings people have about the reasoning behind the Operating System and the choices they made to make sure it is a robust system to provide to casual users that do not yet see the option to contribute as viable.
As I saw a lot of bad things said about the UBports operating system shipped with their Community Edition, and a lot of people were ready to give up on it, I asked UniversalSuperBox and the rest of the UBports people to help the general PinePhone community out, providing answers to some misunderstandings people have about the reasoning behind the Operating System and the choices they made to make sure it is a robust system to provide to casual users that do not yet see the option to contribute as viable.


I personally think the UBPorts team has made some very smart decisions to make Linux more secure in a device that is always vulnerable to physical attacks, as it is moving around in the world, as opposed to the traditional Linux machine in a protected serverroom. Linux is very robust, it just does not try to protect against all Threat Models. UBPorts already provides a lot of devices with their OS, so they have a lot of experience and thought put into the system already, and it would be good to leverage that for other projects as well, once they are ready to look into those. Maybe they will use a different reasoning, but it still is good to learn how the UBPorts community solved their issues.
I personally think the UBports team has made some very smart decisions to make Linux more secure in a device that is always vulnerable to physical attacks, as it is moving around in the world, as opposed to the traditional Linux machine in a protected serverroom. Linux is very robust, it just does not try to protect against all Threat Models. UBports already provides a lot of devices with their OS, so they have a lot of experience and thought put into the system already, and it would be good to leverage that for other projects as well, once they are ready to look into those. Maybe they will use a different reasoning, but it still is good to learn how the UBports community solved their issues.


Specifically I asked for an answer to the reasoning behind the formatting scheme and creation of the UBPorts image, which is one of the things a lot of the people seem to struggle with. There are more issues that seemingly stop users from using their OS as a open system to experiment on, but these are for great reasons as weel, in my opinion. If we could understand those reasons better, all of our communities could improve.
Specifically I asked for an answer to the reasoning behind the formatting scheme and creation of the UBports image, which is one of the things a lot of the people seem to struggle with. There are more issues that seemingly stop users from using their OS as a open system to experiment on, but these are for great reasons as well, in my opinion. If we could understand those reasons better, all of our communities could improve.


UniversalSuperBox was willing to provide us with some answers, and as always, presented them very well, and it was very interesting to read. Thank you for that!
UniversalSuperBox was willing to provide us with some answers, and as always, presented them very well, and it was very interesting to read. Thank you for that!


As I think it would be sad to leave such valuable info in the backlog of the chat, I would like to post it here as well, and try to make the most sense out of them. I hope many will add their conclusions, so we all learn. Later on, I hope we can look into other differences of the UBPorts system, and look into the specific solutions other OSs found for some common problems.
As I think it would be sad to leave such valuable info in the backlog of the chat, I would like to post it here as well, and try to make the most sense out of them. I hope many will add their conclusions, so we all learn. Later on, I hope we can look into other differences of the UBports system, and look into the specific solutions other operation systems found for some common problems.


==Chat log==
==Chat log==
Line 45: Line 45:


Then there is a list of all the partitions: "Loader, scr, persist, boot_a, boot_b, recovery_a, recovery_b, cache, system, data." Each of the names provides an indication about its function, but lets try to make a nice list out of it here on the wiki:
Then there is a list of all the partitions: "Loader, scr, persist, boot_a, boot_b, recovery_a, recovery_b, cache, system, data." Each of the names provides an indication about its function, but lets try to make a nice list out of it here on the wiki:
===UBPorts Partition list===
===UBports Partition list===
#loader
#loader
#scr
#scr
Line 58: Line 58:


It is immediately clear that this is a well thought out system, protecting against a lot of possible mishaps. Some sound like they should clearly be usable to a lot of other distributions. But the next info clears up what each partition does, so lets try to add that to the list.
It is immediately clear that this is a well thought out system, protecting against a lot of possible mishaps. Some sound like they should clearly be usable to a lot of other distributions. But the next info clears up what each partition does, so lets try to add that to the list.
===UBPorts Partitions and their functions===
 
*loader: loader is the u-boot bootloader. It's not at sector 16 like on most OSes so that a full GPT table can be available at any time.
===UBports Partitions and their functions===
*loader: loader is the u-boot bootloader. It's not at sector 16 like on most operating systems so that a full GPT table can be available at any time.
*scr: scr stores the boot.scr script which allows the system to boot at all
*scr: scr stores the boot.scr script which allows the system to boot at all
*persist: persist is a 5M-ish partition for storing things that need to persist between reboots. Right now that's exclusively the reboot-recovery file which tells the bootscript to boot to the recovery partition (later we'll probably put the selected boot slot there)
*persist: persist is a 5M-ish partition for storing things that need to persist between reboots. Right now that's exclusively the reboot-recovery file which tells the bootscript to boot to the recovery partition (later we'll probably put the selected boot slot there)
Line 72: Line 73:
We can see immediately that all the partitions have a distinct use case, and from their existence alone we can deduce a lot. there seems to be only one partition that is used for the user to store the data in. It is the last of them, called data, and is expanded after writing the image, to fill the rest of the available space. This is left alone during upgrades, so we can place our personal stuff in there, and backup just our that.
We can see immediately that all the partitions have a distinct use case, and from their existence alone we can deduce a lot. there seems to be only one partition that is used for the user to store the data in. It is the last of them, called data, and is expanded after writing the image, to fill the rest of the available space. This is left alone during upgrades, so we can place our personal stuff in there, and backup just our that.


Also there is a lot of talk about A and B partitions. They ensure that even if things go horribly wrong, there are ways to get back in a usable state. I will expand on that later...
Also there is a lot of talk about A and B partitions. They ensure that even if things go horribly wrong, there are ways to get back in a usable state.
 
More will follow :) If you want to show off your reasoning in the OS you like, talk to me on IRC (irc.pine64.org) or any of the connected chat channels. I am abcde :)




[[Category:PinePhone]]
[[Category:PinePhone]]