Szef kuchni poleca: Beefy Miracle t-shirts O mnie Planeta !apcoh Social
Niedługo minie rok od zawiązania się naszej Wspólnoty Mieszkaniowej. W tym czasie rozrywek dostarczały mi pasjonujące lektury:
Jak to, możecie sprzedać moje mieszkanie za puszczanie głośnej muzyki?(art 16.)
To do zarządzania budynkiem jako firma musimy mieć człowieka z licencją? really?
My, deweloper, nie przekażemy wam Dziennika Budowy, bo tam jest napisane, że zapomnieliśmy wylać fundamentów(art. 3 pkt 16)
Grilla na balkonie też nie mogę rozpalić?(§ 4. pkt 1., 5)
Nie odpowiada wam odbiór techniczny mieszkania w niedzielę o 3 w nocy? Zapłaćcie karę!
Jak widać, aktów prawnych wpływających na nasze życie, nakładających obowiązki jest multum. Szokujące jest jednak, że ludzie kupujący mieszkania za kilkaset tysięcy złotych nie znają nawet tych kilku stron UoWL. Nie zdają sobie sprawy, że poza mieszkaniem kupują udział (i obowiązki) w częściach wspólnych. Że jak przepali się żarówka, to nie ma jakieś spółdzielni, która ją wymienia, tylko idzie to bezpośrednio z ich kasy. Że za odsnieżanie i sprzątanie trzeba płacić. Itd. itp.
Zdarzają się również Asy nie patrzące nawet w plany zagospodarowania przestrzennego. Potem z wielkimi oczami dowiadują się, że w ich ogródku będzie biegła dwupasmowa droga z tramwajem, planowana od 10 lat. Albo inaczej, że wygodna droga dojazdowa do bloku istnieje tylko na makiecie dewelopera, a nie w jakimkolwiek budżecie Miasta na najbliższe ćwierćwiecze.
Dzisiaj kolejny krok w prywatnej eksploracji kosmosu. Co prawda z nieprzewidzianymi problemami (SpaceX Launch aborted. 7 minutes ago
), ale zawsze duże wydarzenie. Nic więc dziwnego, że transmitowane w mediach na żywo.
Gdy więc w RSSach przy porannej kawie mignęło mi zdanie Zobacz gdzie znaleźć transmisję na żywo - live i streaming w Internecie
kliknąłem, żeby zobaczyć. I co? Link prowadzi do jakiego meczu piłki kopanej.
No kurde. Dzieją się naprawdę ważne rzeczy, a w mediach o niecałych dwóch tuzinach facetów pocących się na trawniku. Wciskają wszystkim tematy interesujące może kilka procent społeczeństwa, absolutnie bez wpływu na życie. A rozwój całej ludzkiej cywilizacji wspomniany gdzieś na ostatnich stronach, jeśli w ogóle.
Słusznie zauważa WO, że pomija się rekordowe
tempo budowy A2 w zamian marudząc, że na jakieś tam mecze nie będzie otwarta.
Who the fuck cares? Nawet jeśli skończą A2 za pół roku, to dalej
będzie wzorowym przykładem budowy dróg i dalej będzie służyła społeczeństwu.
A polscy “kibice” w większości i tak nie będą z niej korzystać, bo kilkanaście
PLN za przejazd nie mieści się w ich budżetach. I nie są w stanie ogarnąć wyzwań
pokonywanych przez rocket science
.
A może nie powinienem wychowywać się na sci-fi?
Od kilku lat Linux ma w jądrze implementację kontenerów o krótkiej nazwie LXC. W przypadku wcześniejszych rozwiązach typu VServer czy OpenVZ dokumentacji było mnóstwo i wszędzie można się było natknąć na jakieś slice'y i inne hostingi. LXC zaś jest jakby zupełnie niezauważone. Mam więc takie małe RFP — niech osoby zajmujące się tym tematem robią więcej prezentacji na linuksiastych imprezach!.
Solaris ma swoje Zones od ośmiu lat i generalnie wzbudza zachwyt. W dużej mierze dzięki działającej i rozbudowanej otoczce w postaci zoneadm, którą łatwo się wszystkim zarządza. Możliwości jądra Linuksa już dawno przewyższają Solarisa w kwestii kontenerów, tylko konfiguracja wciąż mocno kuleje. A może jestem w błędzie i tylko mi się wydaje, że przy LXC trzeba się ostro narzeźbić?
Na początku miesiąca przyszła większość elementów potrzebnych do kontroli umysłów rozpoczęcia Projektu 61107 i siostrzanego Projektu 1434.
![[elementy]](http://dżogstaff.pipebreaker.pl/2012.04.18-p61107.jpg)
Brakuje jeszcze kilku ważnych szczegółów, jak np. płytki prototypowej. Nie jest to pilny problem. Projekt(y) z założenia weekendowe, więc z uwagi na rozpoczęcie sezonu wyjazdów, jakieś efekty osiągnę pewnie za pół roku :-/
Jak
pisałem dwa lata temu, systemd pozbywa się pojęcia runleveli,
dając w zamian cele. Cel jest swego rodzaju punktem
synchronizacji, w którym system zapewnia określoną funkcjonalność. Zależności
między celami, tak jak między innymi jednostkami, nie są liniowe:
Otwórzmy powyższy obrazek i zastanówmy, co ja pacze?
Na początek legenda. Czarna strzałka oznacza, że wskazywany
cel jest wymagany przez wskazujący (Requires=).
Zielona wskazuje na kolejność, wskazywany musi się aktywować
do końca, zanim systemd przejdzie do wskazywanego (After=).
Czerwona oznacza konflikt (Conflicts=). Jak widać
shutdown.target konfliktuje ze wszystkich, czyli aktywacja
shutdownu powoduje zwinięcie wszystkich innych celi.
Jak widać w górnej-lewej części obrazka: nss-lookup.target nie
wymaga network.target. Jeśli jednak z jakiegoś powodu network.target
zostanie aktywowany, to nss-lookup.target wykona się po
nim — zielona strzałka.
Przy systemd nie można za bardzo powiedzieć o kolejności przy starcie systemu. Tutaj wybiera się docelowy stan systemu i osiąga go poprzez przywołanie wszystkich zależności. Analizę co się dzieje łatwiej jednak prowadzić od końca.
Załóżmy więc, że system ma działać w trybie graficznym. Celem jest więc
graphical.target, który z grubsza można porównać z runlevelem
2. w debianowatych. 4. w Slackware, 5. w starych redhatowych, SUSE i Archu —
umożliwia logowanie użytkowników w trybie graficznym.
Jako pierwsze aktywowane zostaną wymagania sysinit.target
(A special target unit covering early boot-up scripts). Ten zaciąga
przestrzenie wymiany (swap.target), lokalne systemy plików
(local-fs.target), w tym również szyfrowane z pytaniem o hasło,
jeśli potrzeba (cryptsetup.target). Aktywacje tej trójki odbywają
się równolegle. Kiedy zakończą się aktywacje i wystartowane zostaną
usługi dla tego celu, sysinit.target zostaje osiągnięty.
Umożliwia to przejście do basic.target. Zadaniem tego jest
dodatkowo uruchomienie wszystkich gniazd, na których słucha systemd
(sockets.target). System w tym stanie może przejść do trybu ratunkowego
(rescue.target) który daje powłokę odzyskiwania systemu. Przypominając:
mamy zamountowane lokalne systemy plików, włączony swap i zainicjowane
podstawowe mechanizmy dystrybucji. Taki runlevel 1.
Tu warto wspomnieć o trybie awaryjnym emergency.target. Jest to
absolutnie minimalny stan, w którym można próbować naprawić całkowicie zepsuty
system. Odpowiada niemal uruchomieniu jądra z parametrem init=/bin/sh,
daje jednak możliwość kontynuacji normalnego uruchamiania po naprawie.
Stąd system może przejść również multi-user.target. Jest to
podstawowy stan linuksa — działają prawie wszystkie demony, użytkownicy
moga logować się na konsolach (dzięki zaciągnięciu getty.target). Pachnie
jak runlevel 3. multi-user.target nie wymaga trybu ratunkowego,
ale jeśli takowy był uruchomiony, to musi skończyć się wykonywać przed przejściem
w m-u.target — zielona strzałka.
Z aktywnego multi-user.target już tylko krok do uruchomienia
graficznego zarządcy logowania i osiągnięcia zadanego graphical.target.
Większość z tych etapów opisana jest na stronie manuala
systemd.special.
Skąd brany jest cel przy starcie systemu? Zazwyczaj wskazuje go łącze symboliczne:
/usr/lib/systemd/system/default.target -> graphical.target. Administrator
może je przesłonić podając w linii poleceń jądra frazę systemd.unit=.
Cele są punktami, do których przypisujemy usługi do uruchomienia w obecnym
stanie. Weźmy np. wiszące luzem na obrazku cele po prawej stronie. Taki
bluetooth.target aktywowany jest przez pojawienie się urządzenia
obsługującego BT:
/usr/lib/udev/rules.d/99-systemd.rules:SUBSYSTEM=="bluetooth", TAG+="systemd", ENV{SYSTEMD_WANTS}="bluetooth.target"
i powoduje wystartowanie odpowiedniej usługi:
/etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Podobnie można np. przywiesić usługi do wystartowanie w związku z kartą dźwiękową
do sound.target.
Nie należy zapominać, że start to tylko jeden z etapów życia systemu. Wdzięczny do omówienia, gdyż powoduje kaskadę aktywacji różnych celi. W normalnym użytkowaniu jest to jednak bardzo specyficzna sytuacja i nie należy się na niej skupiać w celach innych niż akademickie.
Obrazek wygenerowany grepem z systemctl dot.
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>
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.#### 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
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.
UPDATE: Ktoś jednak stwierdził, że lepsze będzie trzymanie konfiguracji w JSON. No cóż, ma szansę sprawdzić się lepiej niż skrypt shellowy.
The actors stopped ranting before Peter had finished his shower. Wang-mu did not notice. She did notice, however, when a voice from the holoview said, "Would you like another recorded selection, or would you prefer to connect with a current broadcast?"Orson Scott Card, ”Children of the Mind” (1996)
For a moment Wang-mu thought that the voice must be Jane; then she realized that it was simply the rote menu of a machine. "Do you have news?" she asked.
"Local, regional, planetary or interplanetary?" asked the machine.
"Begin with local," said Wang-mu. She was a stranger here. She might as well get acquainted.
Siri, anyone? :-)
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.
