Boudhayan "bbhtt" Bhattcharya v článku Uzavření kapitoly o OpenH264 vysvětluje, proč bylo OpenH264 odstraněno z Freedesktop SDK.
Představeny byly nové verze AI modelů: DeepSeek V3-0324, Google Gemini 2.5 a OpenAI 4o Image Generation.
XZ Utils (Wikipedie) byly vydány ve verzi 5.8.0. Jedná se o první větší vydání od backdooru v XZ v loňském roce.
Byla vydána nová verze 0.40.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 2.20 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
LibrePCB, tj. svobodný multiplatformní softwarový nástroj pro návrh desek plošných spojů (PCB), byl vydán ve verzi 1.3.0. Přehled novinek v příspěvku na blogu a v aktualizované dokumentaci. Vypíchnut je interaktivní HTML BOM (Bill of Materials) a počáteční podpora Rustu. Zdrojové kódy LibrePCB jsou k dispozici na GitHubu pod licencí GPLv3.
Minulý měsíc Hector "marcan" Martin skončil jako upstream vývojář linuxového jádra i jako vedoucí projektu Asahi Linux. Vývoj Asahi Linuxu, tj. Linuxu pro Apple Silicon, ale pokračuje dál. Byl publikován březnový přehled dění a novinek z vývoje. Vývojáře lze podpořit na Open Collective.
Ruská firma Operation Zero nabízí až $4 miliony za funkčí exploit komunikační platformy Telegram. Nabídku učinila na platformě X. Firma je známá prodejem exploitů ruské vládě a soukromým společnostem. Další informace na securityweek.com.
Po 9 týdnech vývoje od vydání Linuxu 6.13 oznámil Linus Torvalds vydání Linuxu 6.14. Proč až v pondělí? V neděli prostě zapomněl :-). Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies.
Konference LinuxDays 2025 proběhne o víkendu 4. a 5. října v Praze v areálu ČVUT v Dejvicích na FIT.
S tím, jak firma roste, s tím, jak rostou požadavky, tak musí růst i IT. Když se podívám, jak to vypadalo kdysi, jaké byly začátky a jak to vypadá teď, tak co pár let je prostě nějaká novinka, vyšší a vyšší standardy atd.
!!! Následující text nemusí odpovídat chronologicky a většina článků byla sepsána až třeba po 2 a více letech provozu a zkušeností !!!
Začátky byly dost poklidné a plné práce, která se dnes už tolik neřeší. Když jsem nastupoval do jedné firmy, tak byla doba WinXP + Office 2000/2003. Na všech klientských PC uživatel jako admin, linux nikde, jeden file share, dva PC na obslužný sw a jeden server s oracle db. Člověk řešil počítače, tiskárny, support uživatelům, tahání kabelů, stěhování a to bylo tak všechno.
Moje první produkční virtualizace byl VMware Server, který jsem ve free verzi nasadil na jeden desktop, abych zvirtualizoval dvě mašiny. Bylo to kvůli tomu, že na nich běžel zabugovaný sw (myslím, že to byl DTS od Software602), který dokázal napůl zamrznout a znemožnit připojení k PC na dálku (vnc/rdp). Když člověk nebyl přítomný, aby myší zavřel a znovu spustil DTS, tak musel do práce vyrazit a pořešit to. Konzole od vmware toto řešila. Pamatuji si, že to býval porod, dělat upgrady VMware Serveru, že né vždy to procházelo ideálně. Pak přibyly požadavky na audit uživatelských stanic a kvůli bezpečnosti i předělání všech uživatelů z admin účtů na user účty. Pár uživatelů (150?), pár poboček, pár cest do zahraničí.
Na podobné téma jsem také něco sepsal: Co se stane při aktualizaci 170PC s winxp z 0% stavu na 100%.
Taktéž jsem zkoumal čím dál více vnitřnosti Windows a snažil se všechny stanice konfigurovat nějak centrálně a rychle (tenkrát ještě přes Novell Netware startup script): SCRIPT : Jak během vteřiny nastavit (pár stovek) windows ...
V té době jsem čím dál více musel i řešit licence, takže: Licenční peklo. Nutnost komunikace s celníky přibalil program Helios IQ a k němu MSSQL. Přibyly také zkušenosti s kamerovými systémy a postupně přebírání správy a instalace nad nimi. Dřívější Mail602 řešení bylo nahrazeno Exchange 2007 (opět zápisek se zkušenostmi: Exchange 2007 SP1 a roční zkušenosti). S Exchangem se vezly CAL licence, takže nastal i čas zbavit se Novell Netware a nasadit Windows Server jako fileshare. Nastala také nutnost lepšího systému záloh, což přišlo v podobě CA ARCserve Backup (doteď si vzpomínám, co to bylo za nehorázný shit). Zálohy se dělaly stylem rotace pěti 250GB disků, které se později vyměnily za 500GB a později za 1TB.
V soukromí jsem jel už delší dobu Linux a měl bokovky v IT, spravoval jsem tenkrát soukromě asi 50 PC různým známým a známým známých atd. Tenkrát frčelo pro vzdálenou správu LogMeIn. Pronikám víc a víc do síťování, řeší se vlany, stp, loopy a další věci (HP ProCurve 2810 - VLAN - STP).
Když pominu VMware Server, tak jsem začal s ESXi 3.5 free, pokračoval na 4.x free. I tady na abc jsem o tom napsal článek (Základní info o ESXi free a dlouhodobé zkušenosti). Začalo se pro více věcí nasazovat Linux i do firmy. Přibyla nutnost i zlepšit dostupnost emailů, takže se po delším výběru nasadil GFI Mailarchiver, viz: Enterprise řešení archivace emailů v podání GFI Mailarchiver.
Taktéž se řešila automatizace a problémy s tím spojenými, takže se řešily problémy s RFID: Enterprise řešení RFID v podání firmy Intelleflex. Taktéž je čas řešit vlastní HA proxy pro všechny app, radius server pro vpn a další a další věci. Je třeba také řešit trochu lépe monitoring, takže Nagios, resp. Centreon: Seriál: Nagios + Centreon + MySQL. Nasazujeme vlastní řešení kiosků s termotiskárnama.
Byl potřeba nějaký lepší systém pro faktury a další věci, takže potřeba nasadit DMS: DMS : Nasazení OCR BarCode software. Postupně se přebrala správa i jiných outsourcovaných věcí jako telefonů, telefonní ústředny (viz článek o shánění MOH: MOH do telefonní ústředny) a jak se nasazovala PBX: Firemní telefonní ústředna Aastra MX-ONE. Kvůli konsolidaci s matkou se nasazuje i SAP a přibývají i zkušenosti se SAPem.
Devíci konečně kývnuli na nasazení svn, protože poslední selfdelete změn už byla poslední kapka :D. Po milionů remcání, že svn není jako klávesa F5, si na to zvykli. Tenkrát už byl rozjetý git, ale lepší svn, než nic. Taktéž přibyla nutnos terminal serveru, takže se naladil Citrix se vším všudy a člověk zase nasál nějaké informace a rozšířil si obzor. Dále jsem naladil X2Go (začal jsem na FreeNX) pro pár lidí, co potřebují jen pár věcí, ke kterým není nutný Windows. V některých pobočkách není možná MPLS síť, pokračujeme v nasazování vlastních ipsec tunelů. Přechází se ze storage per server na centrální replikovaný storage v HA. Kupuje se vmware, veeam a další věci. Větší tlak na zálohy mě donucuje nasadit ZFS storage (ZFS : Stavba a zkušenosti se ZFS storage). To se ukázalo jako dobrá cesta a později jsem sestavil plnohodnotné storage řešení s více komponentami v HA: ZFS : Stavba a zkušenosti se ZFS storage (2). Přechází se kompletně na SIP, takže externí firmu na telefony už skoro nepotřebujeme.
Nasazujeme vlastní RFID řešení: Plně otevřené RFID řešení pomocí Olimex A20
Postupně všechny tiskárny jdou na síť, některé přes redukce: Pozor na převodníky TL-PS110P, začíná se postupně více a více věcí izolovat od sebe atd. Nasazují se Cisco stacky, budují se nové HA serverovny atd. Nasazuji vlastní VPN řešení na Strongswanu pro road warriory, začalo se 100 klienty, teď jich je tak 700. Po delší době jsem sepsal první článek: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod. Konečně došlo i k zapojení IT do ticketovacího systému. Relativně sám jsem používal Redmine několik let a konečně k tomu byli dotlačeni i ostatní. Podobně jako u svn spousta remcání, jak je to práce navíc. Nakonec všichni pochopili, že je to i pro ně samotné velký přínos. Helpdesková část je v Redmine nedostatečná, takže RedmineUP projekt s moduly Helpdesk+CMS problém řeší a plná spokojenost. Je už potřeba nějak rozumně řešit dokumentaci. Do té doby jsem jí dělal jen já do svn v podobě souborů, schémat apod. Nasazuje se Mediawiki. Virtualizujeme i OracleDB, migrujeme vše na SSD (Kdo nemá SSD disk je masochista a srab). Přichází zkušenosti s Oracle VM, což se snažím doteď vytěsnit z hlavy.
Tlak na bezpečnost je větší a větší, začínají se dělat pravidelné penetrační testy pomocí firem, které se tím zabývají. Později se interval PT zkracuje. Začínám se víc a víc zabývat bezpečností (ochrana web služeb, různé techniky, vlastní testování atd.) Začínám si sbírat různé bezpečnostní informace a nastavovat notifikace pomocí víc a víc RSS zdrojů (v dnešní době procházím denně cca 100 bezpečnostních informací, které by se mě mohly týkat, což je otázkou cca 5-10min a někdy je to zajímavé počtení). Co nejde přes RSS, nechávám si posílat na email (některé nedostupné části od Citrixu, HPE, Aruby apod.) Snažím se zaplátat jakokouli hloupost (CORS, Secure Cookies, nosniff, HSTS, TLS verze, šifry atd.). Dále usuzujeme, že ač jsme se tomu chtěli vyhnout, tak zkušenosti už máme na to, abychom si část penetračních testů dělali sami. Nasazujeme tedy OpenVAS a děláme si častější penetrační testy pro vlastní potřebu na kontrolu. Dále nasazujeme IDS řešení a začínám pronikat i do inspekce sítě a provozu jako takového. Už si tedy nehraji jen s tcpdumpem a wiresharkem, ale posunuji se opět trochu dál. Nasazuje se on-prem Bitwarden: Bitwarden: Nejlepší správce hesel?. Dochází k nasazení ElasticSearch a sbírání a analýze a alertingu logů ze všeho možného. Rozjíždí se síť honeypotů atd.
S přibývajícími novými projekty, kde probíhá vlastní vývoj, nasazuji Gitlab CE, gitlab runnery na buildování projektů, dále nasazuji Kubernetes nad RKE, řeší se CI/CD, nasazuji objektový S3 storage Minio, nasazuji RabbitMQ, SolarQube, Redis a další a další věci. Poměr Linuxových serverů je větší a větší, jejich počet je větší a větší. Nasazuje se tedy Ansible a začínáme si psát playbooky. Nasazuje se Prometheus na sběr metrik, Grafana pro pohledy atd. Začíná se na pár dceřinkách testovat migrace na Office 365 atd. Částečně spravujeme i MaR (správa automatizace budov). Všechno jde do HA, takže tři instance RabbitMQ, Redisu apod. Řeší se horizontální škálování některých věcí v Kubernetu apod.
Zajímavé kolik služeb, které přímo nesouvisí s businessem, musí běžet, aby se dala zajistit bezpečnost, auditovatelnost a spoustu věcí okolo. Když uvedu pár příkladů, co mě tak napadají, tak:
A teď k tomu je potřeba připočítat, že spousta toho musí běžet v HA a navíc to, že toto není všechno, ale jen základní seznam. Dále je třeba počítat s tím, že jen pro vývoj jsou potřeba minimálně 4 prostředí (Dev, Test, UAT, Prod) a je tlak mít páte (PreProd). To trochu navyšuje počet VM a tlačí více automatizaci.
Občas se mě někdo ptá, co ty IŤáci vlastně pořád dělají? Přeci něco nainstalují a je hotovo :). Vesměs se stále něco řeší, nasazují nové věci, staré se mění za lepší (vystřídali jsme např. asi 4 druhy CCTV řešení, dms řešení se nasazuje zase jiné, virtualizaci teď nastavuji už zase jinou, nejdříve VMware Server, pak ESXi, pak Oracle VM, pak čisté kvm, teď Oracle oVirt, na něčem máme Hyper-V a mimo firmu jedu Proxmox).
Vím, že pro někoho je tento výčet kapka v moři a pro někoho je to zase příliš. Vše se podle mě odvíjí podle velikosti firmy a tlaku na různé věci a dostupnost.
Zdar Max
PS: A jak jste na tom vy?
Tiskni
Sdílej:
Pokud jde o protokoly, tak se postupně všechno přesouvá na web, kde ten vývoj jde hodně kupředu, je hodně dynamický, je tam hodně změn a dá se tomu rychle přizpůsobit. Viz http/1.1 -> http/2 -> http/3No a to je prave pruser, protoze se prostredi meni pod rukama, prohlizece nahodne ukoncuji podporu pro veci (RSS, FTP,...) a co driv stacilo nastavit jednou a zapomenout, se dneska musi porat hlidat. Zbytecna prace navic. Misto aby se dlouhodobe existujici, jednoduche a standardizovane formaty+protokoly jen obalily nejakym standardnim zabezpecenim, treba TLS/SSH/PGP, tak kazdy korporat vymysli vlastni *nekompatibilni* kolo, s vlastnima chybama a backdoorama.
Máme tu pár web prohlížečů, které jedou rollup vývoj, změny rychle proudí k uživatelům, takže nasazovat novinky a dělat změny je podle mě jednodušší.Kdyz uzivatele chteji rolling distro, at si ho uziji. Ale na infrastrukturu musi byt spolehnuti a neustale (nevypnutelne automaticke) aktualizace vseho jsou naprosto nepredvidatelne. Staci pul roku neaktualizovat pip, npm nebou jinou sracku a uz je deadlock aktualizaci a nic nefunguje. Rust, nejpropagovanejsi jazyk soucasnosti, ani nema stabilni ABI a s kazdou verzi kompilatoru se musi prekompilovat i vsechny knihovny.
Rust, nejpropagovanejsi jazyk soucasnosti, ani nema stabilni ABI a s kazdou verzi kompilatoru se musi prekompilovat i vsechny knihovny.Jenom pro pořádek, programovací jazyk (typicky) nedefinuje ABI, C a C++ ho taky nedefinují, stabilní ABI může poskytovat pouze kompilátor na nějaké architektuře na nějakém OS. Rust ABI není až tak moc relevantní, protože stejně by-default linkuješ dependence staticky... A Rust na to alespoň narozdíl od C/C++ poskytuje slušný tooling. Pokud by se měly Rust dependence linkovat dynamicky, muselo by se kromě ABI vyřešit ještě jak dostat dependence do X×Y linuxových distribucí a Z dalších OS a udržovat je aktuální, jak mít možnost používat třeba různé verze/generace Rustu atd... tj. to je šílené množství práce a koordinace. A výsledek? Na Archu je tohle uděláno s Haskellem. Když si chci nainstalovat pandoc, nabídne mi to instalaci 150 balíčků o celkové velikosti 500MB... No takže radši používám statický nalinkovaný pandoc z AURu - jeden balíček o velikosti 80MB. Horší problém než Rust ABI je glibc ABI, které není dlouhodobě stabilní, takže programy se musejí překompilovávat pro novější/starší linux distra a na novém distru. Nakompilovat na novém distru software pro starčí distro je takovej vopruz (pokud tedy vůbec jde protlačit příslušné flagy přes daný build systém), že je jednodušší si starší distro prostě navirtualizovat (třeba v dockeru) a přeložit to tam. Linux mam rád, ale tohle je fakt sračkoidní řešení - nemít stabilní libc a další základní systémové knihovny, ale zároveň tlačit na dynamické linkování. Linuxoví tradicionalisté se pak strašně moc diví, když lidé používají statické linkování (musl libc, Rust, Go, ...), různé Snapy, AppImage, webové technologie atd...
Pokud by se měly Rust dependence linkovat dynamicky, muselo by se kromě ABI vyřešit ještě jak dostat dependence do X×Y linuxových distribucí a Z dalších OS a udržovat je aktuální, jak mít možnost používat třeba různé verze/generace Rustu atd... tj. to je šílené množství práce a koordinace.Jo a ještě jsem zapomněl, že Rust hodně využívá generik a některé silně generické dependence ani dynamicky linkovat není realistické (nebo minimálně ne bez změn ve zdrojáku, sémantice, zhoršení výkonu)... z hodně používaných třeba tokio, futures, serde, ...
Pokud by se měly Rust dependence linkovat dynamicky, muselo by se kromě ABI vyřešit ještě jak dostat dependence do X×Y linuxových distribucí a Z dalších OS a udržovat je aktuální, jak mít možnost používat třeba různé verze/generace Rustu atd... tj. to je šílené množství práce a koordinace.No prave. Pamatujes jaky byl pain pri prechodu z python2 na python3? Ruzna distra ruzne rychle zdefaultnily p3, ruzni autori knihoven migrovali ruzne rychle a celkove se vsechno bilo navzajem. Rust ma tenhle problem s kazdou verzi.
Na Archu je tohle uděláno s Haskellem. Když si chci nainstalovat pandoc, nabídne mi to instalaci 150 balíčků o celkové velikosti 500MB... No takže radši používám statický nalinkovaný pandoc z AURu - jeden balíček o velikosti 80MB.Nepouzivam Arch, pandoc ani haskell - ale verim ti, ze poprve se stahuje zavislosti hodne. Jenze kazdy dalsi nastroj ktery s tema knihovnama pracuje uz je jednou dynamicky ma, a nemusi je stahovat znova - takze 1*500 vs x*80. Ale tenhle flamewar dynamicke/staticke linkovani urcite znas :)
Horší problém než Rust ABI je glibc ABI, které není dlouhodobě stabilní, takže programy se musejí překompilovávat pro novější/starší linux distra a na novém distru.Souhlasim, ale ty *nemusis* linkovat proti glibc, muzes si vybrat jinou implementaci. Nativniho softwaru, ktery bez rekompilace bezi na vsem od Centosu 5 po Debian 12 jsou mraky (ne, neni to obalene wine nebo java).
Linuxoví tradicionalisté se pak strašně moc diví, když lidé používají statické linkování (musl libc, Rust, Go, ...), různé Snapy, AppImage, webové technologie atd...To IMHO spis souvisi s multiplatformnosti jako takovou - mit zdrojaky kompatibilni s prekladem na linuxu, windows i macu (a testovani!) je obrovsska prace, od ktere te Snap/Electron odstini.
Ale tenhle flamewar dynamicke/staticke linkovani urcite znas :)Znám no :) Jen k tomu dodám, abych nevypadal tak radikálně
že u jakž takž standardizované technologie,problem vidim v tom, ze u IT vzdelani se zappomnelo na to, ze standardizace je ta alfa&omega cele cinnosti. Na strojni prumyslovce se uz v prvni hodine rekne zakum, ze uplne to nejdulezitejsi v celem dalsi praxu bude ta standardizace. Existuji statni instituce, ktere se s normalizaci zabyvaji. V kazdem strojirenskem zavode je normalizacni oddeleni.
takovou base aplikaci jako e-mail,v zavedench prumyslovych odvetvich by silenost jako 'email' byla uz davno nahrazena necim smysluplnym Ale jeste neni nic ztraceno. Stavebnictvi potrebovalo 1000 let, strojirenstvi 400 let nez se z umeni stal prumysl a informatika bude jeste nejaky ten patek holt potrebovat, nez odroste detskym strevickum.