Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
# systemctl status -- '-.mount' -.mount - / Loaded: loaded Active: active (mounted) since Fri, 09 Mar 2012 03:57:30 +0100; 1 years and 3 months ago Where: / What: /dev/md127
Na co jsem zapomněl?Na to skoro nejdůležitější. Na obecnou synchronizaci, fyzikálně by se dalo říct určení bodu v čase. T.j. článek se má zveřejnit o půlnoci 11.6., každé pondělí se má něco stát, zaměstnanec se smí přihlásit pouze v pracovní době... Ale jinak souhlas, že je to o požadavcích a předpokladech...
Těch pár služeb, co se jich globální čas nějak víc týká, by měly buď specifikovat závislost na úspěšně synchronizovaném čase (což by měl nabídnout zřejmě chronyd ve spolupráci se systemd), nebo by měly na seřízení času čekat (zřejmě pomocí nějakého API v chronyd). Druhá možnost je aby si poradili s tím, že čas není garantovaný.To API by právě nemělo být v chronyd, ale nějaké obecné (zde je právě prostor pro systemd+dbus,atd...) a chronyd by měl být pouze jeho implementátor (ideálně jeden z mnoha). Stejně tak to nastavení sítě, to je to samé v bledě modrém. Ale to jsme se dostali i trochu dál, mně "vadí", že s tím časem neumí správně pracovat ani sám systemd :)
Ale to jsme se dostali i trochu dál, mně "vadí", že s tím časem neumí správně pracovat ani sám systemd :)A k tomu jste dosel jak? Systemd po startu predpoklada, ze systemove hodiny jsou nastaveny dobre - odhlednemeli od male casove deviace - coz je celkem korektni pozadavek. Vy mu prestavite systemove hodiny pres chronyd, o mesice, a pak se divite, ze runtime vam vraci podivne hodnoty. Co ma podle vas systemd delat? Apriory predpokladat, ze systemove hodiny jsou po startu nefunkcni a pak provest korekci?
Vy mu prestavite systemove hodiny pres chronyd, o mesice, a pak se divite, ze runtime vam vraci podivne hodnoty.Je zajímavé, že uptime mi vrací hodnoty správné, ikdyž mu posunu čas o 10 let...
Apriory predpokladat, ze systemove hodiny jsou po startu nefunkcni a pak provest korekci?Ano, jak jsem psal, spousta zařízení nemá k dispozici HW hodiny vůbec, takže předpoklad, že jsou po startu nefunkční je naprosto správný. A můžu se zeptat, jakou korekci provádí ten výše zmíněný uptime?
Pozadavek zalohovanych CMOS RTC je standardni requirement Windows a Microsoft to chce rozsirit na pouziti HPET, ktere ubastlili spolu s Intelem. Ve vasem pripade, na vasi platforme se jedna o selhani, poruchu HW.Co mají požadavky Windows a Microsoftu společného se systemd? Nebo snad chcete říct, že je to požadavek Intel x86_64 platformy? Ano, na této platformě je často běžné, že čas je správně, ale rozhodně si nemyslím, že je to nějaký požadavek, jehož nesplnění=závada HW.
Urcite by to slo resit lepe, je to cele dalsi pandorina skrinka plna problemu, ale obavam se ze pokus integrovat spravu RTC do systemd by zde nekteri lide uz psychicky neustali .Já už to opravdu déle nevydržím Kdyby to byla jediná pandořina skřínka, ale systemd je jak Pandořino DHL Ale zpátky do objektivní neemoční roviny... Všimněte si, že já nepotřebuju integrovat správu RTC do systemd. Mně by bohatě stačilo použít ten čítač vteřin od startu systému a odečíst ho od aktuálního stavu. Protože, když někdo píše, že "... 1 years and 3 months ago", tak určuje časový interval a ten by se takto velice snadno a elegatně vyřešil. To že by se s tím dalo pracovat dále (například si pamatovat i ten čas a zjistit, že se ty dva časy "rozešly" o rok...), to by bylo hezké, ale to je už nadstandard...
Co mají požadavky Windows a Microsoftu společného se systemd?Systemd nema spolecneho s Windows nic. Pokud ale systemd provozujete na PC platforme kompatibilni s PC AT BIOSem nebo UEFI BIOSem, budete backupovane RTC mit. Bez nich HW neni kompatibilni s Windows, ani s PC specifikaci dohodnutou Intelem, Microsoftem, HP a dalsimi velkymi hraci.
Ale zpátky do objektivní neemoční roviny...My jsme byli v nejake emocni rovine?
Mně by bohatě stačilo použít ten čítač vteřin od startu systému a odečíst ho od aktuálního stavu.Urcite by bylo lepsi pouzit monotonni timer, nulovany pri startu, osetrit preteceni a kombinovat to s RTC. Nicmene to neni reseni treba problemu s logy ci cronem; RTC vam proste nesmi prilis ulitnout.
Bez nich HW neni kompatibilni s Windows, ani s PC specifikaci dohodnutou Intelem, Microsoftem, HP a dalsimi velkymi hraci.Opravdu to v nějaké té specifikaci je? Abysme si rozuměli, já to nezpochybňuju, ale nevím, jestli to tvrdíte na základě nějaké znalosti nebo jen de facto zkušenosti nebo doměnky.
My jsme byli v nejake emocni rovine?My ne, jenom já. A jenom na chvilku v té poznámce o Pandořině DHL
Urcite by bylo lepsi pouzit monotonni timer, nulovany pri startu, osetrit preteceni a kombinovat to s RTC. Nicmene to neni reseni treba problemu s logy ci cronem; RTC vam proste nesmi prilis ulitnout.Je jasný, že RTC nesmí moc ulítnout, k tomu se koneckonců používá to chronyd. A já ani nezpochybňuju to, že budou špatně logy atd... Tohle se dá opravdu řešit jen tak, že se systém rozjede v nějakém "předrežimu", seřídí si hodiny a teprve pak kompletně nastartuje. Ale co mi připadá selským rozumem (nebo jak používá Pavlix common sensem ), tak když něco píše since xxxx nebo xxxx something ago, tak to určuje dobu, která by (teoreticky) měla být na změnách času nezávislá. A teď exkurze do jiné paralelní reality, kde je systemd navržen v souladu s unixovým "dělám jen jednu věc, ale pořádně..." Fakt: systém má k dispozici příkaz uptime, který dokáže s minutovou přesností vypsat dobu od startu systému. Závěr: I kdyby nebyla lepší možnost, tak je možné změřit dobu od spuštění služby do teď s minutovou přesností. Je tedy možné napsat cosi jako "Služba běží 30 minut, pokud je aktuální čas správný, startovala v 10.6.2013 22:41. V mých záznamech je, že startovala 10.5.2012 20:00. To je rozdíl větší než xxx, takže od startu do teď došlo ke změně času v systému." A jen tak malý chyták na konec, co je třeba udělat, aby z prvního výpisu dostal člověk ten druhý?:
Active: active (running) since Mon, 10 Jun 2013 23:15:46 +0200; 5s ago Active: active (running) since Mon, 10 Jun 2013 23:15:46 +0200
Opravdu to v nějaké té specifikaci je?Ano. PC/AT BIOS, cca od 1984, pozadavek od PC DOS 3.0, interrupt 0x1A - RTC Services, viz. treba zde. Od te doby se to vlece az do UEFI BIOSu.
Tohle se dá opravdu řešit jen tak, že se systém rozjede v nějakém "předrežimu", seřídí si hodiny a teprve pak kompletně nastartuje.Není pravda. Stačí počítat logy pomocí monotonních hodin a po seřízení spočítat offset.
Apriory predpokladat, ze systemove hodiny jsou po startu nefunkcni a pak provest korekci?I to je možnost. Když pořád mluví o tom, jak cílí na embedded, tak by měli počítat s tím, že systém nemusí mít ve vypnutém stavu hodiny vůbec žádné.
To API by právě nemělo být v chronyd, ale nějaké obecnéTo je zajímavá teorie. Nicméně pak je potřeba používat nějakou obecnou registrační službu a v ní registrovat obecné události. D-Bus tohle neřeší. Zato systemd to řeší blbě, protože se s něčím takovým vůbec nepočítalo. V systemd je bohužel možné toto řešit jen různými hacky typu že se služba ohlásí jako spuštěná až když úspěšně proběhne synchronizace. OpenRC má něco podobného, jen je to trochu flexibilnější.
Popravdě jsou řečeno závislosti v systemd paradoxně řešeny ještě hůře než před ním.Krasy paralelizace. To casem poladite .
Tam je taky skutečná závislost na funkční síti a ne na forknutí procesu, který se má o síť postarat.A jak je ted network-online.target spolehlivy?
A jak je ted network-online.target spolehlivy?Je to Microsoft-style řešení. Nedělá to vůbec nic, ale hlavně, že se o tom ví. Je to jen přejmenovaný network.target. Navíc je to jen target, který se musí nějak implementovat.
Jinak pro sluzby, ktere potrebuji presny cas pri startu, existuje time-sync.target poskytovany sluzbami chrony-wait.service, ntp-wait.service a ntpdate.service.To se hodí.
Tiskni Sdílej: