Přesně před 34 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
86Box, tj. emulátor retro počítačů založených na x86, byl vydán ve verzi 5.0. S integrovaným správcem VM. Na GitHubu jsou vedle zdrojových kódů ke stažení také připravené balíčky ve formátu AppImage.
Vláda Spojených států získala desetiprocentní podíl v americkém výrobci čipů Intel. Oznámili to podle agentur americký prezident Donald Trump a ministr obchodu Howard Lutnick. Společnost Intel uvedla, že výměnou za desetiprocentní podíl obdrží státní dotace v hodnotě 8,9 miliardy dolarů (zhruba 186 miliard Kč). Částka podle Intelu zahrnuje dříve přislíbené subvence 5,7 miliardy dolarů z programu CHIPS na podporu výroby čipů v USA,
… více »Organizace Apache Software Foundation (ASF) vydala verzi 27 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2024 (pdf). V loňském roce NÚKIB evidoval dosud nejvíce kybernetických bezpečnostních incidentů s celkovým počtem 268. Oproti roku 2023 se však jedná pouze o drobný nárůst a závažnost dopadů evidovaných incidentů klesá již třetím rokem v řadě. V minulém roce NÚKIB evidoval pouze jeden velmi významný incident a významných incidentů bylo zaznamenáno 18, což oproti roku 2023 představuje pokles o více než polovinu.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované obrázky APNG a WebP.
Na chytré telefony a počítačové tablety v Rusku bude od začátku příštího měsíce povinné předinstalovávat státem podporovanou komunikační aplikaci MAX, která konkuruje aplikaci WhatsApp americké společnosti Meta Platforms. Oznámila to dnes ruská vláda. Ta by podle kritiků mohla aplikaci MAX používat ke sledování uživatelů. Ruská státní média obvinění ze špehování pomocí aplikace MAX popírají. Tvrdí, že MAX má méně oprávnění k přístupu k údajům o uživatelích než konkurenční aplikace WhatsApp a Telegram.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu srpnový souhrn novinek. Kvůli nedostatečnému zájmu byla ukončena výroba telefonů PinePhone Pro.
Po pěti měsících vývoje byla vydána nová verze 0.15.1 programovacího jazyka Zig (GitHub, Wikipedie). Verze 0.15.0 byla přeskočena. Přispělo 162 vývojářů. Přehled novinek v poznámkách k vydání.
Měsíc po vydání RC verze byla vydána stabilní verze Devuanu 2.0.0. Její kódové jméno je ASCII, podle planetky s katalogovým číslem 3 568. Přehled novinek v poznámkách k vydání. Devuan (Wikipedie) je fork Debianu bez systemd.
Tiskni
Sdílej:
Tak používaj svoj oneclick systém.
ení to směšné?Není, keby sme sa chceli ťahať za pipíky, tak si môžeme porovnať verzie programov a ver tomu, že Gentoo už dávno zaspalo dobu.
Debian je na tom s podporou init skriptov / systemd unitov dlhodobo zle. Pred systemd to bola len zmes hrozne nespoľahlivých skriptov. Niečo tak neprehľadné a nefunkčné sa len tak ľahko nevidí. Po nasadení systemd síce stále niektoré služby nefungujú (za všetky spomeniem napr. taký gitlab ktorý má 50% pravdepodobnosť naštarotovania, alebo uwsgi, ktorý naštartuje takmer vždy, ale pravdepodobnosť, že sa neskôr dá reštartovať je tak 10%), ale stačilo napísať vlastné pár riadkové unity a všetko krásne funguje.
Niektoré fungovali, niektoré nie. Tie najbežnejšie asi fungovali, ale akonáhle som potreboval rozbehať redmine tak štart fungoval, vypnutie tak v 20% prípadov vytuhlo. Gitlab robil to isté, akurát potreboval viacej krokov a vytuhlo to tak v 50% prípadov. Vtedy som musel zistiť v akom stave zostal visieť, pokillovať čiastočne naštartovaný gitlab ručne a skúsiť ho ručne naštartovať. Úplne najhoršie bolo asi uwsgi. Úspešnosť vypnutia služby bola tak 20% a moc jednoducho som to nevedel pokillovať, takže pri reštarte uwsgi som radšej rovno reštartoval server. Áno, nasieralo to zákazníkov, ale vždy to trvalo kratšie než keby som mal všetky procesy killovať, kontrolovať zámky atď.
Nechcem tu byť za obhajcu systemd, ale treba si uvedomiť, že doba sa trochu zmenila. Časy keď sme na serveri hostovali pár PHP stránok, všetko to bežalo pod apachom, ktorý si sám mangoval PHP, sám si managoval vlastné procesy, sám sa staral o logovanie, sám sa staralo o zapisovanie PID ... sú preč.
Dnes mám na serveri mnoho malých služieb, ktoré bežia samostatne. Niektoré sú štartované na požiadanie, iné štartujú hneď pri boote. Niektoré sa automaticky vypnú pri nečinnosti. Niektoré potrebujú závislosti. Niektoré sú uzavreté v chroote. Keby som to chcel managovať starým spôsobom musel by som každú jednu aplikácu naučiť fork, ku každej jednej ktorá beží pod chrootom by som musel napísať vlastný supervizor, v kadej by som musel riešiť logovanie, ku každej aplikácii by som musel napísať init skripty so špecifickým sleepom podľa toho koľko aplikácii trvá zapísanie PID ... tieto veci sa našťastie presunuli do systemd a pri vývoji aplikácie sa o ne už nemusím starať.
Z mojej strany je odchod od initu vykúpením z nekonečného písania skriptov, ladenia, dopisovania toho istého deravého kódu do každej aplikácie, ladenia, opravovania každej jednej aplikácie, ladenia ... Určite by som u systemd uvítal menej arogantné správanie vedenia, väčší dôraz na opravovanie chýb, minimalizáciu závislosti, možnosť nahradiť binárne logy a mnoho mnoho ďalších vecí, ale ako celok to vnímam pozitívne.
Nechcem tu byť za obhajcu systemd, ale treba si uvedomiť, že doba sa trochu zmenila. Časy keď sme na serveri hostovali pár PHP stránok, všetko to bežalo pod apachom, ktorý si sám mangoval PHP, sám si managoval vlastné procesy, sám sa staral o logovanie, sám sa staralo o zapisovanie PID ... sú preč.Ani náhodou. Provozuju na serveru víc než pár stránek, Apache si pořád managuje svoje vlastní procesy, sám si managuje PHP (se suexec, aby to všechno neběželo pod apachem), sám si zapisuje PID, celé to běží pod supervizorem, systemd-free. (A s radostí pozvu na pivo každého, kdo mě přesvědčí, že existuje lepší způsob, jak to udělat.)
Dnes mám na serveri mnoho malých služieb, ktoré bežia samostatne. Niektoré sú štartované na požiadanie, iné štartujú hneď pri boote. Niektoré sa automaticky vypnú pri nečinnosti. Niektoré potrebujú závislosti.Jo, dobrý, uznávám, že supervizor, který umí řešit závislosti a spouštět služby on-demand, není v principu špatný nápad. Ale systemd+universe (mínus bulánci) je špatná realizace.
Ten apache je typický príklad starej služby. Má určitý master proces, ktorý má pid a init systém komunikuje s master procesom cez signály a ten ďalej managuje forky. Ja som potreboval inicializovať služby bez master procesu a bez práv na zápis mimo svojich chrootov.
Ja netvrdím, že systemd je správne realizovaný, ale rieši problém, ktoré som predtým nedokázal vyriešiť bez vytrhania vlasov. Teda ok, aby som nebol zlý upstart sa celkom približoval k tomu, čo som potreboval. Keby bola rozumná alternatíva k systemd tak by som ju rád používal, lebo je až príliš veľa vecí koré mi na ňom vadia.
Ozaj len pre zaujímavosť aký supervizor je dobrý? Pred prechodom na systemd som používal supervisord, ale ten fungoval celkovo nejak divne.
Ozaj len pre zaujímavosť aký supervizor je dobrý?Já používám runit - stačí na to, co potřebuju - tj. spustit službu a držet ji spuštěnou - ale víc toho neumí.
Ja na desktope používam gentoo. Init skripty neriešim, je to desktop, takže stačí, že to naštartuje do X.
Na serveroch niekde ubuntu, niekde debian. S prechodom na systemd som veľmi spokojný. Na rozdiel od init skriptov systemd funguje spoľahlivo a mohol som 200-riadkové monštrá nahradiť 10-riadkovými konfigurákmi. Všetko pekne používa cgroups, niektoré služby majú socketovú aktiváciu, služba sa naštartuje na požiadanie, pri nečinnosti sa pekne ukončí ...
Ako príklad uvediem toto. Sú to len pomocné funkcie k uwsgi, okrem nich init skript includuje ešte 3 ďalšie súbory s pomocnými funkciami, ktoré includujú ešte ktovie koľko ďalších. Celý tento bordel som nahradil dokopy 11 riadkami pre socketovú aktiváciu (to sysvinit nedokáže) a 17 riadkami pre štart a konfiguráciu služby.
Na zdržanlivosť si nepotrpím :P
Ale teraz vážne. Init funguje dobre na služby kde služba naštartuje, zapíše PID a pod týmto PID zostane bežať až kým ju init nekillne. Ak sa aplikácia potrebuje počas behu prepnúť užívateľa, zatvoriť sa do chrootu, využije k tomu exec, vymení PID a nemôže ho zapísať lebo je v chroote tak sa celý init jednoducho zosype pretože stratí PID. V systemd je stále súčasťou cgroup a dá sa bezpečne ukončiť. Ak potrebujem služby zapínať a vypínať dynamicky (teda služba naštartuje pri pripojení na socket a sama sa vypne pri nečinnosti) tak to je v inite tiež neriešiteľné. Takto by som mohol pokračovať pre mnoho ďalších prípadov.
Či som niekedy skončil s nebootovateľným serverom? So systemd zatiaľ nie, s initom niekoľko krát. Na druhej strane na desktope s archom som pár krát skončil s nebootovateľným systemd a úspešnosť bootu so systemd (ak vôbec fungoval) bola tak 75%. Vo zvyšných 25% prípadov sa systém sekol, čo naštvalo hlavne keď som ho nadiaľku reštartoval. To bolo v začiatkoch systemd, takže odhadujem, že teraz to už bude odladené.
Nenabootovať do sysVinit mi príde po rokoch používania Debianu a derivátoch neuveriteľné. Fakt Mirec si to zrejme znásilňoval viac ako sa má. Ja som o tom ani nepočul, nie že by som to riešil.
Neviem kde bol u mňa problém so sysvinitom. Viem, že mi to urobilo na pár VPS-kach keď som tam spustil skript na aktualizáciu vydania. Vtedy som vrátil späť klon, spustil ten istý skript znovu a druhý krát to prešlo a nabootovalo.
Debiania komunita ktorá bola neskutočne veľká a neverím, že by nikto neriešil tvoje problémy.
Moje problémy neboli riešiteľné sysvinitom. V debiane uhackovali niečo, čo fungovalo niekedy keď sa daemon nechrootoval. Väčšina užívateľov to riešila cez supervizora (ale aj s tým som mal problémy).
Nič nedokázalo tak veľkú komunitu rozbiť a predsa sa našiel zmrd, čo to dokázal.
LP mi svojim prístupom vadí, požieranie ostatných projektov mi tiež vadí, ale som pragmatický človek. Potrebujem aby server fungoval spoľahlivo a potrebujem aby som si pri tom nevytrhal vlasy a prekvapujúco systemd toto splňuje z init systémov, ktoré som skúšal najlepšie.
Konfigi treba ukladať, kde ťa napadne, napr. do /usr/lib, to je to pravé miesto.
Umiestnenie unitov v /usr/lib mi žily netrhá. Radšej by som tak dôležitý komponent ako systemd videl v /lib aby sa dal nabootovať systém, ktorý náhodou nepripojí /usr, ale to je drobnosť. Umiestnenie unitov do podadresára lib je mimochodom správne. Len pre zaujímavosť pozri si kde máš umiestnené také veci ako ssl certifikáty, mimetypy, udev pravidlá ...
Vlastné, alebo upravené systemd unity sa ukladajú do /etc, systémové sú v /usr/lib, čo je asi najlepšie riešenie pretože pri aktualizácii ti nerozbije /etc ako sa to dialo doteraz. V gentoo som používal kedysi jeden upravený skript v /etc/init.d a pri každej aktualizácii som musel spustiť diff a aplikovať znovu svoje zmeny.
Kde sa kurwa pripájajú disky a prečo? Asi cez texťák vytiahnem neskurvený log?
Disky neviem, nestarám sa kým to funguje, ale naposledy to používalo normálne fstab. Logy mi fungujú ako doteraz (síce k tomu pribudol binárny log, ale stále sa posielajú aj do syslogu, takže neriešim, ale na nové služby som si už zvykol prezerať cez journalctl).
# dpkg -l | grep udev ii libudev1:i386 232-25+deb9u3 i386 libudev shared library ii udev 232-25+deb9u3 i386 /dev/ and hotplug management daemon # dpkg -l | grep systemd ii libsystemd0:i386 232-25+deb9u3 i386 systemd utility library
Mam pocit, akoby som sa tu bavil s absolventami pomocnej skoly...
Ano, je to tak! udev v debianu je ten ze systemd.A proč by mi to mělo vadit, když funguje i bez běžícího systemd?