Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.boot > #77338

Re: Proposal for a Modernized Debian Installer

Show all headers | View raw

On Sun, Apr 12, 2026 at 03:16:11PM +0200, Mehmet Akkus wrote:
> The current Debian installer has not kept pace with modern user
> expectations and increasingly acts as a barrier to adoption rather than a
> gateway to one of Linux's most stable distributions. The following is a
> concrete proposal for a redesigned installer that preserves Debian's
> philosophy while improving the experience significantly.
> 
> 

The current Debian installer covers several architectures, many installation
modes and is not unintuitive when you move from installing on a desktop
machine to a server to a virtual machine or even an ARM-based single board
computer. It works in a very similar way everywhere. If you are visually
impaired the high contrast text mode/speech installer is workable with
some effort :)


> 1. Installer Flow Redesign
> 
> Language, system locale, and keyboard layout should be presented first as a
> group. Root and user credentials should follow immediately after, before
> any system decisions are made, so there is no ambiguity about which locale
> settings a password was entered under.
> 

If you don't have a user, then maybe you don't have a system: users first,
then everything else? Nothing is actually finalised until the very last 
stage. Language, system locale and keyboard layout are potentially 
independent of each other.

> 
> 2. Installation Profiles
> 
> The user should be asked what kind of system they are setting up: desktop,
> server, minimal, or custom. Desktop installations should offer profiles
> such as beginner, developer, gamer, and solo, each pre-configuring sensible
> defaults. A user who selects a profile can still override any decision it
> makes. This would be very helpful for instance when it comes to graphics
> drivers.
> 

This is a *significantly* difficult problem to solve - not least because
a user may not know at the outset. See also the problems of selecting 
tasksel selections.
> 
> 3. A Guided Assistant: Tux
> 
> For non-solo profiles, a contextual ASCII Tux character should appear
> throughout the installation, offering brief and relevant explanations based
> on the user's choices. The guidance should be non-intrusive and skippable.
> A beginner seeing a swap partition question for the first time deserves a
> one-line explanation. An experienced user can ignore it entirely.
> 

An ASCII Tux may not work under certain locale choices / Unicode pages.

> 
> 4. Sandboxed Package Layer
> 
> A sandboxed package layer should allow packages and libraries to be
> installed in an isolated environment that can read from but never write to
> the base system. A developer can use a newer library without risking system
> stability, and if the sandboxed layer breaks it can be removed and
> reinstalled without touching the base system. This preserves Debian's
> stability guarantee while removing one of the primary reasons developers
> reach for other distributions instead.
> 

This is orthogonal to the installer: *which* packaged environment?
There's a reason we say "don't create a FrankenDebian" and fast moving
environments for NPM and so on don't fit any better on Red Hat derived
distributions or OpenSUSE ...

> 
> 5. A Lightweight CUI
> 
> The installer should be a clean console interface, not the current
> low-resolution pseudographical one and not a full GUI. A minimal black
> terminal aesthetic with clear prompts and consistent navigation is more
> professional, accessible over SSH, and more aligned with what Debian
> actually is.
> 

The existing installer is also accessible over SSH.
> 
> 6. System Feature Toggle
> 
> A privileged configuration file, modifiable only by root, should expose a
> clean interface for enabling or disabling major system components such as
> audio, Bluetooth, and network manager. It reduces the cognitive load of
> managing what is running on a given machine and makes it easy to produce a
> lighter system without deep knowledge of every service name and dependency.
> 

This is harder than it looks ... see the issues raised in bug trackers
and mailing lists over the years. If you *don't* understand the service
names and dependencies, it's significantly harder to do.
if it helps, it does seem that at least Red Hat and various Debian
derived distributions seem to be standardising on GNOME as a base so 
that GNOME tools and settings can be used to set system components.

> 
> These proposals are not radical departures from Debian's identity. They are
> targeted solutions to well-known friction points, each designed to make
> Debian more accessible without sacrificing the control and stability that
> define it. Thanks a lot for reading this.

Thanks for writing this: several similar suggestions have been made before.
Without *your* effort, in the same way as the other volunteer developers,
this won't be able to be done. Are you able to contribute towards
realising your wishes?

With every good wish,as ever,

Andrew Cater
(amacater@debian.org) 

Back to linux.debian.maint.boot | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Proposal for a Modernized Debian Installer Mehmet Akkus <mehmetakkus0804@gmail.com> - 2026-04-12 15:40 +0200
  Re: Proposal for a Modernized Debian Installer "Andrew M.A. Cater" <amacater@einval.com> - 2026-04-12 21:10 +0200
    Re: Proposal for a Modernized Debian Installer Marc Haber <mh+debian-boot@zugschlus.de> - 2026-04-12 21:40 +0200
    Re: Proposal for a Modernized Debian Installer Mehmet Akkus <mehmetakkus0804@gmail.com> - 2026-04-13 15:10 +0200

csiph-web