Zápisky z LinuxAltu

6.11.2011 15:40 | Přečteno: 2327× | Linux | poslední úprava: 6.11.2011 23:13

Zápisky z přednášek, kdyby to někoho zajímalo :). Jak to půjde, pokusím se z toho nasyntetizovat souvislý text neboli reportáž.
Btw. záznamy prý budou, nicméně něco jsem nahrál na diktafon (hlavně pro případ, že by zase byly s oficiální kamerou nějaké problémy). Stahujte tady, ale nevím, jak bude rozumět (nemám tu nic na přehrávání audia).

Najdi incident v kupě logů Karel Šimeček

(axenta.cz)

• největším škůdcem akademická sfera
• WTF SIEM systém
• syslog-ng je multiplatformní, umí sbírat třeba i eventlog z Windows, agent s integrací do AD
  • čtení různých proprietárních formátů logů, čtení roury (/dev/log, /proc/kmsg)
  • rozdělení nasbíraných dat do různých “inboxů”
  • přímo umí zprávy třídit, zapisovat do SQL DB
  • šifrovaná komunikace v placené verzi
  • buffer v případě nedostupnosti syslog serveru
  • KB, ČEZ, laboratoř Los Alamos
  • grafické zpracování logů do animace, Gource
• vyšetřování incidentu - kdo, kdy, kde, co
  • ani CO? nemusí být tak jednoduché zjistit
    • př. sshd loguje hezky verbose, Cisco už je na tom trochu hůř a SAP je rozsypaný čaj, který se musí pro pochopení hodně přeparsovávat
• zpracování
  • rozhození podle zdroje (sshd, snmpd, aupsd…)
• demo: syslog-ng Store Box, webové klikací cute interface pro filtrování a analýzu
• klasifikace incidentů - priorita
  • snažíme se korelovat související události (zařízení hlásí vysokou teplotu + zařízení spadlo)
  • důležitost stroje (printserver uklízečky x účtárna, uložená data na stroji)
  • opakování incidentu
  • typ anomálie (port scan, divné pakety, spousta komunikace, kterou FW zakázal)

Paralelní start systému pomocí systemd Jan Horák

• když zapneme počítač, spustí se init, ten pak spouští další procesy (strom ps -něco)
• první implementace initu System III UNIX, 1982
• nahrazen SysV, dodnes pozůstatky v /etc/init.d/
• máme v počítači spoustu duplicitního kódu - porovnejte sktipty v /etc/init.d/
• služby seřazeny sekvenčně, ale my máme čtyřjádro

→ crap, zkusme démony spouštět jinak

• 2006 Upstart specifikuje přes LSB standardní hlavičku init skriptů; zparsují se hlavičky, vyrobí se strom závislostí mezi službami (sshd potřebuje síť) a spustí se to paralelně
• ale furt tam je ta duplicita
• nový systém by měl umět i staré skripty, aby se mohl nasazovat postupně
• myšlenka: co to vlastně znamená, že bluetoothd je závislé na dbusu? potřebuje komunikační cestu (zapisování do soketu, TCP a tak) → komunikační cestu vytvoříme naši a obsluhu spustíme, až když tam někdo něco zapíše (podobné xinetd)
• u starého SysV byla jenom démonizace - vyvázání se z terminálu - (chci v xtermu nastartovat lighttpd a udělat, aby běželo i po zavření xtermu) docela psycho - double-fork
• u systemd double-fork nepotřebujeme a můžeme běžet normálně na popředí, systemd nás na popředí nechá
• nemusíme třeba ani kontrolovat, jestli démon nespadnul, systemd nás může respawnovat
• systemd nám může vyrobit soket, může taky přesměrovat náš stdin/stdout do soketu
• (ale pokud chceme podporovat i jiný init systém, stejně musíme implementovat fallback…)
• demo - démon, který vrátí předpověď počasí na daný den
  • nemusíme řešit soket, systemd nám bude stream posílat na stdin!
• kde to zkusit? už je ve F15, volitelně v Ubuntu, ve F16 (vyjde každou chvíli) bude překonvertována většina služeb
• umí cgroups - organizuje procesy do skupin a skupině se dají omezit systémové zdroje, priorita… (př.: chceme snížit prioritu Apache, který ale spouští dvacet procesů → nastavím prioritu grupě); resp. [System]\nNice=-3 v konfiguráku
• systémová konfigurace v /lib/systemd, vlastní změny - soubor s include + změnami v /etc
• snažte se neprasit konfiguraci démonů do /etc/(default,sysconfig), ale do unit souborů, aby to bylo distro-wide
• konverze init skriptů na systemd unit files - často bez problému, ale někdy se musí přepsat „dohledový démon“ - třeba mysql_safe, který drží dohled nad mysqld, to může dělat systemd sám

protip: telnet má parametr -e :)

Využití opensource při stavbě infrastrukturního cloudu Martin Kopta

(oldany, oldany)

• virtualizace - HW proměněný v SW
• nevíme, co přesně ten cloud vlastně je
• SaaS - GMail, GDocs - na pozadí je cloud, uživatelé využívají jeho službu (frontend)
• IaaS - máme přístup k i té nižší úrovni, můžeme s těmi servery různě hýbat a tak
  • infrastrukturní cloud, př. VirtualMaster
• PaaS (Platform) - neposkytujeme software (SaaS) nebo hardware (IaaS), ale něco mezi
• u SaaS a PaaS někdy ani nevíme, že je to cloud; u IaaS je to vidět dost
• architektura IaaS
  • výpočetní uzly - fyzický server, musí být schopný virtualizace (pokud možno HW)
    • obsahuje hypervizor - dohlíží nad těmi virtuály, přiděluje prostředky
      • dnes je in Ubuntu - kompromis mezi bleeding edge a zastaralým
      • občas se používá i BSD nebo UNIX (OpenIndiana)
      • dříve byl preferován Xen, dnes KVM
  • datové úložiště
    • oddělené od samotných virtuálů, abychom mohli migrovat
    • FS na něm by mohl umět deduplikaci, LVM, RAID a tak
    • lokální FS (ext atd.) - exportuje se blokové zařízení?
    • sdílené úložiště (GVFS, OCFS) - exportuje se souborový přístup?
    • distribuované úložiště (9p z Plan9, NFS, AFS) - eh?
    • thin-provisioning - virtuální disk s dírama
  • cloud hypervizor/ultravizor/cloud controller
    • řekneme mu, tohle vypni, tady tohle přesuň
    • tj. hypervizor běží na uzlu a stará se o virtuál, ultravizor se stará o hypervizory
    • OpenNebula - C++ a Ruby
    • OpenStack - dost nové, nyní leader
    • oVirt - jako libvirt (ten se stará o virtuální stroje na serveru), takové webové rozhraní
    • nebo si napište vlastní…
  • rozhraní
    • webové
    • desktop klient
    • gadgety, widgety - machrovinky pro uživatele na telefon
    • RSS, Jabber, IRC bot… :)
    • senzory - když je nízký load, tohle a tohle přemigruj a pár jich vypni
  • správa a komunikace mezi komponentami by měla být na principu front/bufferů
• ukázka: BeeScale von OldanyGroup
  • účtování prostředků po hodinách
  • dotaz z publika: Kdo platí sežrání prostředků při DDoS (dynamické škálování)? Záleží na domluvě mezi poskytovatelem a zákazníkem.

(protip: NoSQL databáze se dá krásně použít k vytvoření fronty)

Linux ve 30km nad zemí Maroš Zatko

(kozmonautika.sk)

• nepopsatelné :)

GNU Radio aneb “hackněte” si elektromagnetické spektrum Jaroslav Škarvada

(RedHat, OK2JRQ)

• aby Fedora byla použitelné pro radioamatéry
• SDR - za vstupní filtr připojíme ADC a za něj DSP, který to zpracovává, za něj pak DAC pro převedení zpět na zvuk
  • byla by potřeba vysoká vzorkovací frekvence ADC
  • můžeme vzorkovat mezifrekvenci superhetu
  • nebo mixovat dva fázově posunuté signály stereo kartou (kvadraturní směšování)
• kognitivní rádio
  • radiospojení, které si samo nastavuje vhodnou frekvenci, modulaci… přeprogramováním se dá všechno změnit
• GNU Radio
  • zpracování signálu z externího SDR - real-time, offline, simulace
• jaký HW?
  • USRP1 - USB, 16MHz, $700 * + daughterboard, 2 RX a 2 TX * USRP2 - už se nevyrábí, 1 Gb/s ethernet, 50 MHz * N2X0 - Gb/s ethernet, 50 MHz, $1500
  • nejdražší jsou na tom FPGA
  • SDR Perseus - hlavně pro radioamatéry - přijímač pro slabé signály; do 40 MHz, 1,6MHz šířka pásma
  • FUNcube - od NASA pro sledování telemetrie Cube Sat, USB, 64-1700 MHz, 80 kHz šířka pásma
  • SoftRock - homemade, vzorkování zvukovou kartou, $20
• FUNcube:
  • radiomodemy, telemetrie spojů DP, hasiči, záchranka…
  • pro počítač je to USB zvukovka
• užití
  • testování komerčních přístrojů - různé mrvení signálu (např. testování GPS přijímačů)
  • FM, AM, DVB-T vysílač
  • fun with RFID
  • dekódování WiFi
  • sledování situace v ionosféře (GNU Jitter)
  • poslouchání satelitů AGILE (s detektory gamma záření)
  • pasivní radar - buď posloucháme vysílání letadla, nebo využijeme odrazů ostatních radiovysílačů a snažíme se to nějak zpracovat (under heavy development)
  • fun with GSM
  • Bluetooth - ale má problém se sledováním frequency hoppingu (moc pomalu se přelaďuje) - musí mít 2 desky
  • Open BTS
• jednotlivé bloky v C kvůli rychlosti, vyšší vrstva v Pythonu
• grafický návrh GNU Radio Companion
• ukázky: Hello World, směšování dvou signálů, dolní propust, FM rádio (koncesionářský poplatek?), příjem FM ručky na 145,55 MHz
• DTFM - tabulka 4×4, vždy smíšená dvojice frekvencí
• pro detekci není třeba počítat celou FFT, stačí vyfiltrovat jeden kmitočet - Goertzelův detektor

g! rms

• problém s legislativou - nejen u vysílání (i na kmitočtech s GL - není to homologování), ale i u přijímání - telekomunikační tajemství - třeba se to, co přijímáme, nesmí dál předávat

KnotDNS - nový výkonný autoritativní name server Ľuboš Slovák a Marek Vavruša

• reálně použitelné jen BIND a nsd, ostatním chybí nějaké funkce
• wishlist: bezpečný, rozumně napsaný, multiplatformní, rekonfigurace za běhu
• představen na RIPE63 nedávno
• jen autoritativní

g! dns axfr/ixfr

Myšlenkové mapy v Linuxu Michal Černý

(myslenkove-mapy.cz)

• pro rozvoj kreativního myšlení, ke studiu, k návrhu algoritmů (návrh UML modelu)
• analýza problémů, monitorování znalostí, prezentace modelu/projektu
• sebereflexe, rekapitulace dne
• zápisky do sešitů formou mindmapy
• sitemap na webu
• rychlý přehled o problematice za pár sekund
• graficky uspořádaný text + obrázky + vazby mezi klíčovými slovy
• zmapováním získáme přehled o souvislostech
• Prezi je vlastně taky taková myšlenková mapa
• FreeMind - umí export i do Javy (apletu)/Flashe

prostě si stáhněte slidy, no

• dejte si myšlenkovou mapu s tím, kdo co ve firmě zrovna dělá, na monitor na chodbě

Fyzikální experimenty v Linuxu Michal Černý

• proč OSS ve školách?
• s použitím volně nedistribuovatelných programů má student možnosti:
  • koupit na doma
  • ukradnout
  • nepřipravovat se doma
• často škola musí utratit peníze prostě proto, aby vyčerpala fondy - jinak by příště už nic nedotala
• nástroje pro zpracování a vizualizaci naměřených dat
  • nástroje musí být didakticky vhodné
    • Calc není - to je pro business tabulky, ne pro fitování 10k hodnot
  • SciDAVis - pro středoškoláky - základní proložení [fitování] a tak
  • LabPlot - 3D a 2D grafy, práce s DB
• Phun - simulace mechanických dějů
  • včetně simulace různých dějů za různých podmínek (gravitace, odpor prostředí…)
  • není OSS
• Step - spíš numerické simulace
• elektronické simulace
  • klasické i logické
  • Oregano - složitější ovládání, kvalitní analýza signálu (FFT)
• astrofyzika
  • virtuální planetária
  • simulace vesmírných dějů
    • Planets - modelování pohybu nebeských těles; např. vymodelování funkční sluneční soustavy, aby se planety nesrážely, není triviální :)
  • Celestia - lety vesmírem
• experimenty se zvukovkou
  • baudline, xoscope
  • se stereo/dvěma vstupy cool, ale i s jedním třeba osciloskop

CC BY, chyby v zápise pravděpodobně vznikly na přijímači; řešte se mnou, ne s přednášejícím

odkaz k anketě        

Anketa

Komentáře

[xkucf03]

Klidně body, ale nemuselo by to být zrovna v <pre/>

[Michal Kubeček]

Souhlasím, v kombinaci s těmi kilometrovými řádky je to děs.

[Saljack]

Přesně vyšoupni to z toho pre ať se to dá normálně přečíst.

[Jendа]

Hmm, čekal jsem, že na širším viewportu než 800 px na notebooku to bude vypadat líp. Nějaký tip na parsovátko, co z toho vyrobí zanořený <ul> seznam, nebo si mám něco ubastlit?

[Jendа]

Zkusil jsem to prohnat parserem z DokuWiki, snad je to lepší.

[xkucf03]

jj, o hodně lepší, díky (no, ale už jsem to vlastně přelouskal v tom <pre/>, takže znova to číst nebudu ). Jinak na tyhle věci používám Markdown (BTW: lze v něm psát i komentáře na KP )

[Bedňa]

bite my shiny metal ass

[Michal Kubeček]

No, podle toho, co jsem zatím viděl, je systemd zatím jedna velká katastrofa a bude ještě zatraceně dlouho trvat, než to aspoň nebude horší. Co se týká toho, jestli to vůbec někdy bude lepší, jsem dost skeptický - (možná) pár sekund při bootu rozhodně nevynahradí komplikovanější konfiguraci, diagnostiku a ladění chyb.

[pavlix]

Konfigurace (ve smyslu unit files) mi už teď přijde přehlednější než initskripty. Pro těch „možná pár sekund“ doporučuju zhlédnout přednášku o systemd z ELCE, pokud už jsou k dispozici videa.

[Michal Kubeček]

Video není potřeba, měl jsem tu (pochybnou) čest zkusit si to na reálném systému. Nějaké zrychlení tam možná bylo, ale rozhodně nestálo za ty obrovské problémy. I když… to by nejspíš nestálo ani v případě, že by systém bootoval v nulovém čase. Jediné štěstí je, že v OpenSuSE 12.1 aspoň částečně zvítězil zdravý rozum a jde to celkem snadno přepnout na klasický System V init.

[Jendа]

A co konkrétně za problémy jsi tam měl? Mně to z té přednášky přišlo jako celkem dobrý nápad, ale ještě jsem to na svém systému nezkoušel.

[Michal Kubeček]

Třeba takové, že při startu bez zjevného důvodu nenaběhne KDM a když už ho spustím ručně, stejně selže inicializace KDE desktopu. A spousty dalších drobných radostí, kdy tu a tam zjistím, že něco nenastartovalo ve správném pořadí nebo dokonce nenastartovalo vůbec. Nebo třeba systém vytuhne během ukončování.

Mně se moc nelíbí ani ta idea. Před rychlostí startu systému upřednostním funkčnost, spolehlivost a snadnou udržovatelnost a diagnostiku. Tohle všechno bohužel systemd nenabízí. Funkčnost se snad časem doladit podaří, možná i spolehlivost, ale co se týká těch zbylých dvou, ty holt bohužel padnou za oběť popularitě závodů v bootování. :-( Už teď se děsím dne, kdy se tohle neštěstí dostane do SLE.

[michich]

S diagnostikou problémů to bylo špatné ve Fedoře 15, protože chybový výstup služeb šel často do /dev/null. Ve Fedoře 16 jde už ve výchozím nastavení stdout a stderr služeb do syslogu (máme tam sice chybku, že jiné typu unitů než service svůj výstup směrují blbě, ale to spravíme updatem). To logování v systemd je dokonce uděláno tak, že do syslogu se dostane i to, co se vygeneruje před spuštěním rsyslog. Třeba i záznam z provedeného fsck. To jsme nemívali.

Já už jsem si na přehled, který mi poskytuje systemctl, zvyknul tak, že si neumím představit být bez toho. Kvůli tomu všemu si myslím, že diagnostika bude nakonec lepší bež kdykoliv předtím.

systemd rozhodně není jen o závodech v bootování a je škoda, že takový dojem vzniknul. Asi to Lennart ze začátku příliš zdůrazňoval.

[Michal Kubeček]

Já jsem bohužel ještě žádný jiný přínos neviděl. Tedy abych se vyjádřil přesně: viděl jsem seznam pár dalších věcí, které sice byly prezentovány jako výhody, ale jejich přínos pro mne je v lepším případě nulový.

[Jezekus]

Celkem s Vami souhlasim, snazil jsem se na to zvyknout (Fedora 15), ale stale davam mnohem radeji prednost puvodnimu init systemu, ktery jiz behem bootovani predal (me jako uzivateli) jednoznacnou informaci o tom jak na tom jsou dane sluzby. Toto bohuzel s prichodem systemd zaniklo, nepreberna sbirka textu pri startu, kde se micha x desitek sluzeb se svymi vypisy starting, started...
Je mozne, ze to bude nekdy v budoucnu prinos bohuzel v soucasne situaci mi to prijde velice neohrabane a slozite na spravu.

[Radek Hladik]

Viz např. můj dotaz, kde ovšem musím říct, že hodně bylo opravdu způsobenou tou beta verzi. Ovšem bugy považuju za poměrně zásadní.

Dále mi při startu chybí můj oblíbený seznam OK, což chápu, že je čistě subjektivní věc, ale vypovídá to něco o návrhu celého systému. Jak jsem se učil ve škole, když děláte nový systém, není moudré dávat pryč věci, na které jsou lidi zvyklí. V současné chvíli je start směsicí všemožných výpisů, které jsou všemožně propletené. A přitom by stačilo, aby systemd místo "Started postfix" napsal "Start of postfix [ OK ]".

Co se teoretických námitek týče, už se to tu řešilo, např zde. Mně osobně se nelíbí už ani ta idea, ani přístup autora, vlastně jediné, co se mi líbí je ta možnost mít lepší přehled o službách a co k nim patří. Což je víceméně věc cgroups.

Závěrem je vhodné podotknout, že ve Fedoře je možné nahradit systemd a původní upstart, ikdyž to dá práci. Ostatně pokud se systemd nějak rychle nezlepší, plánuju to udělat, protože na většině strojů stejně spouštím tak málo služeb, že si ty init skripty zvládnu udžovat sám, když bude potřeba

[Radek Hladik]

Myslel jsem samozřejme "nahradit systemd původním upstartem", ale nějak jsem se v tom zamotal

[petr_p]

Nechci vám kazit radost, ale do Fedory 16 se řada služeb přepsala pro systemd a podpora pro systemv se zahodila. Takže si sice upstart nainstalujete, ale nebude mít co spustit.

[maleprase]

tak par rozumnych lidi podporu pro sysv nezahodila ale pridala podbalicek -sysvinit, namatkou openssh, rsyslog, lvm2, ...

takze upstart se da nainstalovat, je i co spustit, akorat je potreba vypnout selinux, protoze dracut uz inicializaci neprovadi a samotny upstart pro to podporu nema

[pavlix]

akorat je potreba vypnout selinux

Tomu říkám řešení :).

[maleprase]

tak jde to i se selinuxem, jen to chce trochu vic snahy. jestli je vubec nekdo kdo by to vyuzil, muzu to rozepsat.

[Radek Hladik]

protože na většině strojů stejně spouštím tak málo služeb, že si ty init skripty zvládnu udžovat sám, když bude potřeba

Osobně si myslím, že syntaktický rozbor této věty (pro hnidopichy věty vedlejší) by neměl být zas až tak těžký. leč pro jistotu ho přikládám i s podrobnějším vysvětlením.

Každopádně zamýšlené vyznění je takové, že při malém počtu služeb, které na většině strojů používám (cca 15-20 rc.skriptů, z toho 5 mých vlastních), je možné si ty skripty udržet funkční svépomocí. Fedora 14 jich je pořád plná (což je vzhledem k přístupu Lennarta Poetteringa s podivem), pro další Fedory některé balíčky obsahují init skripty. Dále máme další různé distribuce, které nejsou v tomto tak pokrokové. A samozřejmě máme různé editory, kterými je možné skripty upravovat a protože se většina skriptů skládá ze zavolání binárky s nějakými parametry a případně killem podle PID, tak to zas takové zlo není. Také nesmíme zapomínat na autory programů, kteří různé skripty občas distribuují se svými programy. Někteří možná nebudou žhaví do přepisování svých démonů (přestože to Lennart očekává), takže si například dají pozor, aby jejich init skripty pod upstartem fungovaly. Koneckonců to, že Fedora už nepoužívá upstart, neznamená, že upstart už nepoužívá nikdo.

Jen pro zajímavost jsem si porovnal init skript pro SSH z Fedory Core 4 a z Fedory 14, což je řekněme při frekvenci dvě Fedory za rok 5 let rozdíl. A pravdou je, že se liší poměrně hodně, ale vše jsou to věci, které se týkají věcí okolo Fedory (rhgb vs plymouth,rozdělení generování klíčů na dvě části, přidání možnosti force-reload,...) nikoliv však vlastního spuštění ssh. A upřímně řečeno, dokud mne systemd nepřesvědčí, tak klidně budu mít 15-ti řádkové initskripty ve tvaru: spusť binárku, zabij PID...

Co je výrazně horší, jsou systémové skripty (především rc.sys). Ovšem i zde toho požaduju poměrně málo, ve F16 je pořád ještě funkční balíček, takže i tam to nějakou dobu vydrží.

Osobně bych si troufnul prorokovat, že chleba se začne lámat tak u Fedory 20-21, kdy doufám buď bude systemd na smetišti dějin (aka smetištěd ) nebo bude rozumně použitelný.

A taky jsem zvědavý, co na to RHEL, protože upřímně řečeno, dostat v komerční verzi Linuxu systemd v současné podobě, tak nebudu moc spokojený zákazník...

[Michal Kubeček]

A taky jsem zvědavý, co na to RHEL, protože upřímně řečeno, dostat v komerční verzi Linuxu systemd v současné podobě, tak nebudu moc spokojený zákazník...

IMHO to je tak, že do RHEL 6 ho nikdo cpát nebude a RHEL 7 je ještě daleko. A právě proto, aby se to do RHEL 7 stihlo odladit (nebo zavrḧnout), ho teď natlačili do Fedory. (Kvíz: najděte pět rozdílů oproti situaci se SLES 11/12 a OpenSuSE… nebo aspoň jeden.)

[pavlix]

Video není potřeba

Však jasné, někteří lidé sledují aktuální dění a vzdělávají se, jiní ne. Takže díky za to, že nám s té první skupiny neděláš konkurenci :).

[=^..^= AmigaPower®]

Ty jsi ztracenej kámo, jediná klika pro další generace je, že se fakt asi kvůli tomu ani nerozmnožíš....

[xkucf03]

WTF?

[=^..^= AmigaPower®]

...nic, spi...

[xkucf03]

Proč je největším škůdcem akademická sféra?

[Mrkva]

Dovolil bych si tipnout: koleje.

[pools]

http://info.siliconhill.cz/2011/10/klub-silicon-hill-vs-protipiratska-unie-roska-%e2%80%9ctahnete-na-strahove-vladne-warez%e2%80%9d/

[Vašek Lorenc]

Tipuji, že je to kvůli tomu, že tam kupa lidí má neaktualizovaná Windows, často nenastavené antiviry nebo osobní firewally, někde něco pochytají a pak to donesou na koleje/přednášky, kde se to rozjede.. a konektivita univerzit je v řádu gigabitů, takže to občas může menším firmám pěkně zatopit.

[Jendа]

//je tam záznam :)

Říkal, že spousta studentů hledá seberealizaci v dostávání se do cizích systémů.

[|🇵🇸]

Některé fotky snad ani nebudu publikovat.

[|🇵🇸]

Moje fotky.

[Bedňa]

Fakt ostré

[|🇵🇸]

Zkoušel jsi někdy za špatných světelných podmínek fotit sklem s horší světelností a pokud možno bez blesku... lidi na dálku?

Navíc jsem se moc nezabýval vyvoláváním.

[kralyk z abclinuxu]

Tak ta přednáška o SDR musela bejt hodně zajímavá... Škoda, že jsou veškerý trxy stále tak drahý. Jestliže to USRP stojí $700+ tak to už si skoro člověk může koupit některý FT-čko, ačkoli teda s tím se asi nedaj dělat takový bejkárny. Zajímalo by mě porovnání kvality, případně komfortu RX/TX na USRP vs na FT-čku nebo jiným běžným trxu.

[Ondrej 'SanTiago' Zajicek]

Jeste je zajimave low-cost reseni pouzit jako vstup nejakou videokartu s Bt878, ta ma z nejakych duvodu v sobe A/D prevodnik se samplovaci frekvenci 448 kHz. Proti USRP nic moc, ale zas lepsi nez zvukovka. viz.

[PetrHL]

aby Fedora byla použitelné pro radioamatéry

Ale o CQRLOGu ani zmínka . Nedovedu si představit použití pro radioamatéry bez pořádného staničního deníku.

[maleprase]

2006 Upstart specifikuje přes LSB standardní hlavičku init skriptů; zparsují se hlavičky, vyrobí se strom závislostí mezi službami (sshd potřebuje síť) a spustí se to paralelně

upstart zadne LSB hlavicky neparsuje. kompatibilita upstart a sysvinit skriptu je zajistena fakticky pouze ulohou rc (/etc/init/rc.conf) ktera pousti skript "/etc/rc.d/rc $RUNLEVEL"

naopak systemd se o kompatibilitu se SysV init skriptama pokousi tim ze z kazdeho initskriptu vytvori meta .service se stejnym jmenem a na zaklade LSB hlavicek vygeneruje zavislosti.

[michich]

# snažte se neprasit konfiguraci démonů do /etc/(default,sysconfig), ale do unit souborů, aby to bylo distro-wide

To je nedorozumění. Konfigurace démonů opravdu nepatří do souborů v /etc/(default,sysconfig), kde si každá distribuce vymýšlí vlastní formát, ale do unit souborů taky ne. Démon má idálně sám načítat svůj konfigurační soubor v /etc, použitelný v každé distribuci. Neměl by spoléhat na to, že mu nějaký startovací skript všechny možné volby předá na příkazové řádce.

[Michal Kubeček]

Obávám se, že to je přesně ten způsob uvažování, který u vývojářů ostatních unixových systémů (a upstreamových projektů) vyvolává nepřátelské postoje k Linuxu. Tedy konkrétně přístup, že my jsme si tady něco vymysleli, tak je to jedině správně a všechny projekty jsou povinny se bez řečí okamžitě přizpůsobit a zahodit to, jak to dělaly dosud (třeba klasická "démonizace" nebo předávání parametrů na příkazové řádce); a to včetně těch, které nemají Linux jako hlavní cílovou platformu, a těch, které nemají Linux vůbec jako cílovou platformu.

[michich]

Ne, to není povinnost. Jenom dobré doporučení.

[pavlix]

Obávám se, že to je přesně ten způsob uvažování, který u vývojářů ostatních unixových systémů

Obávám se, že v případě těch vývojářů, kteří s tím mají nějaký problém, je to spíš jejich problém než kohokoli jiného.