Layers / variations:
[Mostly from lowest to highest:] A bundle of choices of the last 4-5 items and some apps usually is called a "Desktop Environment" (DE): GNOME, GNOME Flashback, KDE Plasma, Xfce, LXDE, LXQt, Cinnamon, MATE, Enlightenment/E, Pantheon, Trinity, Budgie, Unity, Deepin/DDE, Razor-qt, Sugar, UKUI, PIXEL, Equinox/EDE, etc. article1, article2, article3

From someone on reddit:
"A DE gives you an overall user experience. It has the panels, the system menus, the starters, the status applets. It has a window manager. It might offer a default file explorer and viewer. To streamline, it might even contain default editor, terminal program, or even e-mailer, all made to look alike and work together."

Distributions (distros):
A distro is a set of choices of layers/parts/policies, all packaged together under one label.

Some major distros: Debian, Fedora, Red Hat, Ubuntu, Xubuntu, Linux Mint, openSUSE, etc.

Debian Family Tree (!)
Which is just part of a bigger GNU/Linux Distributions Timeline (!!)

Other pieces that usually vary by DE:

Other pieces that often vary by distro or distro-family:
Things that vary less often, or vary only from one distro-family to another:

Some other variations or modifications, some of them user choices:


Newbie questions:

More-complicated things you can do:

See my "Moving to Linux" page

Linux Myths

From 4/2000 interview of Rob Young, founder of Red Hat:
There are two big myths about the business, and the first is there is a single Linux operating system. Linux is a 16-megabyte kernel of the 600-megabyte operating systems that companies like Corel and Red Hat make. Linux might be the engine of your car, but if you plunk an engine in your driveway, you're not going to drive your kids to school.

Our job is making people understand this revolution is about open-source software and it is not about Linux at all. Linux is simply the poster boy for this movement. The other myth is that Linux is being written by 18-year-olds in their basements when actually most of it is being written by professional engineering teams.
Dawn Foster's "Who Contributes to the Linux Kernel?" (1/2017)

Another myth is that "free" software and "open-source" software are identical concepts.
Mark Drake's "The Difference Between Free and Open-Source Software"

Linux Truths


If you want to contribute to the Linux community:

You could pick an app or distro and:

Jason Evangelho's "8 Ways To Contribute To The Desktop Linux Community, Without Knowing A Single Line Of Code"
wikiHow's "How to Contribute to Open Source"
KillYourFM / contribute-foss
Open Source Guides' "How to Contribute to Open Source"
LTP - Linux Test Project
See "Reporting Bugs" section of my "Using Linux" page
Shubheksha's "How to find your first open source bug to fix"
Davide Coppola's "How to contribute to an open source project on GitHub"
Elizabeth K. Joseph's "4 ways I contribute to open source as a Linux systems administrator"
Quora discussion "How do I start contributing in Open Source projects?"
Sarah Drasner's "How to Contribute to an Open Source Project"
Command Line Heroes' S2E3 "Ready to Commit" (audio)
Debian's' "How can you help Debian?"

For development, start with an app, DE, or distro you use:

First, become a very good user:
  • Use the software, explore the features, read the docs and Help.

  • Update to the latest version, or the beta version.

  • File bug reports, and read the open issues/bugs.

  • Join the user forum or group or reddit sub.

kamranahmedse's "Getting Familiar with Unfamiliar Codebase"

Development things to realize:
  • Probably you will be stepping into a project that has a 20-year history, an enormous base of scripts, code, docs, and issue-tracking, and a big somewhat-changing team of developers.

  • It will take time to learn the code and tools and style.

  • Flitting from one project to another may be difficult, if they all use different tools and languages etc.

  • People-issues and process will be very important; follow the rules, be humble, start very small.

  • If a project seems stalled (2 years since last release, bugs open for a long time, pull/merge requests outstanding for a long time), or going through a huge transition, or very undocumented, or broken in some way, maybe stay away (at least as a first project to join).

Big projects often have extensive guides for developers:

GNOME Wiki's "Building system components"
KDE Community Wiki's "Get Involved"
Linux Mint Developer Guide
Debian Developers' Manuals
What can I do for Mozilla
What can I do for LibreOffice
What can I do for Fedora ?

From someone on reddit:
Anyone suitably capable can become an Ubuntu developer! ...

You start by providing fixes for existing Ubuntu developers to sponsor. Once you have a track record of good work and your existing sponsors are willing to endorse you, you can apply to become an Ubuntu developer yourself. ...
Ubuntu Packaging and Development Guide

Check the plans/roadmap for the unit you have chosen, to see the priorities, and what other people may be working on:
linuxmint / Roadmap

Find out the developer communication channels (mailing list, forum, bug-tracker, IRC, whatever) for the unit you have chosen, and join those channels.


Konrad Zapalowicz's "Three Ways for Beginners to Contribute to the Linux Kernel"
Adam Zerella's "How to become a Linux kernel developer"
Jason Wertz's "Kernel Basics" (video) (2013 but interesting)
torvalds / linux "HOWTO do Linux kernel development"
Linux Kernel Newbies
Arch: KernelBuild
Tamir Suliman's "Beginner's Guide to Writing your First Linux patch"
Sayli Karnik's "A checklist for submitting your first Linux kernel patch"
Kosta Zertsekel's "Who should I sent Linux Kernel patch to?"

Ashish Vara's "Kernel Architecture Of Linux (Part 7/15)"
Wikipedia's "Linux kernel - Architecture"
linux-kernel-labs' "Overview of the Linux kernel"

The Linux Kernel documentation
torvalds / linux (Linux kernel source tree)
Plailect / linux-devel (kernel development using VSCode and libvirtd)

To get a copy of the kernel source locally: "sudo apt install linux-source" and "ls /usr/src". You'll get a file "linux-source-NNN.tar.xz". Then maybe "mkdir ~/kernel && cd ~/kernel && tar -xaf /usr/src/linux-source-NNN.tar.xz"

Hcamael's "How to Develop Linux Driver from Scratch"
Corbet, Rubini, and Kroah-Hartman's "Linux Device Drivers, Third Edition"

From someone on reddit:

> I want to take a stab at creating a couple of GUI Linux apps to improve
> the usability of some parts of the system that are locked to CLI.

Honestly, coding probably isn't going to be the lynchpin issue you'll run into.

Most projects are ruled like fiefdoms, some are more reasonable/practical than others and as a result allow for more broader contributions, but you still run into issues where maintainers/developers will not accept or consider certain features because it either violates their vision or ethos for what they think their creation should be, or they don't want to support features they aren't interested in (desktop icons disappearing from Gnome3 is a prime example), whatever the case it's not a coding issue, the biggest problems with OSs are people issues.

Please don't create a new distro:
Please don't create a new distro. We have far too many already. GNU/Linux Distributions Timeline

If you want/need something, do it some other way. A configuration script that modifies an existing distro. A new DE or theme. A new kernel module. Whatever is appropriate for your need/idea.

Of course, if you have some great new world-beating idea that just can't be done in an existing distro, go for it ! But expect lots of work and little audience. Better if you could implement your idea in some major distro such as Ubuntu, and get it out to millions of users.

Make a Linux App

Linux is suffering from Fragmentation:
See "Fragmentation" section of my "Linux Problems" page.

Standards / projects / groups:

Plenty of huge companies (Intel, Microsoft, Google, Samsung, more) and smaller companies/foundations (Mozilla, Apache, more) contribute to Linux and FOSS.

Some subsystems have come from various corporations: CUPS (Apple), ZFS (Oracle).

Unix Family Tree

The CLI (terminal-and-shell; Command-Line Interface):

Where there is a shell, there is a way.
From procabiak comment on Guide: Migrating to Linux in 2019:

Stop recommending the command line to beginners. Disclaimer/tl;dr: I like the command line, use it every day, but it's not the user-friendly tool you make it out to be. It's a tool for veterans, power users, tech-savvy folk. It's dangerous in the wrong hands.

This is a Linux/nix culture we need to move away from if Linux is to be successful mainstream. There's a reason many distros have a GUI for package management. If everything was indeed easier on a command line for every user demographic, why waste time implementing the GUI package manager, just tell everyone to use the terminal, right? Wrong! (IMO)

There're people who don't speak English or have difficulty with spelling even the simplest words, people with typing disabilities, older aged people, children ... Just to name a few, but all who just want to enjoy a game without needing to learn the complexities of Linux or us vets pushing that need onto them.

With a GUI package manager, you don't need to know anything beyond the ability to explore, click around to find stuff you need, etc. Often times you'll find other software you didn't think about wanting. The guide already states package managers are akin to app stores. These days everyone knows what an app store is (well, I make the assumption - there are people who have never owned smartphones before), so it's not as difficult a concept as it used to be, so we can use fewer words to explain it. The instructions are pretty simple: "open the package manager (app store) from the menu, search for steam and click install, enter your password and click OK". It's not faster than a command line, but it's simpler for many people. The instruction is nearly universal for all distros, even if the GUI looks or behaves slightly differently.

Contrast with apt, yum or pacman. You'd also need to learn to use grep to get anything remotely useful out of their list-package outputs. You can't explore - you just execute a command like sheep and hope you really just installed steam from Valve and not some other kind of steam. And when it comes to instructions, you need more words to explain the command line (that many people are omitting): "open the Terminal, type sudo apt install steam, type in your password (it shows up blank but your password is really there, keep typing), press enter, then type Y and press enter" ... Not only that, that command only works for Debian-based distros using apt. It will confuse Fedora and Manjaro novices using yum or pacman (they might even try to install apt, just to be able to run your command!).

You can also very easily mislead a novice to run dangerous "sudo rm -rf /"-like commands. I assume it's backwards to suggest to the user to understand the command before executing it when they are learning the command in the first place, so we can't assume the novice user will know what every command does. Therefore I can maliciously explain that line means "sudo = as a superuser, rm = remind me, -rf = to read from, / = root", for example. If I am their only reading material, I've just tricked a user to wipe their OS, imagine what else you can do to that novice by exploiting shortly-named commands?

The reality is command lines are simpler for the person offering help, but not necessarily for the person on the other end.

From grady_vuckovic comment on Guide: Migrating to Linux in 2019:

I have experience in converting people to Linux and that terminal is absolutely poison. When I show a typical Windows user an OS like Linux Mint, they are interested until they see the terminal, then groan and lose interest immediately.

Even if GUIs change, it is still waaaay easier for a new user to figure out a GUI with obviously labelled buttons, text boxes and tabs, than figure out how to use a terminal.

Try to put yourself in the mindset of a person who has only ever used a computer for homework, Facebook, job-hunting, Amazon, and who mainly uses a smartphone for all their computer needs. A terminal itself is a foreign concept and not a pleasant one.

On most decent software managers for Linux distros, the GUI is mostly pretty self-explanatory, with a simple search box for finding new software. That's pretty easy for a new user to figure out how to use.

But it is almost impossible for them to figure out what 'sudo apt steam' means at a glance, (and no, taking the time to explain it doesn't help, it will likely result in a 'wait wait I just want to install an app, why do I need to know all this rubbish?') or figure out where they need to go to type it, because if your user doesn't know where the software manager is, they certainly don't know where the terminal is or how to use it, so for all you know they could end up typing those commands into a search box somewhere. Not to mention it's difficult for them to even remember something like that.

And when I say "how to use it" regarding the terminal, I mean that literally. I've seen new users half type in commands, causing the terminal to enter a mode of waiting for the rest of the input of the command, then they can't figure out why it isn't working as they type in more and more commands, and other frustrations. It is truly a TERRIBLE user experience and one that should only be reserved for veteran Linux users.

Also keep in mind, users like to install and uninstall software, how on Earth is a user meant to figure out how to uninstall software which they installed with 'sudo apt'? There's no list of installed software they can look at, no buttons to click, no GUI to navigate, all they can do is hopelessly start Googling for help on how to use apt commands (that's an appallingly bad user experience for someone new to Linux) or (more likely) just get frustrated and decide "Linux is rubbish!" and switch back to whatever they were using before.

On top of that, it looks pathetically antiquated in 2019 to use a terminal to do such a simple basic OS operation as installing software or installing some drivers.

It may be easier for you to give instructions in terminal commands, and the terminal may be easier for you to use than a GUI, but it is scaring away possible Linux converts. For Ubuntu at least you should include instructions on how to navigate to the Software Manager.

I personally wouldn't offer any advice at all for Linux newbies that includes terminal commands unless you're trying to scare them away from Linux.

My thoughts:

"Terminal" is not same as "shell":
Terminals: gnome-terminal, konsole, guake, rxvt-unicode, aterm, xterm, kitty, alacritty, tilix, terminator, PuTTY, more.

Shells: sh, csh, bash, fish, zsh, ksh, more.

Expression of Change's "CLIs are reified UIs"

Package formats and managers:

Format Distros Binary Managers
rpm Red Hat, Fedora, CentOS, SUSE, Mageia rpm, yum, dnf, zypper, YaST, urpmi, Drakrpm
deb Debian, Ubuntu, Mint dpkg, apt, apt-*, aptitude, Synaptic, wajig
tgz/txz Slackware, VectorLinux, Zenwalk pkgtools, slackpkg, slapt-get, Swaret, netpkg
pkg.tar.gz Arch, Manjaro ? pacman, pamac ? AUR helpers: yay, yaourt, apacman, pacaur ?
tbz2 Gentoo, Sabayon emerge/Portage, entropy, equo
nix NixOS nix
xbps Void xbps
Solus eopkg
Intel Clear Linux swupd
Some front-end managers that work on top of multiple package formats: smart, PackageKit.

Combination package manager / configuration manager ? GNU Guix

Devopedia's "Package Manager"
DistroWatch's "Package Management Cheatsheet"

Dedoimedo's "Broken apt, missing dependencies, what now?"

From /u/Linux4ever_Leo on reddit:
Honestly, there really isn't anything stopping the Linux world from standardizing on one single package management system except for egos. Each distro line deems its own package management systems to be the "best". Red Hat derived distros use RPM packages; Debian derived distros use DEB packages, Slackware uses good ol' tarballs. Gentoo and Arch prefer sources based packages. Still other distros have developed their own proprietary ways of managing packages. In short, it's sort of a mess. ... Personally, I don't care what sort of package manager wins the game so long as SOMETHING is standardized which will help further the widespread adoption of software on Linux and make things easier for developers to port their software to the Linux platform.

There are a couple of other levels of "management":


Desktop Environments (DEs):

probono's "Make. It. Simple. Linux Desktop Usability" (series of 6 articles)

Boot process:

Basic steps:
  1. Hardware power-on.
  2. System firmware.
  3. Bootloader (3 stages).
  4. Kernel (initial/temporary root filesystem, and then real root filesystem).
  5. OS Init.
  6. OS GUI.

  1. Hardware power-on. Power supply sends signal to rest of hardware when power is stable.

  2. Firmware / controllers startup:

    1. CPU starts executing code (firmware) in ROM, and consulting stored values in CMOS or NVRAM.
    2. If there is a "management engine" on the board, it starts up too, with its own code, and may start running a TPM which creates an audit trail (recording such things as hash value of firmware contents).
    3. There may be a Hardware Security Module (HSM) which stores crypto keys and can execute crypto algorithms, or even custom algorithms. It has to start up.
    4. There may be micro-controllers / boards which start up too, using their own internal processors and ROMs/NVRAMs. Keyboard controller, disk controllers, GPU, network interfaces, etc.
    5. It's likely that CPU microcode will be loaded.
    6. CPU code initializes hardware, does self-test (POST), displays manufacturer logo, etc.
    7. Some functions (e.g. RAID, video, hardware-encrypted disks ?) may have interactive setup functions in ROMs that have to be executed by the main CPU. So the main firmware may jump into these "Add-On ROMs" to do that processing, then control returns to the main firmware.

  3. Code checks CMOS/NVRAM settings, and looks for key-presses from user, to see what to do. Could go into setup menu, go into menu of boot devices, or step down list of boot device types and look for bootable devices.
  4. A boot device is found or specified.

  5. [Following will assume 512-byte sectors on disk.]

  6. MBR (Master Boot Record) is read from sector 0 of boot device into RAM.
  7. The "post-MBR gap" is the disk space after MBR sector and before first partition. This is at least sectors 1-63 (31.5 KB), but more likely to be 2047 sectors (almost 1 MB) in modern disks.

  8. [Following generally outlines Ubuntu/GRUB2 situation.]

  9. Selecting a kernel:

    If firmware is Legacy BIOS (Basic Input-Output System) and disk has MBR partitioning:

    1. Stage-1 bootloader code (in GRUB, AKA boot.img) is in first 446 bytes of MBR (actually, last few bytes have other uses, so typical limit is 440 bytes). [That small amount of code can do the boot menu and a few basic commands, by calling functions in the BIOS.] Partition table (4 entries; primary partitions) starts at byte 446 and is 64 bytes. Then 2-byte magic number (0xAA55).

    2. Control jumps to start of MBR (start of stage-1 bootloader) in RAM.
    3. If stage-1 bootloader is for Windows, it would load a Volume Boot Record (VBR) which contains an Initial Program Loader (IPL), which would then load NT Loader (NTLDR). But we're assuming Linux and GRUB, so:
    4. Stage-1.5 bootloader code (AKA core.img) is in "post-MBR gap" after MBR sector and before first partition.
    5. Stage-1 bootloader copies stage-1.5 bootloader from post-MBR gap into RAM.
    6. Control jumps to start of stage-1.5 bootloader in RAM.
    7. Stage-1.5 bootloader finds partition in partition table that is marked as "active".
    8. Stage-1.5 bootloader is big enough to understand common filesystems such as ext*, FAT, NTFS.
    9. Stage-1.5 bootloader copies stage-2 bootloader files from /boot into RAM.
    10. Control jumps to start of stage-2 bootloader in RAM.
    11. Assume stage-2 bootloader is main body of GRUB (really, GRUB2).
    12. Which stage is smart enough to know about LVM, RAID, dm-crypt, LUKS, etc ?
    13. GRUB finds partition in partition table that is marked as "boot".

    14. GRUB reads /boot/grub/grub.cfg configuration file.
    15. GRUB may present a menu of kernel images and utility options, or just select a default kernel image.

    Else if firmware is UEFI (Unified Extensible Firmware Interface) and disk has GPT partitioning:

    1. First 446 bytes of MBR are ignored (actually, last few bytes of that space have other uses, so might be used). Next 64 bytes are ignored (actually, they're set to "protective values" showing one full-disk partition of a special type, so the disk looks full and strange type if someone tries to use an MBR utility against this GPT disk). Then 2-byte magic number (0xAA55).
    2. GPT (GUID Partition Table) is in "post-MBR gap" after MBR sector and before first partition. Sector 1 of disk is the GPT header, and has a pointer to the partition table (Partition Entry Array), which typically starts at sector 2.
    3. Boot parameters are in NVRAM.
    4. UEFI firmware understands at least FAT12, FAT16, and FAT32 filesystems, optionally may understand more.
    5. One of the partitions in the GPT has a unique GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) that identifies it as the EFI System Partition (ESP). The filesystem in that partition is specified as FAT-like. It usually ends up mounted on /boot/efi after Linux has booted.
    6. UEFI firmware can launch an application (bootloader, boot manager, utility, shell, more) from the filesystem in the ESP. That can include a Compatibility Support Module (CSM) application to do a legacy BIOS boot using the stage-1 bootloader in the MBR. One standard EFI application is MokManager ("mm*.efi"), which manages keys. Another EFI application is GRUB ("grub*.efi"). Another EFI application could be a direct-launch kernel (using EFISTUB; EFI boot stub). Another EFI application could be a boot manager (systemd-boot, or rEFInd).

    7. UEFI firmware may present a menu of EFI applications and utility options, or just select a default application, or fall back to \EFI\BOOT\BOOTX64.EFI.
    8. Assume "grub*.efi" was chosen.

    9. If Secure Boot is enabled, verify authenticity of the EFI binaries by signatures. Uses certificates and hashes, blacklist database (DBX) and whitelist database (DB) and Key Exchange Key(s) (KEK) and Platform Key (PK), Machine Owner Key (MOK) and MOK Blacklist (MOKX), Secure Boot Standard Mode-ready bootloader SHIM. Signatures generally are provided by Microsoft. For Linux, there is a shim binary ("shim-signed"; signed by Microsoft; contains a cert from Canonical) and a GRUB binary (e.g. "grub-efi-amd64-signed" or "grub-efi-arm64-signed"; signed by Canonical) to get through this process. Secure Boot has various modes including full, fast, minimal, custom. Various paths if checks fail. If available, TPM operates as a passive observer (creating audit trail) of all phases.

    10. GRUB reads configuration from ESP (EFI System Partition).
    11. That config file points to /boot/grub/grub.cfg
    12. Which stage is smart enough to know about LVM, RAID, dm-crypt, LUKS, etc ?
    13. GRUB reads /boot/grub/grub.cfg configuration file.
    14. GRUB may present a menu of kernel images and utility options, or just select a default kernel image.
    15. If Secure Boot is enabled, verify authenticity of the kernel image by signature etc. Initrd image is not validated.

    It's possible to have Legacy BIOS firmware boot a disk that has GPT partitioning (known as "BIOS/GPT boot"), but I'm skipping that.

    It's possible to have UEFI firmware boot a disk that has MBR partitioning and an ESP (identified as partition ID 0xEF), but I'm skipping that ("UEFI/MBR boot").

  10. GRUB copies compressed kernel image (executable zImage or bzImage file; e.g. /boot/vmlinuz-NNN) into RAM.
  11. GRUB copies initrd (AKA "Initial RAM Disk") into RAM. The image can contain anything, but probably is a microcode blob followed by a cpio archive of kernel modules (from /boot/grub/i386-pc) including LVM and LUKS modules, encryption modules, filesystem modules, USB modules, video modules, etc.
  12. Control jumps to start of compressed kernel in RAM.

  13. Start of kernel has some code that decompresses the rest of the kernel (for ARM64 and some others, it was done by GRUB).
  14. Possible that CPU microcode could be updated at this point, using microcode compiled into the kernel image.
  15. Kernel sets up memory-management, floating-point, interrupts, and other low-level things.
  16. Kernel creates an empty initial root filesystem (rootfs) in RAM. Then files are copied to rootfs, first from an initramfs embedded in the kernel binary during the kernel build, then from the initrd (Initial RAM Disk) in RAM. Both of those often are in cpio format, but many formats and variations have been used. Maybe it's more accurate to call them "archives". On Ubuntu 20, the initrd is almost empty, so the initramfs must have most of the files.
  17. Kernel loads modules/drivers as needed from root filesystem (rootfs). If Secure Boot is enabled, verify authenticity of the modules by signature etc.
  18. On Ubuntu 20, there is a CPU microcode file in initrd, so CPU microcode must be applied at this point ? I assume Secure Boot also checks that.
  19. Initialize virtual device systems such as software RAID, LVM, ZFS, NFS.
  20. Kernel mounts real root filesystem, replacing temporary rootfs.

  21. Kernel creates scheduler process (pid 0).
  22. Kernel executes /sbin/init, creating init process (pid 1; first user-space process).

  23. Init:

    If /sbin/init is standard/old init application, init process mounts non-root filesystems as specified in /etc/fstab, then reads /etc/inittab file to find out what to do, or processes all of the /etc/init.d/* files.

    If /sbin/init is a symlink to /lib/systemd/systemd, systemd process mounts non-root filesystems as specified in /etc/fstab, then uses files under /etc/systemd (including /etc/systemd/system.conf) to decide what to do. Maybe uses info from GRUB that specifies starting target under /etc/systemd/system/: default, rescue, emergency, cloud-final, more ?

  24. Init code sets up windowing system, starts cron, starts getty's, sets up networking infrastructure, maybe connects to networks, start print server, start audio service, etc.
  25. Init code could load microcode into CPU and other processors, using files in /usr/lib/firmware. "journalctl -k --grep='microcode'" to see log entries about updates.
  26. Eventually init code runs login manager, which presents a login screen to the user.

Ramesh Natarajan's "6 Stages of Linux Boot Process"
Narad Shrestha's "A Basic Guide to Linux Boot Process"
Sarath Pillai's "Linux Booting Process"
David Both's "An introduction to the Linux boot and startup processes"
Wikipedia's "Linux startup process"
Arch Wiki's "Boot loader"
NeoSmart Knowledgebase's "The BIOS/MBR Boot Process"
Debian Reference's "Chapter 3. The system initialization"
"man bootup"

Wikipedia's "GUID Partition Table"
Wikipedia's "EFI system partition"
Arch Wiki's "EFI system partition"

Ubuntu Wiki's "UEFI / SecureBoot"
NSA's "Boot Security Modes and Recommendations"
"sudo mokutil --sb-state" [NOT SURE WHAT THIS DOES]

When booting, hold down Shift key to get into GRUB menu.
GNU GRUB Manual (or do CLI "info grub")

Rob Day's "initrd and initramfs"
Wikipedia's "Initial ramdisk"