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

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

Re: Proposal for a Modernized Debian Installer

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Thank you for taking the time to read and respond to my proposal. I
understand that many of these points have been raised before and that the
complexity behind them is significant.

I want to clarify that these were not demands but observations from the
perspective of a new developer. Debian was my first stable Linux
distribution after spending a lot of time on Arch, and the installer was
genuinely one of the annoying parts of that transition. My suggestions were
written with that experience in mind, specifically hoping to make the first
contact with Debian easier for people who are learning.

I am not in a position to contribute right now, but I do hope that the
installer can be revisited with new developers and beginners in mind. Even
small improvements to guidance during installation could make a real
difference for someone encountering Linux seriously for the first time.

Thank you again for your time and for the work you and the rest of the
Debian team put into the project.

With kind regards,
A Debian user

On Sun, 12 Apr 2026, 21:08 Andrew M.A. Cater, <amacater@einval.com> wrote:

> 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 | 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