ntpd działa w naszym systemie jako daemon. Przy uruchomieniu łączy się z serwerami czasu i wstępnie koryguje zegar systemowy pod warunkiem, że różnica nie jest większa niż 1000 sekund (dlatego nie nada się do przestawiania zegara z czasu letniego na zimowy i odwrotnie). Następnie działa w tle i stopniowo przyspiesza albo zwalnia zegar, by uzyskać jak najdokładniejszy czas, uśredniając różnice z podanych serwerów.

Na wstępie powinniśmy ustawić godzinę na tyle dokładnie, żeby różnica nie przekroczyła wspomnianych 1000 sekund. Możemy to zrobić ręcznie bądź poleceniem:

# ntpdate ntp.icm.edu.pl

Pora przejść do edycji pliku konfiguracyjnego /etc/ntp.conf. Opcjami server podajemy serwery protokołu NTP, dzięki którym ntpd będzie mógł korygować czas. Jeżeli chcemy mieć dostęp do logów, warto użyć opcji logfile <ścieżka do pliku z logami>. Resztę opcji pozostawiamy domyślnie. Pomijając komentarze i puste linie, ntp.conf może wyglądać tak:

server 150.254.183.15
server 193.110.137.171
server 193.0.71.133
fudge   127.127.1.0 stratum 10
driftfile /etc/ntp/drift
broadcastdelay  0.008
restrict default noquery nomodify
restrict 127.0.0.1
logfile /var/log/ntp

Teraz wypada zdefiniować w pliku /etc/ntp/step-tickers serwery NTP, z którymi będzie łączył się ntpdate przy starcie. Mogą być te same, co w ntp.conf:

150.254.183.15
193.110.137.171
193.0.71.133

Na zakończenie ustawiamy systemową strefę czasową poprzez skopiowanie odpowiedniego pliku do /etc/localtime. Dla Polski:

# cp -f /usr/share/zoneinfo/Europe/Warsaw /etc/localtime

Ostatni ruch to nadanie skryptowi startowemu atrybutu wykonywalności:

# chmod 755 /etc/rc.d/rc.ntpd

Od następnego uruchomienia systemu daemon ntpd rozpocznie swoją pracę. Ażeby zobaczyć statystyki dotyczące poszczególnych serwerów w porównaniu do naszego zegara, wydajemy polecenie:

# ntpq -p

Pamiętajmy jedynie, by nie mieszać ntpd z innymi synchronizatorami. Po dokładniejszy opis opcji zapraszam do dokumentacji.

Oto lista najważniejszych zmian, które zaszły od wersji 12.2 (większość z nich opisana już we wcześniejszych artykułach):

• nowy format paczek .txz, który przyczynił się do zmniejszenia ich rozmiaru,
• użycie w instalatorze dystrybucji udev do wykrywania urządzeń,
• nowa wersja Xorg pozwalająca na zredukowanie linijek pliku konfiguracyjnego dzięki obsłudze urządzeń poprzez HAL,
• przejście z wersji 3 KDE na 4, dzięki czemu to środowisko graficzne zyskało nowe możliwości i wygląd.

A to wersje najbardziej sztandarowych składników systemu:

• kernel Linux — 2.6.29.6,
• kompilator GCC — 4.3.3,
• Binutils — 2.18.50.0.9,
• GNU C Library (glibc) — 2.9,
• KDE — 4.2.4,
• Xfce — 4.6.1.

Przy aktualizowaniu systemu warto przeczytać następujące dokumenty:

• UPGRADE.TXT,
• CHANGES_AND_HINTS.TXT.

Warto także wspomnieć, że to najlepszy moment na aktualizację pakietów dla użytkowników używających stabilnej wersji Slackware i chcących korzystać ze Slackware Current eXtended Desktop, gdyż teraz wersja stabilna wygląda tak samo jak rozwojowa -current.

Cytując słowa Patricka Volkderdinga

Have fun, and enjoy the new stable release!

przyłączam się do życzeń.

Większość z nas pewnie dotychczas wykonało choć jedną kompilację przy jego użyciu. Na etapie konfiguracji widzimy czytelne komunikaty, a sama kompilacja opatrzona jest procentowym postępem i kolorową oprawą. CMake nie odchodzi jednak od Makefile. Choć używa CMake-owych narzędzi, nadal wpisujemy make w celu rozpoczęcia kompilacji. Generowany jest natomiast przez program cmake, który z kolei opiera się na pliku CMakeLists.txt, tak jak autoconf na configure.ac. I właśnie pisanie tego pliku chcę tu opisać. Opierać się będę na projekcie Qt QameOfLife, który już opublikowałem w poprzednim artykule.

CMakeLists.txt tworzy się we własnym interpretowanym języku (już nie w Bashu jak w configure), który posiada wiele komend. Na szczęście do obsłużenia prostego projektu nie potrzebujemy ich zbyt wielkiego wachlarza. Zaczynamy od nazwy projektu:

project ( QameOfLife )

set( QAMEOFLIFE_SRCS
    main.cpp
    mainwindow.cpp
    game.cpp
)

set( QAMEOFLIFE_MOC_HDRS
    mainwindow.h
    game.h
)

set( QAMEOFLIFE_UIS
    mainwindow.ui
)

set( QAMEOFLIFE_RCS
    files.qrc
)

cmake_minimum_required( VERSION 2.6 )

find_package( Qt4 REQUIRED )

include( ${QT_USE_FILE} )

qt4_wrap_ui( QAMEOFLIFE_UI_HDRS ${QAMEOFLIFE_UIS} )
qt4_wrap_cpp( QAMEOFLIFE_MOC_SRCS ${QAMEOFLIFE_MOC_HDRS} )
qt4_add_resources( QAMEOFLIFE_RC_SRCS ${QAMEOFLIFE_RCS} )

add_definitions( -O2 -w -D_REENTRANT $(QT_DEFINITIONS) )

include_directories(
    ${QT_INCLUDE_DIR}
    ${QAMEOFLIFE_BINARY_DIR}
    ${QAMEOFLIFE_SOURCE_DIR}
)

set( EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR} )

add_executable( qameoflife
    ${QAMEOFLIFE_SRCS}
    ${QAMEOFLIFE_MOC_SRCS}
    ${QAMEOFLIFE_UI_HDRS}
    ${QAMEOFLIFE_RC_SRCS}
)

target_link_libraries( qameoflife
  ${QT_LIBRARIES}
)

install(
    TARGETS qameoflife
    RUNTIME DESTINATION /usr/bin
)

install(
    FILES icons/qameoflife.xpm
    DESTINATION /usr/share/pixmaps
)

Dokumentacja
Przy budowie bardziej skomplikowanego projektu z pewnością będziemy musieli skorzystać z dokumentacji. Zawiera ona szczegółowy opis CMake wraz mnóstwem przydatnych komend.

• Dokumentacja CMake 2.6

Używanie
Zbudowanie i zainstalowanie gotowego projektu jest bardzo proste:

CFLAGS="$SLKCFLAGS" CXXFLAGS="$SLKCFLAGS" cmake 
  -DCMAKE_INSTALL_PREFIX=/usr
make
make install=$DESTDIR

Mam nadzieję, że przekonałem drogich Czytelników-programistów do korzystania z CMake, gdyż jest to nowoczesny, rozwijający się system budujący z pokaźną ofertą możliwości.

Narzędziem IDE, które także posiada dizajner interfejsu GUI, a wyszło spod skrzydeł zespołu deweloperów Qt, jest Qt Creator (paczka dostępna w SCXD). Właśnie z jego pomocą postawimy pierwsze kroki, co nie oznacza, że nie nadaje się do profesjonalnych zastosowań. Z góry zaznaczam, iż nie mam na celu opisu całości aplikacji, lecz jedynie kilka jej kluczowych elementów mogących wydać się nieoczywiste. Wersja biblioteki, na której opieram opis, to 4. Nie ograniczajmy jednak Qt jedynie do biblioteki graficznej, ponieważ zawiera ona także biblioteki sieciowe i wiele innych będących chociażby odpowiednikami z innych popularnych bibliotek.

Tworzenie nowego projektu
W wyborze rodzaju projektów decydujemy się na Qt4 Gui Application. Z listy modułów zaznaczamy te, które będą nam potrzebne do stworzenia aplikacji. Metody, które zawierają, należy sprawdzić w dokumentacji.

Po lewej pojawi się lista plików będących elementami projektu:

• *.pro — wylistowanie plików projektu. Na jego podstawie generowany jest Makefile. Zarządzany przede wszystkim przez Qt Creator
• main.cpp — zawiera główną funkcję
• main (). Ograniczmy się w nim do operacji związanych stricte z C++, typu wygenerowanie zarodka liczb pseudolosowych (srand ())
• mainwindow.cpp — kod klasy MainWindow, tzn. związany z zarządzaniem wyglądem GUI, inicjujący często funkcje znajdujące się poza nim. Do zarządzania samym głównym oknem używamy obiektu MainWindow::MainWindow, np.
  

  void MainWindow::metoda () {
     // ...
     MainWindow::resize (width, height);
  }

  
  Natomiast do widgetów się w nim znajdujących został skonstruowany obiekt MainWindow::ui:
  

  void MainWindow::metoda () {
     // ...
     ui->napis->setText ("jakiś tekst");
  }

  
  Początkowe ustawienia obiektów warto umieścić w metodzie MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow). Jeżeli chcielibyśmy mieć dostęp do danego elementu ui z innej klasy niż MainWindow, dobrym pomysłem jest utworzenie obiektu dostępnego w niej całej, który z kolei jest typu naszego elementu. Tj. przekazujemy wskaźnik do elementu przez argument funkcji, a funkcja ta funkcja przechowuje go we wskaźniku dostępnym tylko w macierzystej klasie:
  

  MainWindow::MainWindow(QWidget *parent)
      : QMainWindow(parent), ui(new Ui::MainWindow) {
     Klasa *obiekt;
     obiekt = new Klasa;
     // ...
  }
  
  MainWindow::funkcja () {
     obiekt->new_ui_table (*ui->table);
  }

  
  Od tej pory jesteśmy w stanie zarządzać elementem GUI nazwanym table z klasy Klasa
• *.h — zwykłe pliki nagłówkowe
• mainwindow.ui — po dwukrotnym kliknięciu otworzy się graficzny edytor interfejsu. Za jego pomocą jesteśmy w stanie umieszczać widgety z listy w oknie MainWindow, a następnie edytować ich początkowe parametry.
• *.qrc — po wybraniu otworzy się edytor, w którym możemy dodawać prefiksy (adekwatne do lokalizacji w systemie po instalacji), a w prefiksach pliki będące w użyciu przez nasz projekt, np. ikony. Plikom warto nadać aliasy

Sloty
By mogło nastąpić wywołanie danej funkcji wskutek wykonania jakiejś operacji na danym elemencie interfejsu graficznego przez użytkownika, potrzebny jest slot. Tworzymy go w edytorze *.ui, klikając na drugą ikonkę od lewej nazwaną Edit signals/slots i przeciągając kursorem od widgetu do pustego pola. Otworzy się okno, gdzie wybieramy przy jakiej akcji slot ma zostać uruchomiony (metoda prób bądź dokumentacja) i funkcję, która wtedy zostanie wywołana. Istnieje możliwość dodania własnej. Pamiętajmy o umieszczeniu jej w private slots w pliku nagłówkowym. Definiujemy ją w klasie MainWindow.

Akcje menu
Po dodaniu do listy menu opcji, pojawi się ona w zakładce Action editor. Tam wypada zmienić jej nazwę. Natomiast akcją będzie metoda klasy MainWindow o nazwie “on__activated”:

void MainWindow::on_wyjdz_activated () {
    QCoreApplication::quit ();
}

Przykład
Żeby lepiej zrozumieć, jak to wszystko działa, napisałem prostą implementację Gry w życie Conway’a do pobrania tutaj. Zapraszam do przejrzenia kodu źródłowego.

Kompilacja
Kompilujemy w katalogu, gdzie zapisaliśmy projekt:

$ qmake
$ make

Przydatne adresy

• Przewodnik po Qt Creator
• Dokumentacja Qt 4.5

Podsumowanie
Liczę, że artykuł stanie się przydatny do wkroczenia w świat programowania w Qt dla osób, które nie miały jeszcze z tą biblioteką styczności. Pamiętajmy, że wszystkie możliwości Qt wykraczają poza jakikolwiek artykuł, dlatego najlepszym źródłem wiedzy jest oficjalna dokumentacja.

Za wprowadzenie mnie w opisany świat dziękuję Juzefowi.

Istnieje możliwość pozostania przy starym /etc/X11/xorg.conf. Wystarczy w sekcji ServerLayout dopisać

    Option "AllowEmptyInput" "false"

Do tego będziemy potrzebować paczki xf86-input-evdev zawierającą bibliotekę za to odpowiedzialną. Ponadto, jeżeli posiadamy bardziej wyszukany zestaw urządzeń, przyda nam się coś jeszcze, przykładowo xf86-input-synaptics dla touchpadów. Warto także wykonać kopię xorg.conf. Teraz należy przystąpić do usunięcia kilku sekcji z tego właśnie pliku. Niestety, skrypt xorgsetup służący do jego generowania jeszcze nadal pozostaje przy opcji “wszystko w pliku konfiguracyjnym”.

Po kolei możemy śmiało usunąć sekcje: Module, ServerFlags, InputDevice (kilka), Monitor, ServerLayout. Warto zostawić Files, gdzie znajdują się katalogi z naszymi czcionkami, Device, gdzie jest określony sterownik karty graficznej, z którego korzystamy i Screen, by zachować dotychczasową rozdzielczość. Mimo wszystko każdy powinien kierować się własną konfiguracją, ponieważ w niektórych sekcjach mogą znajdować się potrzebne wpisy. Oto, jak wygląda mój xorg.conf gotowy do współpracy z Init-Hotplugiem:

Section "Files"
    FontPath   "/usr/share/fonts/TTF"
    FontPath   "/usr/share/fonts/OTF"
    FontPath   "/usr/share/fonts/Type1"
    FontPath   "/usr/share/fonts/misc"
    FontPath   "/usr/share/fonts/75dpi/:unscaled"
    FontPath   "/usr/lib/X11/fonts/misc/"
    FontPath   "/usr/lib/X11/fonts/75dpi/:unscaled"
    FontPath   "/usr/lib/X11/fonts/100dpi/:unscaled"
    FontPath   "/usr/lib/X11/fonts/Speedo/"
    FontPath   "/usr/lib/X11/fonts/Type1/"
    FontPath   "/usr/lib/X11/fonts/TTF/"
    FontPath   "/usr/lib/X11/fonts/OTF/"
    FontPath   "/usr/lib/X11/fonts/cyrillic/"
    FontPath   "/usr/lib/X11/fonts/75dpi/"
    FontPath   "/usr/lib/X11/fonts/100dpi/"
EndSection

Section "Device"
    Identifier  "card"
    Driver      "nvidia"
    Option "AllowGLXWithComposite" "true"
    Option "AddARGBGLXVisuals" "true"
    Option "NoLogo" "true"
    Option "RenderAccel" "true"
EndSection

Section "Screen"
    Identifier  "Screen 1"
    Device      "card"
    Monitor     "monitor"
    DefaultDepth 24

    Subsection "Display"
        Depth       8
        Modes       "1024x768" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection
    Subsection "Display"
        Depth       16
        Modes       "1024x768" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection
    Subsection "Display"
        Depth       24
        Modes       "1024x768" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection
EndSection

W tym momencie czas zrestartować X-y i sprawdzić efekty naszej pracy. W pliku /etc/inittab warto ustawić domyślny tryb inicjacji na 3, by w razie czego móc z konsoli poprawić, co zepsuliśmy.

Operacje te wymagają podstawowej wiedzy na temat konfiguracji serwera X.Org, dlatego przed ich rozpoczęciem polecam się z nimi zaznajomić. Miejmy nadzieję, że wchodzimy w erę, w której skończą się pytania “jak zrobić, żeby kuleczka w myszce przewijała Firefoksa?”.

Ponieważ ostatnio używam Slackware Current x64 i mnie dopadł problem polonizacji. Po niezbyt długiej walce udało mi się osiągnąć sukces. Poniżej przedstawiam metodę na uzyskanie polskich znaków w Slackware przy kodowaniu UTF-8.

Na początek warto sprawdzić w /etc/lilo.conf cz nie uruchamiamy kernela z parametrem append=”vt.default_utf8=0″. Jeśli tak to należy zmienić wartość parametru z 0 na 1, aczkolwiek ja po prostu usunąłem wpis pozostawiając opcję append w postaci: append=”". Należy pamiętać o odświeżeniu konfiguracji LILO poleceniem /sbin/lilo. W przypadku GRUB-a należy sprawdzić w pliku konfiguracyjnym linie zawierające ścieżkę do kernela. Jeśli pierwotnie mieliśmy opcję vt.default_utf8=0 to po zakończeniu konfiguracji potrzebny będzie restart systemu.

Teraz możemy przystąpić do dalszej konfiguracji. Jako root naszym ulubionym edytorem otwieramy plik: /etc/rc.d/rc.font i wpisujemy do niego następujące opcje:

#!/bin/sh
setfont -v lat2-16.psfu.gz

Teraz nadajemy plikowi prawa do wykonywania aby był uruchamiany przy starcie systemu:

chmod a+x /etc/rc.d/rc.font

Teraz kolej na plik /etc/rc.d/rc.keymap:

#!/bin/sh
loadkeys -u pl2

I znowu nadajemy prawa do uruchamiania się:

chmod a+x /etc/rc.d/rc.keymap

Kolejnym plikiem jest /etc/profile.d/lang.sh:

#!/bin/sh
export LANG=pl_PL.utf8
export LC_CTYPE="pl_PL.utf8"
export LC_NUMERIC="pl_PL.utf8"
export LC_TIME="pl_PL.utf8"
export LC_COLLATE=C
export LC_MONETARY="pl_PL.utf8"
export LC_MESSAGES="en_US.utf8"
export LC_PAPER="pl_PL.utf8"
export LC_NAME="pl_PL.utf8"
export LC_ADDRESS="pl_PL.utf8"
export LC_TELEPHONE="pl_PL.utf8"
export LC_MEASUREMENT="pl_PL.utf8"
export LC_IDENTIFICATION="pl_PL.utf8"
export LC_ALL=

Tu ciekawostką jest, że w przykładach podane są lokalizacje w formacie np. en_US.UTF-8 natomiast w systemie występują one w formie takiej jak podałem powyżej (można to łatwo sprawdzić wykonując polecenie locale -a | grep pl).

To właściwie wszystko… Pozostaje tylko ponownie uruchomić system (jeśli trzeba) lub przeładować ustawienia:

source /etc/profile.d/lang.sh
/etc/rc.d/rc.keymap restart
/etc/rc.d/rc.font restart

Jeśli jakaś usługa nie było poprzednio uruchomiona i przy parametrze restart zwraca błąd należy spróbować uruchomić ją z opcją start zamiast restart.

Sprawdzone na aktualnych Slackware Current i Slackware Current x64.

Powyższy tekst dostępny jest na licencji GNU Free Documentation License.

Nic w tym dziwnego, że Slackware64 nie został wydany od razu w stabilnej wersji, ponieważ wymaga dokładnego przetestowania, chociaż Patrick zapewnia, iż do tej pory również przechodził przez ten proces. Nie zmienia to jednak faktu, że można go wypróbować już teraz. Czysto teoretycznie (nietestowane) wystarczy zaktualizować ostatnią stabilną wersję bądź Current 32-bitowy do 64-bitowego, chociażby podmieniając ścieżkę repozytorium w menedżerze pakietów. Niestety, na dzień dzisiejszy nie są załączone żadne wskazówki dotyczące aktualizacji, a ChangeLog sprowadza się jedynie do inicjacji gałęzi.

Pod znakiem zapytania staje sens istnienia nieoficjalnych 64-bitowych forków Slackware. Przykładowo Slamd64 wydaje się być zszokowane i nie skomentował jeszcze tego wydarzenia w żaden sposób.

Tym szczęściarzem, którego wybrał Patrick, jest .txz. Oczywiście mówiąc format, mam na myśli jedynie sposób kompresji archiwum tar i tak naprawdę tylko to się w paczce zmienia. Wszelka jej struktura wewnętrzna pozostaje taka sama.

Testując poszczególne formaty po ich wprowadzeniu, od razu dostrzegłem wielki potencjał w .tlz i .txz. Oba opierają się na słownikowym algorytmie kompresji LZMA i nie dostrzegłem pomiędzy nimi różnic. Algorytm LZMA przy wykorzystaniu narzędzia xz ma w porównaniu z Gzip i Bzip2 o wiele większy stopień kompresji. Oto przykładowe porównanie rozmiaru paczki Krusadera w tych trzech formatach:

$ du -hs krusader.*
3,5M    krusader.tbz
4,0M    krusader.tgz
3,0M    krusader.txz

Jako iż uważam zastąpienie wysłużonego .tgz za całkiem zgodne z ideą postępu i łatwego użytkowania, niedługo nowy format zawita również w Slackware Current eXtended Desktop. To oznacza, że wszelkie aktualizacje i nowe pakiety będą dodawane właśnie w nim. W związku z tym proszę zadbać o aktualne pkgtools, tar, xz i wybrać rozwijający się menedżer pakietów, który obsłuży tą innowację.

Adekwatnych do naszej potrzeby cacherów mamy dwóch: dnsmasq i nscd. Ten drugi zawarty w glibc, niestety, może być używany tylko przez aplikacje korzystające z tej biblioteki translacji DNS-ów, której on sam używa, a więc przykładowy Firefox, będący w większości przypadków głównym konsumentem cachera, nie skorzysta na tym. Aczkolwiek nscd możemy użyć do cache-owania lokalnych haseł i grup użytkowników, więc o ile odrzucamy go w kwestii hostów, o tyle warto i tak mu się przyjrzeć.

dnsmasq natomiast pełni rolę serwera DNS-ów, co czyni go zdecydowanie bardziej uniwersalnym, będziemy mogli na nim oprzeć wszystkie internetowe aplikacje. Jest on ponadto serwerem DHCP, lecz w ujęciu desktopowego komputera pod tym kątem on się nam nie przyda, więc pozwolę sobie pominąć tą funkcjonalność w opisie konfiguracji.

Zacznijmy od zainstalowania i konfiguracji. dnsmasq znajduje się w oficjalnym repozytorium Slackware’a, więc nie będzie problemu ze zdobyciem jego paczki. Konfiguracja jest również prosta, bo polega na odkomentowaniu kilku opcji z jego pliku konfiguracyjnego /etc/dnsmasq.conf. Przedstawiam je poniżej, lecz aby zachować porządek w pliku proponuję ręcznie je odszukać, odkomentować i dodać potrzebne parametry.

interface=ra0
listen-address=127.0.0.1
expand-hosts
cache-size=1024
no-negcache

Teraz wypada nadać uprawnienia wykonywalności skryptowi startowemu, aby dnsmasq był uruchamiany przy starcie systemu, i najlepiej od razu go uruchomić.

# chmod 755 /etc/rc.d/rc.dnsmasq
# /etc/rc.d/rc.dnsmasq start

W końcu musimy sprawić, żeby aplikacje wiedziały, że domyślnie mają się odwoływać nie do globalnych serwerów DNS, tylko do naszego pośredniczącego dnsmasq, który sam odwoła się do globalnych, jeżeli jeszcze dany adres nie będzie się znajdował w cache-u.
W związku z tym na początku pliku /etc/resolv.conf dopisujemy nasz lokalny serwer 127.0.0.1. W przypadku, gdy korzystamy z usług TP, może on wyglądać następująco:

search .
nameserver 127.0.0.1
nameserver 194.204.152.34
nameserver 194.204.159.1

prepend domain-name-servers 127.0.0.1,194.204.152.34,194.204.159.1

Od teraz cache-owanie przy pomocy dnsmasq powinno być w pełni funkcjonalne. Sprawdzić to możemy wywołując translację hosta na IP dig-iem. Najpierw, by IP zostało zapisane w cache-u; drugi raz, żeby sprawdzić, czy cache działa — odpowiedź serwera nie powinna być dłuższa niż kilka milisekund.

Za cenne wskazówki dziękuję slawulowi, który zresztą zainteresował mnie tym zagadnieniem.

Tata wskazał na moją nieużywaną od lat iluminofonię J-50 z zestawu do samodzielnego złożenia, a Kosma zaproponował port LPT (parallel) zamiast układu z klawiatury i uzmysłowił mi, jak i jakimi częściami to wszystko połączyć, jako że o elektronice nie mam większego pojęcia.

Port LPT posiada 8 bitów, 8 czyli sygnałów sterujących. To właśnie one zostały wykorzystane do włączania i wyłączania lampek. Każdy bit odpowiada za jeden odbiornik zasilania, więc musimy zadecydować, ile ich chcemy wykorzystać. Mi wystarczyły 2, dlatego też do pinu 2. i 3. portu za pośrednictwem wtyczki (którą zakupił mi uprzejmy kolega Fbz) przylutowałem oporniki 150 ohmów, a je z kolei do anod transoptorów CNY17 (polecam specyfikację). Każdy z bitów ma wspólną masę, która znajduje się w 25. pinie — łączymy ją z katodą każdego transoptora. Transoptor służy nam tu jako zabezpieczenie przed przedostaniem się napięcia 230 V w kierunku parallela.

Poniżej przedstawiam fragment schematu iluminofonii, który może przydać się nam do zbudowania tego prostego układu (oczywiste jest, że nie potrzebujemy całej iluminofonii).

Posłużę się przykładem pierwszego rozgałęzienia, który jest analogiczny do pozostałych. Rzecz jasna takich rozgałęzień możemy stworzyć do 8, by miało to sens.

Tranzystor T1 jest nam tak naprawdę niepotrzebny, więc łączymy się do niego równolegle lub zamiast niego. Kolektor transoptora (patrz: schemat w specyfikacji na 1. stronie) lutujemy do opornika R11, a emiter — do R12. Zamiast gwintów żarówek na końcu mocujemy gniazdo sieciowe (nie polecam ściennego ) i posiadając połączenie bit-opornik-transoptor-oporniki-układ-gniazdo dla pojedynczego odbiornika elektrycznego, elektronikę mamy z głowy.

Sterowanie za pomocą skryptu Perla jest całkiem proste. Oto ten, który napisałem:

#!/usr/bin/perl

use strict;

use Time::HiRes qw/usleep/;
use Device::ParallelPort;
use Device::ParallelPort::drv::parport;

my $p = Device::ParallelPort->new('parport');

$| = 1;

sub pin {
  @_ = grep (($_ != 0), @_);
  return $p->set_data () unless @_;
  
  my $pins = 1 << (shift () - 2);
  $pins = ($pins | (1 << ($_ - 2))) for (@_);
  return $p->set_data ($pins);
}

sub off {
  pin (0);
  exit;
}

$SIG{'INT'} = 'off';

open U, "< $ARGV[0]" or die;
my $t = scalar <U>;
my $l = scalar <U>;
my @u;

while (<U>) {
  chomp;
  my $pn = 2;
  s/1/$pn/g;
  push @{$u[0]}, (split / */, $_);
  for (my $i = 1; $i < $l; $i++) {
    $_ = scalar <U>;
    chomp;
    $pn = $i + 2;
    s/1/$pn/g;
    push @{$u[$i]}, (split / */, $_);
  }
}
close U;

while (1) {
  for my $i (0 .. (scalar @{$u[0]} - 1)) {
    pin (map $u[$_][$i], (0 .. ($l - 1)));
    usleep ($t);
  }
}

$ ./lamps.pl <układ>

<tempo w jednostce czasu usleep>
<ilość sygnałów sterujących>
<cyfry 0 i 1 reprezentujące odpowiednio stan włączony i wyłączony 1. sygnału>
<2. sygnału>
...
<1. sygnału>
<2. sygnału>
...

200000
2
11111111 00000111
00000111 11111111

Efektem kilkugodzinnej pracy są synchronicznie migające świąteczne światełka. Przedstawiam krótkie nagranie z udziałem mojego okna i balkonu przy wykorzystaniu przedstawionego układu.

Zastrzegam, że nie odpowiadam za ewentualne szkody wynikające z próby zbudowania tej ekscentrycznej maszyny. Życzę chęci i powodzenia.