Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
Spolek vpsFree.cz zveřejnil data o distribucích, které jeho členové provozují na svých virtuálních serverech. Žebříček jednoznačně vede Debian, následovaný Ubuntu – tyto dvě distribuce běží na 75 % VPS. Dalších 19 % pak tvoří RPM distribuce Fedora, CentOS a Scientific. Seznam uzavírají Gentoo, Arch a openSUSE.
Tiskni
Sdílej:
Zajímavý je i celkový součet: 100 % uživatelů používá GNU/Linux 
Pokud pujde vsechno dobre a neprekvapi mne neco, co ted nevidim, pujde v "dohledne" dobe pod nasima kontejnerama poustet QEMU s KVM akceleraci, takze i BSD pujde. A kazdy clen si to bude moct zaridit, jak bude chtit - akorat zrejme budeme podporovat QEMU/KVM jenom na templatu stejneho systemu, jako bezi na hardware node, protoze resit QA pro trilion verzi QEMU by byla docela chutovka - kdyz uz pracujeme na poautomateni QA featur, ktere podporujeme, tak by bylo dobre pokryt i tohle, protoze tipuju, ze to bude nemalo lidi pouzivat pro provoz veci, na ktere kontejnery samotne nestaci.
Proof of concept funguje, vselijake divne zachazeni to vydrzelo, ale musim tomu venovat podstatne vic casu a snahy, nez si dovolim to pustit do produkce, kdyz to potom taky mam podporovat - usil bych si na sebe akorat pekny bic 
Pouštět plnou virtualizaci pod kontejnerovou je docela úlet Spíš bych dal to KVM vedle OpenVZ a měl na fyzickém stroji jedno společné BSD, ve kterém bych přiděloval kontejnery uživatelům.
Proc je to ulet, krome toho, ze to na prvni pohled vypada dost netradicne? Napriklad SmartOS od Joyentu pousti QEMU v Zones (kontejnery na Solarisu/Illumosu), akorat oni maji to QEMU rovnou jako PID #1. Naopak si myslim, ze je to vyborny napad, protoze to da cloveku mnohem vetsi flexibilitu - muzes si potom v tom kontejneru udelat tech plnych virtualek treba 10, pokud to dava nejaky rozumny smysl a nenastves spravce pretezovanim fyzickeho serveru.
To, co navrhujes, oproti tomu vede na schizofrenii z admin hlediska, protoze to nuti starat se o dve kompletne nesouvisejici prostredi a z toho plyne, aspon z meho pohledu, hromada prace navic s nejasnym, az bych rekl skoro zadnym, benefitem. Ale treba jsem neco pri zvazovani variant prehlidnul.
Also, Jails jako technologie nejsou srovnatelne s OpenVZ, neumim si dost dobre predstavit jaily nabizet clenum; pokud OpenVZ obcas nekoho omezuje ve volbe aplikaci a nastaveni, jaily by omezovaly skoro kazdeho. Ze stejneho duvodu ani LXC neni a jeste dlouho nebude vhodne (a az do toho stadia dospeje, OpenVZ projekt se redukuje akorat na user-space utility, protoze patch prestane byt potreba - LXC je prevazne o tom, upstreamovat nejakym zpusobem funkcionalitu vyvinutou v OpenVZ projektu).
To, co navrhujes, oproti tomu vede na schizofrenii z admin hlediska, protoze to nuti starat se o dve kompletne nesouvisejici prostredi a z toho plyne, aspon z meho pohledu…
A z pohledu uživatele je to přesně naopak – uživatel si chce spravovat různé virtuály a pokud možno chce abstrahovat od konkrétní technologie (KVM, LXC, OpenVZ, Xen…), protože to pro něj je prostě GNU/Linux (případně obecně UNIX/POSIX), na který se může přihlásit po SSH a má tam roota.
Jednotným způsobem chci dělat všechno, co je společné bez ohledu na použitou technologii – zapnout, vypnout, připojit se na sériovou konsoli, podívat se na využití zdrojů atd. Od moderního IaaS očekávám, že v sobě tuhle abstrakci má.
A z pohledu uživatele je to přesně naopak – uživatel si chce spravovat různé virtuály......což taky bude moci, když se to nasadí. Když mám virtuál (kontejner), ve kterém si můžu pustit QEMU/KVM, můžu si ty různé virtuály vyrobit a spustit. Hm, zasíťovat něco takového bude asi zajímavé, co?
Tak vsak ale tak to je ted, proste mas kontejner, pouzivej a je to. A drtiva vetsina lidi si ani nevsimne, ze bezi pod OpenVZ - az jsem nechapal jak je to mozny, ja bych si treba vsimnul hned
A k tomu chystame navic API a moznost ty prostredky, co ted ma jedna VPS na clena, si bude moct clen rozdelit podle urcitych pravidel na vic oddelenych VPS. Takze na to jdeme z obou smeru, aby clen byl co nejmene limitovany tim, ze "oni si tam kluci rekli, ze to bude tak a tak jak to tak".
Pokud pujde vsechno dobre a neprekvapi mne neco, co ted nevidim, pujde v "dohledne" dobe pod nasima kontejnerama poustet QEMU s KVM akceleraciTo jako fakt? To jestli někdy budu vracet komp, kde mam virtuály teďka, tak bych to docela i přesunul. Akorát by to chtělo víc ramky než s kolika vpsfree začínalo.
No, co jsem si s tim par dni hral, tak to chodilo v pohode i se suspend/resume VM a spravou pres libvirt, teda az na par drobnosti pro rozchozeni libvirtu (chybejici polozky v /sys fs v CT hlavne, ale to se da vyresit zatim workaroundem tam ty soubory vykopirovat na tupo z hw nodu a bind-mountnout je pres danej podstrom /sys, IIRC to ma souvislost s osahavanim vlastnosti CPU, to se da do OpenVZ dodelat a nemelo by to bejt slozity). Zkousel jsem CT s nekolika VM pod libvirtem i naklonovat, jestli se nebudou nejak bit mezi sebou ruzne CT, kdyz konfigurace libvirtu uvnitr CT bude identicka a taky to nebyl problem. Ale musim se vic ponorit do cely problematiky KVM v kernelu a poradne to otestovat ze vsech stran.
Ad. RAM, ja osobne bych velmi rad videl zmenu stejnym smerem, ale narazime na cenu modulu - 32G moduly jsou o dost drazsi na 1 GB, nez 16G. Nenapada mne, jak to jinak resit, pokud nechceme swapovat.
Ad. RAM, ja osobne bych velmi rad videl zmenu stejnym smerem, ale narazime na cenu modulu - 32G moduly jsou o dost drazsi na 1 GB, nez 16G.Jaký je vůbec dlouhodobý plán obměny hardware?
Vsechen hardware je Sandy Bridge a novejsi, s tim, co Intel predvadi, si nemyslim, ze ten HW zastarava moralne nejak vyznamne rychle. Cili situaci vidim tak, ze s pribyvajicim vekem toho HW budem koukat, mit adekvatni dostatek rezervniho HW volneho. Pro nas relevantnich featur, ktere Intel slibuje do budoucna, neni zajimavych az tolik - kdybychom bezeli full-virt, byla by situace jina, tam jeste dost dlouho bude co zlepsovat. Z novinek, ktere Intel predbezne slibuje napr. pro Skylake-EP, mi prijde letmym pohledem zajimava zatim akorat jedna - eDRAM L4 cache. Otazka je, jak se projevi u nas, kdyz CPU ani pametova propustnost nejsou bottleneckem. Tim byva spis disk IO, coz se vyhledove vyresi pres NVMe SSD - a to pujde i u vetsiny stavajiciho HW (PCIe form factor).
Jiny rozmer pohled na updatovani HW dostane v pripade, ze by zasadne zlevnily DDR4 pameti; kdyby se cena za GB dostala na rekneme 60-70% ceny/GB u DDR3, pak ma smysl o tom uvazovat prave z pohledu vic RAM.
Moje aktualni uvazovani jde ale spis tim smerem, ze nez za kazdou cenu menit HW, radsi investujeme ty prostredky do lidi, aby se vic lidi z core tymu mohlo venovat vpsFree na plny uvazek. Ja jsem prvni (od unora) a jeste jsou na rade minimalne dalsi 2 kusy . Uvidime, dost zalezi, jak budeme rust dal. Kazdopadne bych chtel, aby se vpsF vic podilelo na vyvoji softwaroveho ekosystemu, ktery pouzivame - kam uz mirime, takze to staci akorat podporovat dal. A rad bych videl vic aktivity smerem k podporovani nezavislosti jednotlivcu na cloudech. Ultimatne bych vpsFree.cz videl jako dobreho predchudce mozneho globalni open cloudu - vpsFree.org jako zastresujici organizaci pro lokalni implementace nosim v hlave uz delsi dobu. Ale od toho mame jeste vcelku daleko, je potreba pritahnout vic lidi, protoze dostat se tam je spousta prace.
Z hardwaroveho hlediska by se mi strasne libilo mit rychlejsi sit s nizkou latenci, protoze bych rad vyresil "data locality problem", chtel bych distribuovat data nad siti, aby CT nebyly uveznene na konkretnim serveru. Ale situace s 10GE je az trapne smesna, ceny nepadaji, levne L2 managed switche se 48 porty nejsou a L3 switche jsou pro nas totalni zbytecnost. 40GE je uz uplny vysmech. S cim dal vetsi intenzitou premyslim o QDR Infinibandu (40G wirespeed) a nebal bych se klidne second-hand switchu, pokud bude cely backbone redundantni. A za usetrene $ se da koupit jeste dalsi nahradni kus (kdyby jeden :D). Totiz diky vyuziti IB hlavne v HPC, kde je jim jakakoliv propustnost malo, s rozsirenim FDR IB (56G wirespeed) vcelku QDR opadly ceny. No a na distribuovani dat nad sit jsme zase kruhem zpatky u potreby vyvoje a hlavne QA, QA, QA.
Jety HW temer nikdy neprodavame, vlastne si nemuzu vzpomenout na jediny priklad. Funkcni, ale dlouho jete disky, pak konci v rukach aktivnich clenu, kteri maji tak jako tak root pristup. A pokud jdou nahodou nekomu mimo, tak je premazavam - s ohledem na schopnosti, znalosti a motivace ciloveho cloveka, ktery ten disk dostava do ruky. Pravda, ze se nikdy nekaslu s nasobnym premazanim, ale ty disky nikdy nekonci u nekoho, koho bych neznal a tim padem mam temer uplne 100% jistotu, ze to z toho disku fakt nebudou schopni dostat.
Ostatni hardware - no, towery skoncily jako workstationy aktivnich clenu, pokud vim, neumrel z nich zatim ani jeden, jedine nasi prvni masine vubec umrel asi pred rokem zdroj. No a ted nas ceka uvolneni prvnich rackovych masin, ktere se nedaji preskladat na workstation, jelikoz ta deska si nerozumi s zadnou externi grafikou a ta integrovana zvlada myslim akorat 1280*neco rozliseni. Na produkcni nasazeni jsou nam ty masiny uz moc slabe, takze nektere z nich pujdou na automatizovane buildeni naseho systemu a jeho testovani a co zbyde, rozdame neziskovkam s podobnym zamerenim. Ono jich neni zas tolik, ted pujde o 4 kusy, 2 z toho pujdou na QA, 1 kus pujde do lbcfree.net a jeden jeste neni alokovany. Mam v planu se zeptat kluku z Brmlabu, jestli by pro ni meli dostatecne vyuziti, kazdopadne urcite nechci, aby ten HW skoncil nekde, kde by se valel jen tak, bez vyuziti.
Nejvic umiraji disky, sem tam nejake to SSD (vzdycky vsechno mozne, krome opotrebeni NAND modulu), pak jsme meli myslim jedno nebo dve umrti desky a celkem tri nebo ctyri predcasne odchody pametovych modulu. Jinak se spolehlivosti HW nemame problem.
Funkcni, ale dlouho jete disky, pak konci v rukach aktivnich clenu, kteri maji tak jako tak root pristup. A pokud jdou nahodou nekomu mimo, tak je premazavam - s ohledem na schopnosti, znalosti a motivace ciloveho cloveka, ktery ten disk dostava do ruky. Pravda, ze se nikdy nekaslu s nasobnym premazanim, ale ty disky nikdy nekonci u nekoho, koho bych neznal a tim padem mam temer uplne 100% jistotu, ze to z toho disku fakt nebudou schopni dostat.Uff. To jsem asi nechtel slyset. Nu, hlavne, ze je ta jistota skoro 100%.
Btw to opravdu aktivni clen dostane do ruky disk s daty klientu? Ja zapomnel, vzdyt ma beztak roota.
At zije neziskovy sektor.
Říkat pravdu je samozřejmě v pořádku a otevřenost a možnost zapojení členů je jednoznačně velká výhoda občanských sdružení.
Ale nechápu, co je na tom za problém – stačí mít nějak nastavený proces „vyřazování disků“ a držet se ho. Vždyť by stačilo tam pustit badblocks – je to zadání jednoho příkazu do konsole. A když je disk úplně mrtvý, tak můžeš rozdat motory a magnety, ale plotny zničíš.
Jaký je rozdíl mezi tím, když má někdo roota a plný přístup k těm datům, a když dostane disk s těmi samými daty?
I když má člověk roota, tak očekávám nějakou minimální kontrolu – alespoň zpětně – lze dohledat logy, kdo (otisk SSH klíče) se kdy kam přihlásil, případně i jaké příkazy spouštěl. Taky se dá evidovat, kolik kam teklo dat – když někdo vytahá ze serveru po síti stovky GB nebo TB dat, je to minimálně podezřelé. I když to bude neznámá IP adresa (to může být zase útočník zvenku).
Tyhle kontrolní mechanismy nemusí fungovat 100%, dají se obejít a dokonce ani nemusí vůbec existovat – ale i tak fungují jako psychologická bariéra, takže to většina lidí ani zkoušet nebude.
Oproti tomu je celkem zásadní rozdíl, když máš disk fyzicky u sebe, můžeš s ním pracovat offline a nikým nepozorován z něj sosat data. Tohle si člověk zkusí už jen ze zvědavosti, aby zjistil, jestli je ten druhý takový blbec, že mu dal nepromazaný disk s citlivými daty. Kdybych si koupil starý disk třeba v bazaru nebo ho někde dostal, tohle je první věc, kterou bych udělal (po kontrole S.M.A.R.T. hodnot). Prostě obyčejná zvědavost a snaha zkusit si, jestli to jde.
Další věc je, že v tom nemusí být vůbec úmysl. Člověk si ten HW může vzít proto, že je zadarmo, levný nebo že mu přijde škoda, aby skončil ve šrotu. Později zjistí, že ho zase tolik nepotřebuje a časem ho někam odloží nebo daruje dál…
i tak fungují jako psychologická bariéra, takže to většina lidí ani zkoušet nebude.To je dost sporné a záleží to jenom na motivaci. Skutečná překážka bránící úniku dat to není ani náhodou. Ale chápu, hlavním argumentem je dobrý pocit, že se něco dělá. Bez ohledu na to, jestli to dává smysl nebo je účinné.
A ještě jeden dobrý důvod: vystupování směrem ke stávajícím a potenciálním členům – když budu vědět, že roota má jen pár vybraných lidí, jejich činnost se kontroluje a že se důsledně promazávají vyřazené disky, budu z toho mít mnohem lepší pocit.
Disky jsou promazane ddckem, pokud je nedostava primo clovek s root pristupem pro svoje pouziti. A v tech pripadech vzdycky vim, jake pouziti na to kdo ma. Dokud pro ty disky pouziti neni, tak se vali v racku. Root pristup se nerozdava jen tak, musim ty lidi znat delsi dobu a musi se vytvorit dostatecna vzajemna duvera. Aktualne maji roota 4 lidi (a vic uz asi ani nebude potreba), coz znamena dostatecny odbyt do domacich NASu na to, abychom to nemuseli zatim resit vic. A taky je dobre rict, ze bez urcite miry duvery by nam ta organizace nefungovala.
Ale chapu, kdyz budete chtit, vzdycky se da najit neco, na co budete nadavat, ze to delame spatne a proc si o nas myslet, ze jsme amateri (nebo viz troll Odin a jeho teorie, ze komercni sfera dela vzdycky vsechno lip). Myslim, ze to asi nema cenu dal rozebirat.
Soukromi a data clenu nam ukradene nejsou, to z toho kdo chce, myslim pochopil, akorat nejsme tak ultra paranoidni, jak by se treba Frantovi libilo Je to spatne? Ja si to nemyslim.
Bylo by fajn, kdyby k tomu přepisu při vyřazování docházelo vždy, to je tak jediné možné zlepšení, které mě napadá.
Souhlas, o to mi v zásadě šlo. Badblocks je sice lepší, ale i dd if=/dev/null je pro tyhle potřeby celkem dostatečné. Mělo by se to dělat, i když se disky darují „důvěryhodným“ lidem. Ve chvíli, kdy se ten starý disk vyndavá ze serveru, tak už by měl být promazaný.
(a když ten disk odejde úplně a promazat nejde, tak bych to viděl na fyzickou likvidaci ploten – ono vyčíst z mrtvého disku data není až takové sci-fi)
Presne tak. Technicky je OpenVZ kontejnerova virtualizace pro Linux, sestavajici z kernel patche a k nemu pridruzenych nastroju, jako celek to davaji dohromady aktualne podle meho nazoru nejschopnejsi kontejnerovou virtualizaci vubec.
Co se jaderne stranky tyce, je OpenVZ patch proti RHEL5 a RHEL6 kernelum, vyvoj novych vlastnosti ted bezi primarne nad RHEL6 jadrem. Patch pro RHEL7 jadro slibuji vyvojari do konce H1/2015, ale muj odhad je, ze to o neco presvihnou, pocitam tak s koncem leta. Potom bude vyvoj pokracovat nad RHEL7 kernelem a RHEL6 patch bude pokracovat v udrzovacim a obcasnem backport modu.
Vzdycky jsem si myslel, ze Parallels (ti, kdo plati vyvojare OpenVZ) maji nejakou smlouvu s Red Hatem a maji pristup ke gitu RHEL kernelu, ale byl jsem vyveden z omylu - soudruzi z OpenVZ projektu stavi svoji praci presne nad tim, co je dostupne i vsem ostatnim - tj. jeden megapatch proti 2.6.32(.0). Takze se ani nedivim, ze jim to cele kapku trva
Pro novou verzi zalozenou na RHEL7 se konecne OpenVZ projekt hodla otevrit vic komunite a umoznit uzivatelum aktivneji prispivat. Git repozitar s RHEL7 OpenVZ jadrem by mel byt verejny, coz eliminuje hromadu prace, kterou bych musel delat. Kolikrat jsem chtel nejakou drobnost, ale vstupni bariera je tak vysoka, ze mam lepsi veci na praci. Takze se na to vcelku tesim.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
6.5.2015 21:20
7.5.2015 09:35
9.5.2015 11:08