Need to think about an update strategy

[probonopd]

pkg upgrade seems to overwrite our configuration.

For example, our changed rc scripts are seemingly replaced with those from the pacakges, and our carefully configured slim.conf is moved to slim.conf.pkgsave.

How does e.g, the Mac work when "over-installing" a newer version of the OS?

[grahamperrin]

Was the slim.conf.pkgsave effect reproducible?

… How does e.g, the Mac work when "over-installing" a newer version of the OS?

IIRC it's quite blunt. Something like, writing all affected files to a temporary path then a move into place – typically without considering the before/after state of things (because things are so neatly separated).

[probonopd]

The OS in a read-only image + user modifications in a read-write unionfs overlay would solve this very neatly...

[grahamperrin]

helloSystem/hello#37 (comment) recently I might have misunderstood what's to be expected within the constraints of 'live' media.

If the OS will be read-only: that's fine, if:

1. user data is saved to persistent storage on the medium; and
2. user data will be transferable, fairly easily, from an old medium (i.e. outdated OS) to a new medium (up-to-date OS).

Alternatively: some way to periodically download then 'slot in', to the medium, an updated OS?

[probonopd]

What I mean is that the OS should be conained in a read-only image file (in the worst case: ZFS dataset) but overlayed with read-writeable space so that any changes by the user get redirected into the read-writeable area. This way, the system appears entirely r/w to the user.

When an OS update comes along, the read-only file is switched to another one, but the user-generated content "on top" still is there.

NomadBSD kinda goes into this direction, but the underlying OS is not an image file but a partition, which makes updating it harder.

Why do I want an image file rather than a partition for the system: So that it can be most easily exchanged with another one, and users can easily keep multiple ones around.

The more I think about it, we should have a closer look at what NomadBSD is doing there. Using a file rather than a partition shouldn't be that hard to change... but then, as far as I remember, not even NomadBSD achieves that all parts of the system appear r/w to the user.

[grahamperrin]

Overlapping:

• System Update/Upgrade utility · Issue #33 · helloSystem/Utilities

#55 (comment)

pkg upgrade seems to overwrite …

Not a problem with pkg(8); see helloSystem/hello#67 (comment)

From #135 (comment):

A system that works for, not against, you

Freedom: lets you load software without restrictions. … easy to modify applications. …

ISO/settings/script.hello

Line 329 in 56a03e4

*upgrade*) echo "pkg update is not yet supported in helloSystem" ;;

pkg-upgrade(8) is not pkg-update(8)

ISO/settings/script.hello

Line 328 in 56a03e4

*update*) echo "pkg update is not yet supported in helloSystem" ;;

Why are there still these restrictions?

Why work against the natural desire to install, or update, an application?

This is the opposite of ease.

[probonopd]

Why work against the natural desire to install, or update, an application?

Because you can end up with a half-outdated (hello components), untested (in this combination), messed up (regarding configuration files), and potentially no longer working (as you have shown) system.
helloSystem is (also) for non-technical users who should never have to see a terminal.

Note that it says "not yet". We still "need to think about an update strategy" and it will probably be more like Android/iOS.

[grahamperrin]

end up

Are boot environments forgotten again?

helloSystem/Utilities#33 (comment)

non-technical users who should never have to see a terminal.

If you stop crippling pkg, these users will be blissfully unaware of the improvement.

[probonopd]

Boot Environments just allow to go back once disaster has struck. I want to avoid the disaster in the first place. (As I am sure you find out you can use pkg.real if you really know what you are doing.)

Note that pkg is not mentioned in any helloSystem documentation at all.

[grahamperrin]

pkg is not mentioned

Maybe not mentioned at https://hellosystem.github.io/docs/index.html but pkg is integral to FreeBSD.

From helloSystem/hello#110 (comment):

… we want to stay "true FreeBSD" wherever possible. So at least for what comes as part of the Live ISO, I think the existing system wih ports and packages serves us well …

From main page https://github.com/helloSystem/hello#what:

Based on FreeBSD. Less, but better!

… Without lockdown. Without Big Brother. The user in full control.

Crippling pkg, for any length of time, does not make helloSystem better than FreeBSD.

Boot Environments just allow to go back once disaster has struck.

That's a somewhat narrow vision.

Less dramatically: boot environments allow you to progress¸ with the option of going back.

If there's a fear of boot environments, then why is Boot Environments amongst the preferences for helloSystem?

[probonopd]

There is no fear of BEs, but

• We need a way to select BEs from the bootloader, which means we need to work on the bootloader to be completely silent unless a key combo (e.g., Command-B-E for Boot Environments) is held down
• In order to be able to update the system (not just some apps) using pkg, someone would need to package all of helloSystem

[kettle-7]

In order to be able to update the system (not just some apps) using pkg, someone would need to package all of helloSystem

If you use SystemImageKit and have a pure FreeBSD image with an early init script to copy over hello-specific files from a second image with geom_rowr or something, then you can use rsync to update the two.

Does this simplify things or complicate them?

[probonopd]

So your idea is to have one image that contains an unmodified FreeBSD, and another one that contains the helloSystem modifications? Would work but would require a working union filesystem, because geom_rowr doesn't allow you to use the second image without the original first image.
Also, I think even updating an unmodified FreeBSD is too complicated. I'd just replace the whole image with a new one. Similar to how OpenWrt works.