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.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Zdravim,
chcel by som, aby mi pri kompilacii pomahali skolske PC. Ma to ale problem - tie PC obsahuju 32bit "smejdarnu" - OS a aj vsetky nastroje, pricom ja chcem kompilovat programy pre architekturu x86-64.
Napadlo ma skompilovat cross toolchain pre skolske PC, ale mam problem, ze na kompilaciu mi nestaci kvota a roota nemam.
Teda riesenim by bolo nainstalovat si 32 bit cross toolchain pre moj domaci 64 bit system a pomocou neho skompilovat cross toolchain pre skolske PC.
Je toto najjednoduchsie riesenie? Ak nie, tak ako to spravit jednoduchsie? Distcc nie je podmienka, je to len aktualne nastavenie.
Myslíš, že bez roota niečo skompiluješ ?
Ja si myslim, ze kludne. Ak sa pocita len "rucna kompilacia" (=nie emerge), tak kompilujem len pod neprivilegovanym uzivatelom a zatial vsetko bezi. Na "dojem" roota mi staci fakeroot.
Čo konktretne potrebuješ skompilovať ?
Tvoj pc na to nestačí ? Aké máš komponenty vo svojom PC ? Myslíš, že školské PC budu na to lepšie.
Naštuduj si ccache
. Možno to pomôže skrátiť čas kompilácie.
To subjektivne nepomohlo - skompiloval som kernel 2 krat (raz po bisecte) a pravdepodobne to cacheovanie nie je stavane na taketo upravy alebo mam mozno nieco zle nastavene (nastavovanie nebolo skoro nijake, len par env. variables a instalacia ccache).
$ ccache -s
cache directory /home/user/.ccache
cache hit (direct) 2
cache hit (preprocessed) 14
cache miss 27353
called for link 63
called for preprocessing 5035
unsupported source language 184
no input file 5129
files in cache 56328
cache size 4.3 Gbytes
max cache size 5.0 Gbytes
Mne sa osvedčilo pred ďalšou kompiláciou vyčistiť adresár s už skompilovanými objektmi. Takto to aspoň funguje pri kompilácii kernelu.
A ako teda urychlit tie dalsie akcie?Pořídit rychlejší počítač, ať už osobní nebo buildserver. Ale rychlejší především v oblasti storage.
nak aj zmensenie trvania na polovicu pri desiatkach PC by mi aspon trochu pomohlOd určitého počtu při sebelepší konfiguraci prostě nebudeš mít, co na ty počítače odložit. Nedá se té kompilaci úplně vyhnout a nechat to na nějakém distributorovi?
Pořídit rychlejší počítač, ať už osobní nebo buildserver. Ale rychlejší především v oblasti storage.
Tak na to asi nemam, kedze nejde o nic komercne. Teraz ma napadlo, ze by to mozno islo buildit na ramdisku, ale na to asi nemam vela RAM (cely build mi tusim nesiel pri menej ako cca 10GB disku)
Od určitého počtu při sebelepší konfiguraci prostě nebudeš mít, co na ty počítače odložit.
S neidealnym skalovanim pocitam; ide mi aj len o nejake zrychlenie.
Nedá se té kompilaci úplně vyhnout a nechat to na nějakém distributorovi?
To je dobry napad, diky moc. Davnejsie som sa k openSUSE build service nedostal kvoli chybe na stranke, teraz to uz tusim funguje, tak to skusim.
Tak na to asi nemam, kedze nejde o nic komercne.
120GB SSD dnes pořídíte kolem 2000 Kč s DPH, na buildroot z něj bude stačit tak 16 GB, takže ještě zbyde dost na kořenový filesystém a nějaký pracovní. Rozdíl v rychlosti buildu je dost zásadní.
Teraz ma napadlo, ze by to mozno islo buildit na ramdisku, ale na to asi nemam vela RAM (cely build mi tusim nesiel pri menej ako cca 10GB disku)
Pokud nepotřebujete debuginfo (což pro bisect obvykle nepotřebujete), dá se jeho vypnutím náročnost výrazně snížit. Např. na build (x86_64) jádra SLES 11 SP2 nebo OpenSuSE 12.2 mi bez debuginfa pro buildroot stačí 4GB tmpfs, zatímco s ním bych potřeba asi 9-10 GB. Jako bonus bude build i o dost rychlejší. (Hodnoty jsou pro kompletní build distribučního balíčku pomocí "osc build
", pro build samotného jádra a modulů přímo ze zdrojáků to bude o něco méně.)
To je dobry napad, diky moc. Davnejsie som sa k openSUSE build service nedostal kvoli chybe na stranke, teraz to uz tusim funguje, tak to skusim.Akorát hodně těch veřejných build služeb je pomalejších než lokální build.
Robim git bisect, takze su to zasadne zmeny skoro vsade, kde sa udiali medzi Linux 2.2. a Linux 2.3. Kompilacia jadra trva s ccache cca 3 hodiny (je to vanilla, ale bug sa neprejavuje pri mojom mini configu - prejavuje sa pri distribucnom configu, takze treba kompilovat vsetko alebo nejak skusit "bisect" na kernel config).
Stve mna, ze pri pisanych 12 krokoch je to cca 36 hodin a ak niekedy nezaregujem hned a PC vypinam vzdy, ak je mimo mojho dohladu (spim, nie som doma), tak to budem riesit este minimalne tyzden.
Pripojenie snad nepotrebujem riesit - ak to pri testovani nejak bude fungovat, tak to dam svoj PC do skoly na LAN, kde to v optimalnom pripade pojde 1Gbit.
Dakujem, uz som to vyriesil, aj ked nakoniec pomohol upraveny modprobe a trocha intuicie. Tie 3 hodiny boli kvoli modulom (distribucny kernel), lebo v osekanom kerneli sa mi bug neprejavoval.
Takze keby niekomu nefungovalo pripojenie Androidu k PC, tak treba v kernel configu vypnut CONFIG_USB_OTG, ktore v poslednom case zacali zapinat packageri. Bug je este o nieco hlbsie, ale to tu uz nebudem rozoberat.
Tiskni Sdílej: