LPIC-1 Internet Protocols, X11 Display Managers, and Accessibility

Every conversation on a network runs over a transport protocol, and the protocol is a deliberate engineering choice — not an accident. The two you meet constantly are TCP and UDP, with ICMP off to the side for diagnostics.

Think of TCP as a registered letter: the post office confirms delivery, re-sends anything lost, and guarantees the pages arrive in order. That reliability costs an exchange of paperwork up front. Think of UDP as a postcard: you drop it in the box and hope it lands. No confirmation, no re-send, no ordering — but also no overhead and no waiting.

• TCP — connection-oriented and reliable. It opens a connection with a three-way handshake (SYN -> SYN-ACK -> ACK) before any data flows, then tracks, acknowledges, and re-transmits. Used where every byte must arrive: HTTP/HTTPS, SSH, SMTP.
• UDP — connectionless and fire-and-forget. No handshake, no acknowledgements. Used where speed beats perfection or where one tiny request/reply doesn't justify a connection: DNS, DHCP, NTP, most streaming.
• ICMP — not for carrying user data at all. It's the network's diagnostic and error channel: ping (echo request/reply) and the "time exceeded" messages that make traceroute work both ride on ICMP.

An IP address gets a packet to the right host; a port number gets it to the right program on that host. Ports 0-1023 are the well-known ports, reserved for standard services so that anyone, anywhere, can reach https by knocking on 443 without arranging it first.

Linux keeps a human-readable map of port -> service name in `/etc/services`. It's a plain text file, so you can grep it — and that's exactly how you settle a "which port is this on, and is it TCP or UDP?" question without memorising the whole list.

An IPv4 address is 32 bits, written as four dotted octets like 192.0.2.10. On its own that's just a number — the CIDR mask is what gives it meaning. A mask like /24 says "the first 24 bits are the network, the rest is the host." Everything sharing your network bits is on your subnet (a local hop); everything else has to be handed to the gateway to be routed onward.

This is the single most useful decision a host makes for every packet: is the destination local, or do I send it to the gateway? The host answers it by masking both addresses and comparing the network parts.

Work an example with the documentation-reserved range 192.0.2.0/24:

• Your host: 192.0.2.10/24 -> network 192.0.2.0
• Destination 192.0.2.200 -> network 192.0.2.0 -> same network -> deliver directly (local)
• Destination 198.51.100.5 -> different network -> not local -> send to the gateway

Now change only the mask. With 192.0.2.10/26, the network block is just 192.0.2.0-192.0.2.63. Suddenly 192.0.2.200 is outside your subnet and must go via the gateway. Same addresses, different mask, opposite routing decision.

IPv6 is 128 bits — four times the width of IPv4 — written as eight groups of four hex digits, like 2001:db8:0:0:0:0:0:1. Two shorthand rules keep that readable:

• Drop leading zeros in each group: 0db8 becomes db8.
• `::` collapses one run of all-zero groups to nothing. So 2001:db8:0:0:0:0:0:1 shortens to 2001:db8::1. The rule that catches people: `::` may appear only once in an address, because otherwise the number of zero-groups it stands for would be ambiguous.

One block matters even on a machine with no internet: `fe80::/10` is link-local. Every IPv6 interface auto-configures an fe80:: address that is valid only on that single link — it is never routed off the local segment. It's the IPv6 equivalent of a name you only answer to inside your own house; it works for neighbours on the wire but means nothing to the outside world. (2001:db8::/32 is the reserved documentation range, the IPv6 cousin of 192.0.2.0/24.)

When a Linux machine shows a graphical desktop, three distinct layers are stacked up, and the exam loves to test whether you can keep them straight:

1. Display server — the software that actually talks to the GPU, draws pixels, and handles mouse/keyboard input. The traditional one is X11 (the X Window System); the modern replacement is Wayland. This is the engine underneath everything graphical.

2. Display manager — the graphical login screen. It starts at boot, presents the username/password prompt, and after you authenticate it launches your session. Common ones are GDM (GNOME), SDDM (KDE), and LightDM.

3. Desktop environment — the windows, panels, and apps you see after login: GNOME, KDE Plasma, Xfce, and so on.

Think of it as a theatre. The display server is the stage machinery and lighting rig that makes any scene possible. The display manager is the box office that checks your ticket and lets you in. The desktop environment is the play you actually watch. Different jobs, easy to confuse because you only ever see the last one.

Whether a machine boots to that graphical login at all is decided by the systemd default target:

• `graphical.target` — boot all the way to the display manager and a GUI login.
• `multi-user.target` — boot to a full multi-user system but text console only, no GUI.

You switch the default with systemctl set-default, and you can check the current setting with systemctl get-default.

LPIC-1 expects you to recognise the standard Linux accessibility (a11y) features and what each one is for. They cluster by the barrier they address:

• Vision — Orca is the screen reader: it reads the interface aloud and drives a Braille display. A magnifier enlarges part of the screen. High-contrast themes and large text help low-vision users.
• Motor / dexterity — the on-screen keyboard lets someone type with a pointer instead of a physical keyboard. Several keyboard-assist modes help too:

- Sticky keys — press modifiers (Ctrl, Alt, Shift) one at a time instead of holding several at once, so one-finger or one-hand users can still do Ctrl+Alt+Del.

- Slow keys — a key must be held briefly before it registers, filtering out accidental brushes against keys.

- Bounce keys — ignores a repeated keystroke that arrives too quickly, helping users with tremor who hit a key twice unintentionally.

Know Orca by name (it's the one most asked) and be able to say what sticky/slow/bounce keys each do — they're easy to mix up.

You have a real shell. Every command here is read-only — it inspects state and changes nothing. Run them in order and connect each result back to the concept it came from.