Per-System Config Generation

[JayRovacsek]

Within the README TODO section, visualising features such as disko and impermenance are noted; does the project have a pathway already considered to visualising those functionalities that could be contributed to by the community if desired?

A few questions that might already be considered:

• where would these be rendered?
• would this space open up further visualisation of host configration options that aren't classical services as are currently rendered? (e.g systemd services visualisation, DE/WM visualisation, boot opinions such as systemd/grub/uboot)

Thanks in advance!

[oddlama]

In my first drafts I had very rudimentary disk visualization via disko, but ultimately removed it for now because visualizing the whole partition table wasn't super easy regarding rendering, and it would require a lot of space on the card. Especially when you start considering zfs datasets or pretty much anything that goes beyond the partition table.

Traversing the whole hierarchy of things declared with disko essentially means re-implementing a lot of stuff disko does. Imagine how hard it would be to render a luks encrypted mdadm raid5 that lives on several disks. There are too many possibilities. I guess the sensible thing to do for now would be to display the known disks and maybe the GPT partition table, but nothing beyond that. Even GPT partitions are going to be some pain to render visually.

And regarding the visualization: I generally think the way forward is to somehow differentiate between a detailed view and normal view. The normal view is already getting pretty big so it should probably just contain services and networking stuff and maybe a list of disks similar to the network interface icons. The detailed view can then have anything that goes beyond that. There we can also add auxiliary information like what you are proposing above.

[JayRovacsek]

Agree! Thanks for the response, if I can get a moment to contribute a PR that adds elements like described above I'll try to remain aligned with what you've suggested :+1:

In terms of the previous code you'd implemented elements of disko with - I haven't searched super hard through history, but can't see it for now; is it possible the code might be a good starting point for any future PRs or do you think work in that space would be better starting from scratch again?

[oddlama]

Nothing that could be reused I'm afraid, I never committed the draft into this repository. It really didn't do much apart from extracting disk names, so starting from scratch is probably easiest.