-ENOTTY

Konkludując historię wielkiego nieobecnego btrfsck… Szósty lutego 2012, Josef Bacik:

We're running close to the wire on this but it looks like Chris will have fsck out for btrfs tomorrow

I co? Oficjalnego ogłoszenia nie było, ale fama sie już rozniosła: od dwóch tygodni btrfsck jest dostępny. Mason udostępnił kod w gałęzi repozytorium o nazwie dangerdonteveruse. Użycie oczywiście używanie na własną odpowiedzialność. Bugreporty od osób, które tym narzędziem popsuły sobie system plików będą ignorowane.

Dekadę po wprowadzeniu architektury AMD64 przerobiłem w końcu ostatnią z moich maszyn na dystrybucję 64-bitową. Sprzęt był capable od dawna, ale jego wymiana odbyła się metodą transplantacji dysków ze starego komputera i nie było kiedy zmienić softu.

Procedura jest prosta. Instalujemy kernel 64 bitowy, uruchamiany z niego system z 32-bitowym userlandem i reinstalujemy wszystkie pakiety po kolei w wersjach x86_64. Userland 32 na jądrze 64 działa sprawnie nawet na x86, ale trzeba mieć na uwadze trzy drobiazgi:

Automount ma rozbieżne wielkości strukturki danych między 32 a 64 bity. Owocuje to zawieszeniem w czasie uruchamiania systemu 32 bit na jądrze 64 bit. Pamiętać należy o wyłączeniu automountów przed takim bootem.

RRD nie lubi baz stworzonych na innej architekturze. Tu warto zrobić rrdtool dump do xml na 32 bitach, a po upgradzie rrdtool restore.

PostgreSQL też nie lubi plików baz danych utworzonych na innej architekturze. Podobnie jak z RRD, najpierw pg_dumpall, a po upgradzie initdb i psql -f dump.sql.

Inny soft na razie problemów nie wykazuje. Zapomnienie o zrzutach może zawocować drapaniem się w głowę podczas poszukiwania jakieś jeszcze działającej 32 bitowej instalacji, żeby dokonać ich post factum. Ale na szczęście wystarcza pendrive USB z zainstalowaną 32 bitową instalacją i katalogi baz danych wyeksportowane przez NFS.

Ostatnio przemigrowałem z tgt na nowy, lepszy, wbudowany w jądro LIO. Chodzi o cel SCSI. Po robocie odsunąłem się od monitorów, spojrzałem na stary config, spojrzałem na nowy i naszła mnie refleksja.

Czy przejście z takiego sposobu konfigurowania:

vendor_id UTC FS Support
product_id Linux iSCSI

# Set the driver. If not specified, defaults to "iscsi".

default-driver iscsi

<target iqn.2010-08.com.fs.utc:dvdtmp>
        backing-store /dev/mapper/sabretoothvg-iscsi.dvdtmp
</target>

<target iqn.2010-08.com.utc.fs:winxppp45client-stor1>
        backing-store /dev/sabretoothvg/iscsi.winxppp45client-stor1
</target>

<target iqn.2011-02.com.utc.fs:esxi.local-space0>
        backing-store /dev/sabretoothvg/iscsi.esxi.local-space0
</target>

<target iqn.2011-02.com.utc.fs:fcoe.test0>
       backing-store /dev/mapper/sabretoothvg-fcoe.test0
       allow-in-use yes
</target>

na taki (uwaga, ściana tekstu):

#### Parameters for TCM subsystem plugin storage object reference
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --establishdev iblock_0/iblock0 /dev/sabretoothvg/fcoe.test0
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --setunitserialwithmd iblock_0/iblock0 72ad13f0-c8d2-4d96-bffe-30f9cfc46f2f
#### Parameters for TCM subsystem plugin storage object reference
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --establishdev iblock_1/gilbertus.swap /dev/sabretoothvg/iscsi.gilbertus.swap
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --setunitserialwithmd iblock_1/gilbertus.swap 7e05140f-6536-4813-a1a0-d9fdc3b7bca8
#### Parameters for TCM subsystem plugin storage object reference
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --establishdev iblock_3/esxi.local-space0 /dev/sabretoothvg/iscsi.esxi.local-space0
python /usr/lib/python2.6/site-packages/rtsadmin/tcm_node.py --setunitserialwithmd iblock_3/esxi.local-space0 5bcaffac-6da0-42b0-ad07-fe130609674
#### iSCSI Target Ports
mkdir -p /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_0
ln -s /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_0/../../../../../../target/core/iblock_0/iblock0 /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_0/6efd3cb027
lio_node --aluasecmd iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd 1 0
mkdir -p /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_1
ln -s /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_1/../../../../../../target/core/iblock_4/winxppp45client-stor1 /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/lun/lun_1/1d6312ea35
lio_node --aluasecmd iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd 1 1
#### iSCSI Initiator ACLs for iSCSI Target Portal Group
mkdir -p /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/acls/iqn.1994-05.com.fedora:5f21153a55f
echo 16 > /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/acls/iqn.1994-05.com.fedora:5f21153a55f/cmdsn_depth
mkdir /sys/kernel/config/target/fc
#### fc Target Ports
mkdir -p /sys/kernel/config/target/fc/20:00:00:23:ae:b2:f4:3b/tpgt_1/lun/lun_0
ln -s /sys/kernel/config/target/fc/20:00:00:23:ae:b2:f4:3b/tpgt_1/lun/lun_0/../../../../../../target/core/iblock_0/iblock0 /sys/kernel/config/target/fc/20:00:00:23:ae:b2:f4:3b/tpgt_1/lun/lun_0/b522dc7322

to naprawdę jakiś postęp? Powyżej to drobny fragment, całość ,,nowości'' ma prawie pół tysiąca linii i postać skryptu, który odtwarza ustawienia przez wykonanie wszystkich katalogów i dowiązań symbolicznych.

Do LIO dostępny jest targetcli, będący tak naprawdę kolorową nakładką na mkdir, ln i touch. Ja rozumiem, że wszystko jest plikiem, ale naprawdę zajęło mi pół godziny wpadnięcie na intuicyjny sposób określenia IP, na który jądro ma słuchać. (Tym sposobem jest utworzenie katalogu, dokładniej mkdir -p /sys/kernel/config/target/iscsi/iqn.2003-01.org.linux-iscsi.sabretooth.x8664:sn.aeee2b8d6fdd/tpgt_1/np/192.168.6.9:3260).

Plik konfiguracyjny jest dla mnie czymś solidnym. Skrypt zastępujący go setkami poleceniem powłoki sprawia wrażenie sznurka i taśmy klejącej.

Trzeba kogoś z dużą wyobraźnią i pomysłowością, żeby przewidzieć przyszłe problemy, wymagania i przygotować się do nich. Trzeba odwagi, żeby zejść z utartej ścieżki i zaproponować radykalne rozwiązania. A, jeszcze trzeba być niezłym programistą, żeby wcielić to w życie.

Natomiast nie trzeba nic umieć, by napisać taką petycję: Lennart Poettering: Stop writing useless programs - systemd, Journal. Do tego trzeba mieć tylko zamknięty, prymitywny umysł i cainofobię:

Lennart, come out from Linux please. You aren't necessary.

Powyższy komentarz pokazuje dobitnie jak bardzo niektórzy nie rozumieją reguł gry. I jak niepotrzebnie trwonią bity, od takich jednostek absolutnie nic nie zależy. Dystrybucje Linuksowe, a szerzej środowisko free software to przykład doskonale działającej merytokracji. Robisz = rządzisz. Zyskujesz respekt i wpływ. Narzekasz i produkujesz stop energy = znikasz w szumie tła.

Programy pisane przez Lennarta znajdują się w każdej dystrybucji Linuksa i poza nimi. I chociaż nie wszyscy dystrybutorzy radzą sobie z nimi, to jednak rozwiązują pewne problemy i są potrzebne. Nie pojawiają się znikąd — ktoś podejmuje decyzję o ich włączeniu.

Dystrybucje mają Komitety Techniczne (fedorowe FESCo, Technical Board w Ubuntu, openSUSE Board) nadające kierunek rozwoju. Zasiadają w nich ludzie z szerokim doświadczeniem i uznaniem społeczności. Osoby, które rozumieją i mają wiedzę pozwalającą stwierdzić: tak, w nowoczesnym systemie potrzebne jest avahi, systemd, nss-myhostame, pulseaudio, rtkit, libcanberra, nss-mydns itd. Są problemy, są braki, są na nie rozwiązania, to jest właściwa droga.

Drastyczne zmiany generują olbrzymi opór. Ostatnie dwa artykuły o Journal wywołały na spokojnym zazwyczaj LWN dyskusje na ponad 200 oraz ćwierć tysiąca komentarzy. Większość to biadolenie osób nie rozumiejących po co i dlaczego takie rozwiązanie jest proponowane. Zaraz za nimi Ci trochę sprytniejsi, ale reagujący na postęp jak autystyk na przemeblowanie pokoju. Nowe ficzery są spoko do momentu, jak trzeba się nauczyć czegoś nowego. W tym momencie zagrożona jest samopodtrzymywana opinia wszystkowiedzącego guru.

A głosy ,,to jest kopiowanie foobar''? Otóż na pewne potrzeby istnieją jakieś optymalne rozwiązania, więc nic dziwnego, że różni ludzie dochodzą do tych samych wniosków. Ale świat się wali, gdy wcześniej podobne mechanizmy zostały np. zaimplementowane przez Microsoft w Windows. Świętokradztwo, tam nie może być nic dobrze! Efektem jest więc robienie hałasu.

A najlepsi są w tym nastoletni programiści PHP używający Gentoo lub Archa, strzelający hejtspiczem we wszystko, czego nie potrafią ogarnąć. Zagorzałe dyskusje (patrz flame'y) są normalnym elementem działania naszego światka. Z niektórych nawet wynikają cenne uwagi. Większość to niestety mącenie wody przez osoby, od których i tak nic nie zależy. Ostatecznie to decyzje podejmie starszyzna, rozumiejąca przesłanki merytoryczne. A mały pies szczeka najgłośniej.

Istnienie btrfs Chris Mason zaanansował w połowie 2007 roku. System plików był używalny, chociaż brakowało wielu ficzerów i narzędzi. Nie było działającego fsck. I chociaż współczesne systemy plików w zasadzie nie potrzebują fsck, to jednak sprzęt kłamie i czasem trzeba ratować.

Półtora roku później (pierwsza połowa 2009) wydana zostaje Fedora 11. Instalator pozwala użyć btrfs po podaniu intuicyjnego hasła icantbelieveitsnotbutter. Przy katastrofach dalej trzeba odgrzewać backupy.

Kończy się 2009. Chris informuje, że fsck wciąż znajduje się w TODO. btrfsck z btrfs-progs nie dokonuje żadnych napraw tylko, kilku sprawdzeń.

W tym czasie koledzy z firmy Chrisa zauważają, że jednak nie można ignorować problemów spowodowanych niedoskonałością sprzętu. ZFS otrzymuje opcję recover, pozwalającą na odrzucenie ostatnich transakcji i przywrócenie spójności.

Mija kolejne pół roku. Niezrażeni twórcy MeeGo w maju 2010 postanawiają stosować btrfs jako podstawowy system plików.

Kilka kolejnych tyogdni bez wzmianek o fsck. W czerwcu 2010 Chris wspomina:

Everyone needs an fsck. Yan Zheng is working on a more complete fsck right now, and making good progress ;)

Zauważa też, że planują większości napraw dokonywać on-line. Fsck ma być przeznaczony do ratowania nie mountujących się systemów plików.

Tik, tak, tik, tak. Kończy się sierpień 2010. We're still actively developing it. I don't have a release date planned yet but we should have betas coming out over the next few months.

W listopadzie 2010 pierwszy przejaw wyjścia kodu fsck poza Oracle. Osoba z częstymi problemami zostaje namaszczona przez Chrisa:

Since you're basically going to be my first external fsck customer, is there anyway you can do a raw device based backup of the blocks?

W grudniu 2010, oprócz pojawienia się drobnego btrfs-select-super przydatnego przy odzyskiwaniu, Chris zapala kolejną iskierkę nadziei. I hope to have something ready early Monday..

W sylwestrową noc Ziemię rozświetlają fajerwerki.

Luty 2011.

Yes, but its still real soon now. I've been at about 90% done since Christmas. It would have been out last week […] I finally found a race in btrfs causing the corruption and now I'm back on fsck full time again.

W lipcu 2011 pojawia się jądro z numerkiem wersji 3.0. Wśród zmian jest scrub dla btrfs, czyli sprawdzanie spójności i naprawianie błędów w czasie pracy. Jest też autodefragmentacja. Wciąż nie ma narzędzia na sytuacje, kiedy nie można zamountować uszkodzonego systemu.

Na początku sierpnia 2011 Chris obiecuje ponownie:

Aside from making sure the kernel code is stable, btrfsck is all I'm working on right now. I do expect a release in the next two weeks that can recover your data (and many others).

Kolejny brak konkretów powoduje, że Fedora rezygnuje z uczynienia btrfs domyślnym systemem plików. Może za pół roku. Dostępność fsck jest jednak pierwszym warunkiem koniecznym. Wciąż nie spełnionym.

Na IRCu Chris zapowiada gotowość fsck na Linux Plumbers Conference 2011. LPC odbywa się w pierwszej połowie września. Stan fsck – jak zwykle.

Najnowsze zapowiedzi łączą się z ogłoszeniem, że btrfs został wybrany na domyślny system plików w Oracle Linux.

What this means is that absolutely cannot move forward without btrfsck. RH, Fujitsu, SUSE and others have spent a huge amount of time on the filesystem and it is clearly time to start putting it into customer hands.

Fsck mamy w końcu zobaczyć na Linuxcon Europe, który odbędzie się pod koniec października 2011. Wcześniej będzie merge window dla jądra 3.2. Z obsługą dużych bloków i podwalin dla RAID. Z doświadczenia wynikałoby, że kolejnego Sylwestra spędzimy bez btrfsck.

Czytając o systemd można czasem przeoczyć większą wizję. Celem nie jest jedynie napisanie kolejnego zastępcy inita. To tylko element całości, którą jest zdefiniowanie (również poprzez stworzenie) platformy Linuksowej. Ostatecznie będzie można powiedzieć, że ,,w Linuksie''

• jest ustawiona nazwa hosta
• listę zalogowanych użytkowników uzyskujemy przez systemd-loginctl list-sessions
• startujemy usługi na żądanie tworząc definicje .socket
• usługi potrzebujące haseł korzystają ze zdefiniowanej metody pytania
• unikalny identyfikator systemu można odczytać z /etc/machine-id
• itp.

I to zawsze. Dostawca oprogramowania nie będzie musiał tworzyć zawiłych skryptów sprawdzających czy używamy xinetd, inetd czy jeszcze czegoś innego. Osuszanie bagienka różnic między dystrybucjami powinno ułatwić dostarczanie oprogramowania firmom trzecim.

Aby osiągnać ten cel, systemd dostarczany jest wraz z garścią pomocniczych programików pojedynczego zastosowania. Część ujednolica czynności wykonywane we wszystkich dystrybucjach, część implementuje nowe mechanizmy mające stać się API Linuksa. Najprostsze (ograniczające się do pojedyńczych syscalli) wbudowane są w samą binarkę systemd.

Do czego zacząć się przyzwyczajać?

• hostname1 — dostępna przez D-Bus usługa zarządzająca krótką oraz opisową nazwą komputera; konfigurowana w /etc/hostname
• systemd-localed — dostępne przez D-Bus ustawianie języka systemu; konfigurowane w /etc/locale.conf
• systemd-timedated — D-Bus; ustawianie czasu, daty, strefy czasowej; konfiguracja w /etc/adjtime, /etc/timezone, /etc/locatime
• systemd-vconsole-setup — ustawienie układu klawiatury i fontu na konsoli tekstowej; konfiguracja w /etc/vconsole.conf
• systemd-binfmt — konfiguracja jak traktować różne pliki wykonywalne; katalog z konfiguracją: /etc/bindfmt.d
• systemd-tmpfiles — tworzenie plików, katalogów i gniazd przy starcie systemu; również kasowanie starych, nie używanych plików; konfiguracja z /usr/lib/tmpfiles.d i /etc/tmpfiles.d
• systemd-sysctl — ustawienie zmiennych jądra; konfiguracje z katalogów {/usr/lib,/etc,/run}/sysctl.d i pliku /etc/sysctl.conf
• systemd-modules-load — ładowanie modułów jądra; pliki konfiguracyjne w /etc/modules-load.d
• systemd-kmsg-syslogd — minimalny demon zapamiętujący informacje przed uruchomieniem właściwego syslogd
• systemd-random-seed — inicjacja puli entropii generatora pseudolosowego; również zapisanie stanu przy wyłączaniu komputera

Wydzielenie tych drobiazgów ze skryptow startowych umożliwia:

1. ujednolicenie zachowania wszystkich dystrybucji Linuksa
2. ujednolicenie sposobów np. zmiany nazwy komputera na wszystkich dystrybucjach
3. uruchamianie powyższych czynności jednocześnie
4. uruchamianie w razie potrzeby w trakcie działania komputera (np. pojawienie się nowego pliku w /etc/binfmt.d)

Ważnym nowością jest systemd-loginctl i skojarzony /etc/systemd/systemd-logind.conf zarządzajacy sesjami użytkownika. Odpowiada m. in. za automatycznie uruchamianie getty na konsolach, na które przełącza się użytkownik. Login manager daje informacje o zalogowanych użytkownikach, aktywnych sesjach i także pilnuje sprzątania procesów po użytkownikach wylogowanych. Poleceniem systemd-loginctl enable-linger można zażyczyć sobie uruchamiania sesji dla zwykłych użytkowników przy starcie systemu.

systemd-logind zarządza również wszystkimi zestawami klawiatura+mysz+monitor+inne urządzenia, ułatwiając pracę wielu użytkowników jednocześnie. Jest to efekt zapowiadanego pozbycia się ConsoleKit.

W życiu zachodzi czasem potrzeba modyfikacji skryptów startowych (jednostek systemd). Co jeśli mamy jakiś niepełnosprawny program i chcemy opóźnić jego uruchomienie, a nie możemy tego wyrazić poprawnymi zależnościami?

Systemowe (dostarczane przez dystrybucję) skrypty startowe znajdują się w /lib/systemd/system. Administrator nie powinienen ich ruszać, za to może przesłonić skrypt systemowy swoim, umieszczając go w /etc/systemd/system. Skrypt z /lib wygląda następująco:

[Unit]
Description=uses CDP / LLDP frames to inform switches about connected hosts
Requires=network.target

[Service]
EnvironmentFile=/etc/sysconfig/ladvd
ExecStart=/usr/sbin/ladvd -f $LADVD_OPTIONS
PIDFile=/var/run/ladvd.pid
StandardOutput=syslog

[Install]
WantedBy=multi-user.target

Przepisywanie całości jest niezdrowe, dużo roboty i możliwe rozjechanie gdy aktualizacja zmieni systemową jednostkę. W takich sytucjach najlepiej posłużyć się dyrektywą .include:

.include /lib/systemd/system/ladvd.service

[Service]
ExecStartPre=/bin/sleep 20s

[Install]
WantedBy=multi-user.target

Pierwsza linijka zaciąga całą treść oryginalnej jednostki. Sekcja [Service] wprowadza interesującą nas zmianę. Końcowka jest potrzebna do korzystania z systemctl enable/disable.

Inny przykład: dodanie zależności, wpływa na kolejność startu. Tworzymy /etc/systemd/system/radvd.service z zawartością:

.include /lib/systemd/system/radvd.service

[Unit]
After=aiccu.service

Wraz ze zmianą numeracji jądra pojawiło się kilka problemów z programami spodziewających się numeracji x.y.z. Brak trzeciego numerka odczuły jak dotąd:

• lvm2 — efektem jest problem z bootowaniem, naprawiony już w najnowszej wersji
• mdadm też krztusi się z dwucyfrowym numerkiem
• distributed.net client nie startuje, wysypuje się na inicjalizacji timerów
• aktualizacji wymagały module-init-tools w Fedorze

3.0 udostępnia też katalog /sys/fs/selinux. Biblioteki SELinuksa korzystają z niego w pierwszej kolejności przed /selinux. Zmiana punktu mountowania zaskoczyła systemd, co kończy się pętlą komunikatów loading policy przy uruchomieniu. Poprawka już jest, w międzyczasie zbootować można dodając selinux=0 do linii poleceń jądra.

A czy Twój kod radzi sobie z nowym numerkiem? I w ogóle po co mu ta informacja, powinien sprawdzać obecność wymaganych ficzerów, a nie numer wersji.

Linuksowi administratorzy w nadchodzących wydaniach swoich ulubionych dystrybucji natkną się na nowy wpis w katalogu głównym. Będzie to /run.

Katalog /run jest dostępny zaraz po zamountowaniu głównego /, przed pojawieniem się /var, który może być na osobnym wolumenie. Zawiera rzeczy odnoszące się do aktualnie działających program‎ów i usług (nie przechowuje wpisów przy reboocie). Są to:

• pliki blokad (/run/lock, dostępne również jako /var/lock)
• różne pliki uruchomieniowe, dotąd w /var/run
• zbiór rzeczy do tej pory ukrywanych w .katalogach w /dev:
  • dane udev z /dev/.udev
  • informacje przekazane przez programy z initramfs, działające przed zamountowaniem /, dotąd w /dev/.initramfs
  • informacje z systemach plików z /dev/.mount/utab (wszystko to, co nie jest zawarte w /proc/self/mounts)
  • pliki kontrolne w /dev/.systemd
  • pliki tymczasowe z /dev/.mdadm
• pamięć podręczną z /etc/lvm2/cache

A także inne pliki tworzone przez dracut, plymouth, bootchart i wszystkie programy, które do tej pory potrzebowały takiego miejsca. Użycie /dev było podyktowane obecnością tego katalogu od samego początku uruchamiania systemu. Nie do końca prawidłowe jest jednak przechywanie w /dev wpisów nie będących urządzeniami, a zwłaszcza ukrywanie ich kropką w nazwach.

Poza nadużywaniem /dev, dystrybucje do problemu podchodziły różnie. Debian daje /lib/init/rw, który z kolei narusza przestrzeń /lib dla bibliotek. Ubuntu udostępnia /var/run i /var/lock przy starcie, a przy mountowaniu właściwego /var dokonuje przypięcia (bindmount). Jest to jednak rozwiązanie podatne na wyścigi.

Wynik międzydystrybucyjnych uzgodnień ogłosił Kay Sievers, jednocześnie odpowiedzialny za wdrożenie tego rozwiązania w SUSE. Zawtórował mu Scott James Remnant, opiekun upstart i członek rady technicznej Ubuntu. Rozwiązanie wdrożyła Fedora, poddane zostało również pod dyskusję w Debianie.

Nasuwać się może pytanie, co z File Hierarchy Standard? Wersja 2.3 nie zakazuje, jednak wymaga rozwagi:

Distributions should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability.

Twórcy najważniejszych dystrybucji porozumieli się między sobą i stosowna poprawka do FHS została zgłoszona. Ostatecznie będziemy mieli: /var do rzeczy zmiennych, dostępnych pomiędzy restartami i /run dla tych mających sens jedynie w działającym systemie (wskazane więc użycie tmpfs). Coraz bliżej jest do umożliwienia funkcjonowania systemu z kluczowymi katalogami (/usr, /etc itp.) zamountowanymi w trybie tylko-do-odczytu.

Projektanci GNOME3 dołożyli wszelkich starań, żeby domyślne ustawienia były eleganckie, sensowne i nie wymagały poprawiania. W menu udostępnionio możliwość zmiany niektórych ustawień, ale część została uznana za zbyt niszowe na poświęcanie im miejsca.

Zmiana przycisków na belce okna czy zachowania Nautilusa możliwa jest z linii poleceń (używając gsettings lub dconf-editor), jednak wygodniej zrobić to graficznie. Z pomocą przychodzi narzędzie Gnome Tweak Tool.

Dodatek można zainstalować z linii poleceń (yum install gnome-tweak-tool) lub używając graficznego zarządzania pakietami. Większość wprowadzonych zmian jest widoczna od razu, niektóre wymagają restartu gnome-shell.

Dlaczego gnome-tweak-tool nie jest instalowany od razu?

Changing the theme is tweaking, changing the colours of it or changing the background is personalisation, changing the speaker volume is a setting (if it can even be called that), changing the default printer is definitely a setting. We support personalisation, and settings, but not tweaking. (Bastien Nocera)