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.
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í.
Jelikož jsem dlouho nic nepostnul o vpsFree.cz, tady je zápisek jako pokus o nápravu. Aneb vpsAdmin, obrovský úspěch adWords, downtimes, stav počtu členů, finanční stav.
Pro solidně klikací administraci OpenVZ jsme hledali nějaký solidně použitelný administrační panel. Možnosti jsou, a je jich dost, jenže a) nic není dotažené b) nic neumí dostatečně využít vlastností OpenVZ c) pokud to náhodou splňuje a) a b), je to jiným způsobem nepoužitelné (Ruby neumím, integrované řešení jako distribuci nechci, daemon v C jako backend se mi nezdá).
A tak jsem začal minulý rok na podzim bastlit vpsAdmin. Dneska už umí celkem dost - vytvářet/mazat VPS, start/stop/restart VPS, zobrazí stav virtuálu, nastaví limity, přidělí IP, monitoruje datové toky NIX/mimo NIX, nakliká pravidla firewallu pro iptables (jako workaround pro napůl funkční iptables přímo ve virtuálech), online a offline migraci VPS mezi HW servery, správu členů a základní evidenci kdo zaplatil a kdo ne. Další kupa vlastností se chystá.
Až dorazíme k verzi 1.0 (= použitelnost mimo vpsFree.cz servery, to bude docela brzo), pokud bude zájem, postnul bych potom článek/blog o tom, jak to zprovoznit a používat.
Když jsme zprovoznili Betu (hostname 2. serveru), měli jsme strach, že neseženeme dost členů, aby se nám náklady na ni vrátily a aby se vůbec zaplatil housing. Rozhodli jsme se tedy zkusit adWords jako způsob, jak získat nové členy. Výsledky jsou teda dost nevalné, je pravda, že jsme na to dali jenom 2000Kč, ale ze skoro 1 milionu impresí se vyklubalo jenom okolo 200 kliků a členů jenom pár. Linuxáři mají evidentně v hlavě firewall na reklamy (za sebe můžu potvrdit). No co, aspoň vím, co příště pro cílovou skupinu "ajťáci" nepoužívat.
Objevili jsme ale novou cílovou skupinu, a to lidi, kteří chtějí herní servery, ale neumějí je zprovoznit. A tak dělám helpdesk pro CS 1.6 provozovatele serverů (trochu nadsázka). Hlavní problém je v tom, že herní servery generují dost trafficu, kterého nikdy není dostatek (ale pokud nejsou public, tak se to dá).
Ačkoliv bych řekl, že dostupnost našich serverů je na občanské sdružení víc než slušná, downtimům se prostě nevyhneme. Přehled downtimů (jsou měřeny pomocí monitoring-serveru.cz free varianta, takže minimální rozlišení 10 minut, i když je to jedna nebo dvě minuty v reálu):
Alfa:Dneska, tj. 24.8. jsme zaregistrovali 31. člena. Momentálně máme ještě něco okolo 30ti volných pozic na VPS.
Servery úspěšně splácíme, housing platíme bez problémů a stav účtu neklesá pod 2násobek měsíčních výdajů za housing.
Koho by to zajímalo, účet je transparentní, podívat se může tady.
Myslím, že oproti tomu, co jsem čekal na začátku, když jsme vpsFree.cz zakládali, jsme napřed aspoň 10x. Za to moc děkuju všem našim členům a hlavně Frantovi a Tomsovi, za jejich čas, který do toho vráží. (můj nepočítám, je to přeci jenom můj výmysl a taky moje blbost , na druhou stranu, zatím mi to dalo hodně zkušností, které jinde neseženu). Zájemce o členství v tomhle sdružení vítáme, samozřejmě, a dotazům jsme otevření.
Tiskni Sdílej:
Hlavní problém je v tom, že herní servery generují dost trafficu
Většina ne.
No, o CS:S serverech jsem slyšel, že geerují hodně trafficu, CS 1.6 nevím. Každopádně u ničeho jinýho jsem si toho nevšiml
Třeba mně tam běží veřejný Sauerbraten server a ten nežere skoro vůbec – viz svickova.frantovo.cz – kdybyste si chtěl někdo zahrát, tak napište na jabber.
ty se tam nepřihlásíš? já žádné heslo nezadávám a občas si tam i s někým zahraju
Asi bychom časem měli umístit jeden server do serverovny s neomezenými přenosy – pro tyhle případy – ať si pak lidi vyberou, jestli chtějí kvalitu a budou se držet trochu na uzdě, nebo chtějí neomezené přenosy a nevadí, že budou občas výpadky nebo problémy. Pak je tu ještě třetí možnost – neomezené přenosy a vysoká kvalita – myslím, že pokud to někdo zaplatí, není problém něco takového zorganizovat pod křídly našeho sdružení – ovšem cena se odvíjí od nabídky datacenter a s tím nic nenaděláme.
Člověče, to vám výměna jádra dá vždycky tak zabrat?
Vždyť se prostě uvaří nové jádro, potřebné soubory se překopírují do /boot a až když je vše připraveno, tak se zavaděči řekne, ať pro tentokrát natáhne nové jádro. Pak dáme reboot a obvykle naběhne nové jádro (aby ne, když se používá oldconfig). Záležitost nejvýše dvou minut. Když se něco pokazí, tak stačí reset a najede starý systém a pak si může člověk v klidu rozmyslet, co udělal špatně. Po úspěšném bootu pak ještě zbývá kontrola, že vše, co má, běží, ale to už nemá vliv na dostupnost služeb. Po nějaké době (hodiny, dny), kdy je stabilita nového jádra prověřena, se v konfiguraci zavaděče přesune nové jádro do výchozí polohy a tím upgradovací cyklus končí.
> V takovém případě ale stačilo na power switchi odpojit na chvíli napájení a server by nabootoval do starého jádra.
Pokud to mas tak v GRUBu nastavene.
Dokonce jsem se vás chystal zeptat, jaké řešení plánujete pro tu "online migraci".
Tohle jsem taky řešil, a použitelně vypadá snad už jen DRBD. Zdá se mi dost ověřený a funkční, na vlastní testování se teprve chystám. Jinak pár lidí tady už psalo, že s tím mají velmi dobré zkušenosti. Já mám pořád strach, že když něco takové zprovozním, budu se nejvíc bát aby se to nerozpadlo (stav split-brain, když si každý uzel myslí, že ten druhý spadnul).
Nad DRBD může být normálně Ext3 - pak může být FS připojen jen na jednom z uzlů. Nebo nějaký clusterový FS, třeba OCFS2 nebo GFS - pak můžete zapisovat z obou uzlů DRBD zároveň. Nebo lze mít nad DRBD svazkem clustered LVM pro Xen virtuální disky, pak lze dělat i živou migraci Xen guestů mezi fyzickými stroji.
Online migraci řeší OpenVZ utilitka vzmigrate. Nejdřív sesyncne (přes ssh) stav virtuálů (rootfs, context - paměť, stav v jádře atd.) a pak jednoduše "přepne" mezi HW servery. Pravda je, že úspěšnost online migrace není 100%. To jsem ve vpsAdminu vyřešil fallbackem na offline migraci.
DRBD se mi osobně moc nezdá, jednak je to moc v kernelu, to má nic-moc výkon a je to nestabilní (aspoň co jsem to zkoušel naposled). Navíc to neumí pravej multimaster pro víc než 2 nody. Takže jediný řešení vidím v GlusterFS 2.
Online migraci řeší OpenVZ utilitka vzmigrate. Nejdřív sesyncne (přes ssh) stav virtuálů (rootfs, context - paměť, stav v jádře atd.) a pak jednoduše "přepne" mezi HW servery.
Hmm, tak to je docela pěkné.
K DRBD se dají najít informace o seriózním a stabilním nasazení, problémy s výkonem by neměly být zásadní (je samozřejmě nutné propojení Gb ethernetem, popř. více Gb rozhraní v trunku). Ale je pravda, že to bude citlivé na verzi jádra + verzi DRBD modulů, bude to chtít trochu ladění nebo zjistit ověřenou konfiguraci a moc na to nesahat. Pro víc než 2 stroje to taky není. Jako možné řešení bych viděl 2× storage server s výkonným s mnoha disky v HW RAIDu + replikace přes DRBD, podívejte se na distribuci OpenFiler, tam údajně iSCSI a DRBD funguje bezvadně. A k tomu hromadu serverů, na kterých poběží OpenVZ virtuální servery. Propojení přes iSCSI a nad tím GFS. Obecně bych asi čekal, že clusterové věci budou vyladěné v enterprise distribucích, při použití skoro-poslední verze jádra asi lze čekat problémy...
Až budete mít plný rack, můžete uvažovat o nějakém diskovém poli s iSCSI rozhraním.
Glusterfs vypadá hodně zajímavě, ale mě tam chybí podpora uživatelských kvót a ACL.
Glusterfs vypadá hodně zajímavě, ale mě tam chybí podpora uživatelských kvót a ACL.Tak to potom AFS nebo Lustre.
AFS – pokud myslíte Andrew File System, tak tam pokud vím ani replikace dat není. Je možné mít data ve více kopiích, ale jen jedna je RW, ostatní jen pro čtení. Nutnou součástí je Kerberos autentizace. Kouzlo AFS je v něčem jiném - je to globální filesystem, používá se v prostředí s desítkami tisíc uživatelů - např. univerzity (určitě na ZČU, jako hlavní síťový FS), CERN. Tady si vlastnostmi nejsem úplně jistý, ale pro tohle použití to není vhodná věc. AFS je distribuovaný - tj. data v rámci jedné adresářové struktury lze mít transparentně uložená na různých serverech.
Lustre – co jsem našel, tak je to pro clustery se stovkami až tisíci stroji, nic moc vhodného pro 3 servery.
viz http://en.wikipedia.org/wiki/Replication_(computer_science)#Disk_storage_replication
ad AFS - nevěděl jsem. ad Lustre - no, je pravda že to je kapku overkill pro 3 stroje Smutnou pravdou je, že současnej stav není ideální ani u jednoho FS / replikačního cluster řešení. Ona to asi není žádná sranda to odladit tak, aby to jelo výkonně a spolehlivě.
Každopádně GlusterFS se hodí tam, kde není potřeba dělat psí kusy -> takže záloha, sdílená data pro nějakou aplikaci a podobně. Rootfs VPS na to stejně nejde umístit, to lze (u openvz) jenom na ext2/3.
S tím zhodnocením situace souhlasím. Holt kdo potřebuje takový výkon a spolehlivost, obvykle má prostředky i na pořízení nějakého plně HW řešení replikace, nebo alespoň diskového pole s redundantními řadiči a propojením k serverům. Software řešení na normálním HW stejně bude mít vždycky značné limity ve výkonnosti, takže po vývoji něčeho takového nebude až tak velká poptávka.
Pro méně náročné situace myslím stačí ten GlusterFS nebo DRBD, kde se zřejmě dá postavit spolehlivé řešení, i když ne úplně ideální a podle všech představ (poslední kernel etc.).
Jinak k takovéhle diskusi by měla sloužit i skupina Virtualizace (uvažovalo se snad o doplnění názvu + High Availability), kde si toho spíš někdo všimne. Určitě tam jsou lidé, kteří by k tomu měli co říct. Zkuste položit dotaz i tam.
Mate to nejak pravidelne zalohovane? O necem takovem uvazuji pro osobni/komercni repozitar, ale bez zaloh bych do toho nesel.
No bolo by super keby alpha zalohovala betu navzajom (to najdolezitejsie) + nejake zalohy na 3. cisto backup server ...
Nevim, jak OpenVZ funguje, jestli mate pristup do filesystemu virtualu, ale pokud jo, tak by mozna bylo nejlepsi zaloha: zakaznik nadefinuje adresare a ty se zalohuji. Precijen zalohovat cele virtualy muze byt prostorove celkem narocne...
Zase když jsou zálohy v režii zákazníka, tak si sám může vytáhnout třeba smazané soubory nebo přepsané konfiguráky ze zálohy – když se zálohuje všechno najednou, tak je to opruz, který musí dělat správce centrálního serveru. Docela zajímavý by byl solaris a jeho ZFS snapshoty – možná až budeme dělat další server…
solaris a jeho ZFS snapshoty
A nebo taky FreeBSD...
Jen malý dotaz: jakou máte dostupnost?
Já se neptal na to, co vysype minun na základě historie, ale co garantuje občanské sdružení nebo čeho by chtěli administrátoři dosáhnout.
Neměří to minun ale nezávislý měřák
Čeho bychom chtěli dosáhnout? Co garantujeme? Ale no tak, naslibovat se dá cokoli, důležité jsou výsledky Chceš čtyři devitky, nebo víc, 100%? Slíbit můžeme cokoli, ale pokud chceš SLA a smluvní pokuty pokud nebude dodržená požadovaná dostupnost… budeš muset zvolit komerční dražší hosting. Pro dostupnost děláme to nejlepší, co umíme, ostatně, běží na tom i naše stroje.