ISO
ISO copied to clipboard
helloSystem
Need to think about an update strategy
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?
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).
The OS in a read-only image + user modifications in a read-write unionfs overlay would solve this very neatly...
https://github.com/helloSystem/hello/issues/37#issuecomment-751341802 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:
- user data is saved to persistent storage on the medium; and
- 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?
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.
Overlapping:
https://github.com/helloSystem/ISO/issues/55#issue-775400817
pkg upgradeseems to overwrite …
Not a problem with pkg(8); see https://github.com/helloSystem/hello/issues/67#issuecomment-772307831
From https://github.com/helloSystem/ISO/issues/135#issuecomment-800032910:
A system that works for, not against, you
Freedom: lets you load software without restrictions. … easy to modify applications. …
https://github.com/helloSystem/ISO/blob/56a03e4d5e3514e9b08857ccf80d84c4d9a53aec/settings/script.hello#L329
pkg-upgrade(8) is not pkg-update(8)
https://github.com/helloSystem/ISO/blob/56a03e4d5e3514e9b08857ccf80d84c4d9a53aec/settings/script.hello#L328
Why are there still these restrictions?
Why work against the natural desire to install, or update, an application?
This is the opposite of ease.
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.
end up
Are boot environments forgotten again?
https://github.com/helloSystem/Utilities/issues/33#issuecomment-800529129
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.
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.
pkgis not mentioned
Maybe not mentioned at https://hellosystem.github.io/docs/index.html but pkg is integral to FreeBSD.
From https://github.com/helloSystem/hello/issues/110#issuecomment-776911839:
… 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?
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
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?
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.
Yeah, pretty much. Even if you mount /var from a persistent partition, and symlink /etc, /Applications, and /Users to subfolders of /var, like Silverblue does, would that work?
up.bsd.lv Binary Upgrades Report
From https://up.bsd.lv/:
2021-07-26 - This Proof of Concept was extremely informative and is taking a break to build a Proof of Concept replacement for freebsd-update. Thank you everyone who helped out with it!
pkgis integral to FreeBSD.
More accurately:
- the normally used
pkgis a port – ports-mgmt/pkg - the
pkgthat's installed with FreeBSD is for bootstrapping – when run, it invites installation of ports-mgmt/pkg.
https://cgit.freebsd.org/src/tree/usr.sbin/pkg
https://github.com/ChimeraOS/frzr
frzr is a deployment and automatic update mechanism for operating systems. It deploys pre-built systems via read-only btrfs subvolumes, thus ensuring safe and atomic updates that never interrupt the user.
Updated system images are downloaded at boot time and deployed to an entirely separate subvolume so as not to interfere with the currently running system. Upon next boot, the newly installed system is started and the old one is deleted, completely seamlessly and invisibly.
Persistence is handled by making /home and /var separate subvolumes mounted into the read-only root. /etc is made read-write via overlayfs.
Goes in the direction I mean. But I'd like to use filesystem image files rather than btrfs subvolumes.
Yes, that might be just what we need. As for the btrfs thing, we might be able to fork it...
Yes, and that's why we could fork it. ZFS is welcome, right? And that naturally uses a similar but more flexible subvolume system. So, could we not fork it and add ZFS support?
Or yeah, there's the option of having ufs2 images that can be downloaded, that may be better.
Also I want my Firefox updates ;~)
I tried bundling Firefox, but it's one of those apps that's damn near impossible to compile on a relatively slow computer, on FreeBSD. I might have a look at the port, see how they do it, I might be missing a compiler option.
As for Firefox, it shouldn't be too hard to make Application Bundles for each version. It shouldn't even be neccessary to re-compile it, it should be doable by using the pkgs as ingredients.
Oh, I posted it on a separate issue.
Basically, updating Firefox updates Inkscape, python and Thunderbird, uninstalls krita and removes Qt, which explains why krita went but hey, now the system doesn't boot because my display manager crashes cause of no qt libraries.
Quick hint: Entering h something in Falkon will search for "something" in all helloSystem GitHub repositories.
https://github.com/search?q=org%3AhelloSystem+author%3Akettle-7+Firefox&type=Issues | https://github.com/search?q=org%3AhelloSystem+commenter%3Akettle-7+Firefox&type=issues @kettle-7 I can't find it. If not Firefox, what was the keyword?
FreeBSD PkgBase
https://github.com/helloSystem/hello/issues/37#issuecomment-751341802
https://github.com/helloSystem/hello/issues/161#issuecomment-927250627
https://github.com/helloSystem/ISO/issues/166