Re: speeding up installs
On Mon, Jun 10, 2019 at 12:56:53PM -0400, Sam Hartman wrote:
> >>>>> "Adam" == Adam Borowski <kilobyte@angband.pl> writes:
> Adam> On Sat, Jun 08, 2019 at 10:23:08PM +0200, Jonathan Carter wrote:
>
> So, d-i over serial is important and is likely to stay that way.
>
> If I'm actually having to interact with an installer, I prefer an
> accessible GUI most, a CLI second and a TUI third.
>
> But the community of blind users has disagreement on this issue. I got
> flamed fairly aggressively for suggesting that perhaps Amazon didn't
> really need to care about the accessibility of Kindle on text web
> browsers for DOS given that it worked fine on Firefox on Debian.
That's valuable info, thank you. It's also interesting that you prefer
CLI over TUI -- which I guess makes sense, as a text-to-speech device can
interpret the former better.
If I were to make a new installer today, I'd use text mode, at least in
first versions. GUI can do strictly more than text (proof: it can render
the text with pixel-to-pixel accuracy, then improve about that), but our
current d-i doesn't use any such features. All the graphical d-i does is
support non-Latin writing scripts, in an unwieldy debconf based scheme.
The text console is restricted to 256/512 characters at one time only
because of some ancient hardware. Modern graphics drivers for x86
conflict with vgacon, ARM never had vgacon in the first place, and serial
consoles support anything the real display does, thus there's no reason to
stick with ASCII/ISO-8859-1. I've personally helped review (now
mainlined) patches to support Unicode in vt's internal view; there's also
a non-upstreamed patch to actually draw cell-based scripts (ie, all
non-combining non-shaped ones).
But, I have no intention, skills nor tuits to overhaul the installer's
interface at this time.
> But if I'm interacting with an installer something has gone horribly
> wrong. I guess I do tend to run debootstrap on a live system to install
> my laptop. But for everything else I've used something higher-level.
Yeah, and extended debootstrap is the backend level I'm looking at.
> Most debian systems are not installed with d-i. When you include things
> like FAI for installing sites and clusters; chroots, containers, VMs,
> etc, d-i is not used in most situations.
> So I'd argue that in the long run we actually want the speed
> improvements at a tool at about the deebootstrap level.
I do more than debootstrap, less than d-i. The best equivalent is
"debootstrap && chroot target apt-get install task1 task2 task3".
Ie, a completely CLI stage that's usually wrapped over.
> You've made some good arguments that the interface of such a tool needs
> to change significantly based on your findings. But I want these speed
> improvements for fai, fai-diskimage, all the other image creation tools,
> as well as d-i runs.
I raised the issue of interface only because my design doesn't allow
incremental install that d-i does. You give it either a pile of .debs or
a list of "goals" passed to apt -s; the goals must be given all at once.
I don't care if the goals form minbase, a buildd+deps, or a complete
system with every DE we have -- it's a low-level tool that's glorified
NIH dpkg.
As it uses apt for some tasks, it might be easy to steal code from
mmdebstrap to have its goodies. But in general, the scope is to install
all .debs in the target system than just minbase.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄⠀⠀⠀⠀ agriculture, towns then cities. -- whitroth on /.
Reply to: