[debian-derivatives dropped from cc]
[93sam, pabs added to cc] [0]
nick black left as an exercise for the reader:
Christian PERRIER left as an exercise for the reader:
Quoting nick black (nick.black@sprezzatech.com):
As said, you can find a growlight udeb in the SprezzOS repositories, where it
is actively used in our d-i-derived installer:
It's quite likely that the first step is then to have growlight in
main Debian, isn't it?
Indeed. I will file an ITP.
sorry to revive an eight-year-old thread, but there has recently
been news on this front =]. you might find a web archive useful
for context [1].
growlight (as a deb, not an installer component) was admitted
into the archive last year, and shipped today as part of
bullsye:
https://packages.debian.org/testing/source/growlight.
i have been actively maintaining and extending it for the past
decade, thought the SprezzOS derivative from which it originated
is long defunct.
debconf21 allocated twenty minutes to discussing this idea [2],
and i thought i'd bring it up here so as not to surprise anyone.
my main arguments for why it might be worth looking at include:
* features and new technologies are added to growlight as they
emerge as a natural part of its post-install development [3],
whereas partman presumably requires fresh dev effort for any
feature desired in the installer.
as an example, creating btrfs aggregates requires some
conceptual work, some minimal ui work, and some minimal
integration, independent of system installation. growlight
would gain this functionality as due course, as disk
management is its raison d'ĂȘtre, much more so than it is d-i's.
* can present dynamic information about multiple devices
simultaneously, and perform most actions in parallel. running
e.g. concurrent mkfs operations can be displayed and managed.
* partman AFAIK only gets run during installation, not in the
course of system administration. it is thus possible that
growlight would get more and/or more varied testing.
* it's already been built as a udeb and used as a partman
component, and proven out in the d-i context (see video proof
at [4], admittedly from 2013). so we could just start messing
around with it pretty much tomorrow.
of course, there are plenty of reasons why a change might be
undesirable, and i hope to address many of them in my talk. most
concerning to me is preseeding, which i would be very hesitant
to either (a) invalidate or (b) recreate.
so i hope you all watch the talk! hopefully it won't be a grand
waste of everyone's time.
--nick
[0] sam because he's the current QA contact for partman, paul
because he was so active on the derivatives list.
[1]
https://lists.debian.org/debian-boot/2013/02/msg00122.html
[2]
https://debconf21.debconf.org/talks/3-proposing-a-new-d-i-disk-preparation-tool-growlight/
[3]
https://nick-black.com/dankwiki/index.php/Growlight#Some_capabilities
[4]
https://nick-black.com/tabpower/growlight-return-of.mp4
--
nick black -=-
https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEmi//dHmU4oe+xCLxX0NADCHL+swFAmEYEScACgkQX0NADCHL +szkOg//fB83N3jH2UlHyFaXEmVCJn8M4fOLIeFqIyTQvpvtZo8O0cG7TZQTePEi H744/rA/+kMMJ2eYv+rhduKWP9VdK6Z8M6PRbPh1CfKuzcuo8PQHlk+BiCT1FPDb lNH6HQKRkCB4Jhry5icuwE8xPheuFQH4peEe4dgnx36HnoyptWWpRZDOuAKcsQfg hik0hKTqluKV2oawPUbYlUVwUtxkNwFLw5amiXHJq9eq3BdWW/2Yc5Bl5/AxXjyw IyFd9jOS1n2Ym/wkj3peZRohmCNp3L8iEk/oyUN5+CrXVstmNTHVwFzHhNR8MDtJ nZf7EU6jXun+W5FPgWiRxaDnpFoKXWJrw9OnkhAV9FFgwQpx0dR8EqWyJO4ELemF XWtgIuTK8BhKrsYKhvvZz4+R+L7EKB1PxHlPZMKE39OB9aqlq2Y1hyM95dOQTGke 3LCUl0f3D1rhS8byjZQURGpPoYm2QrcR+E5K/LnWjqygjUmKE2p6Ij7lU1KkKMZB 9xSBMFH1OyfvpChy/jidTPsQH+hj8If4Eqh8b1rFmXX9zQ6Qz7dosLUrJleooU/r AVsL1o+A4PnM4PFSGCon2D8AnYmimZbi0QxQ709dCXRem+JdTsjpNl8491zOIBzC 1TPLX/mJOAw7a1WvX77m4kDlVE/sdvltCINDA3WQARmdR+8pT5o=
=SZZS
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet G