Pro vývoj můžete použít RHEL Developer Subscription - https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscription-now-available/
Na server se možná bude týkat oznámené rozšíření nabídky RHELu zdarma.
bude to zajímavé, Red Hat má cenovou politiku dost zběsilou, centos používáme převážně na dev/uat prostředí, pro virtualizaci, kde to Red Hat nemá dobře vyřešené a subscription je příliš drahé a neohebné. Pro Red Hat to byla prostě konkurence.
V produkci ale už druhým rokem na některých projektech testujeme Oracle linux, jeví se ve spoustě ohledech jako pěkná náhrada.
Pre server nevidim absolutne ziadny dovod nepouzivat Debian. Jedine kedy sa oplati RedHat je specificke nejake nove enterprise zelezo rozumej nejaka specialne pole s optickym pripojenim od nejakej 'obscurnej' firmy IBM. VTEDY ano, treba RedHat. Inac Debian, nikdy ziadny problem.
A na klientovi pouzivam Debian SID pripadne testing s rolujucimi balickami uplne bez problemov uz asi 10 rokov.
Používám na klentovi testing/unstable kombinaci už dlouho, ale rozhodně si nemyslím, že je to úplně bez problému. Pro lidi co tomu rozumí to vhodné je, ale drobné problémy nastávají celkem pravidelně (což je logické z principu rolling updates distribucí). Např. při přechodu na novou verzi gnome nebo prakticky jakéhokoliv důležitějšího runtimu (gcc, python atd.). Řešení většinou zabere jen pár minut, ale zdaleka to není bezúdržbové.
Kedysi mal APT taky neprijemny bug ktory nevedel spravne vyhodnotit zavislosti automatickych balickov ktore prechadzali cez rucne instalovane balicky ... takova blbost ... a od vtedy ako to zafixovali co je asi 3 roky sa clovek musi velmi snazit aby nainstaloval balicek s nefunkcnymi dependencies. Pouzivam stary dobry 'aptitude' a momentalne (tuk, tuk) 2-3 absolutne bezudrzbova zalezitost. Napriklad teraz mi v balikoch stoji uz asi 3 mesiace novy LibreOffice na chybajucich dependencies ale netlacim, pockam, vzdy pri update upozorni, dam ! - Accept a hotovo.
Spíš jsem myslel problémy jako, že ti přestanou fungovat starší konfigurace gnome co máš v home nebo se ti nainstaluje python 3.9 a přestane ti fungovat program co vyvýjíš, protože všechny balíky a binární závislosti máš nainstalované pro verzi 3.8. Tohle jsou věci, které se na bezúdržbové distribuci nesmí stát (v debianu stable se ti to nikdy nestane). apt nebo aptitude ti nepomůže pokud nechceš měnit major verze programů a knihoven. Pokud ti to nevadí tím líp, ale není to rozhodně pro každého.
Ono sa to stane vzdy pri prechode na novu stable verziu (tento rok konci python2 a bol by si prekvapeny, kolko veci prestane fungovat). Debian je super, je to snad jedina distribucia, ktora uz roky zvlada prechod na novsiu verziu v podstate bez problemov - uz som siel o 4 verzie hore naraz (po 4 rebootoch) a fungovalo to.
Narazal som na to, ze su distribucie, o ktore sa musis starat non-stop a tie, ked to staci raz za cas. Kompilovatelne - gentoo, arch a podobne su ako domace zvieratka, potrebuju pravidelnu opateru :-) Debian je tank, po rokoch ho premazes, nastartujes, opravis a ides.
A konfiguraky? Stare konfiguraky dokazu narobit paseku, zvlast, ked o nich ani netusis a aplikacie ich stale pouzivaju - mas 3-4, kade tade a ktory z nich je ten spravny?
debian zejména (ale obecně hlavně stable) má obrovský problém s fixováním bezpečnostním děr v balíčkách, na hromadu z nich nemá mainteinery a jsou ponechány bez dozoru. Např. debian buster, php 7.3 a CVE-2020-7070 z počátku letošního roku pořád není opraveno v stable a přitom lze zneužít z venku přes podvržené cookies.
To se u CentOS nestává v takové míře (teda pokud někdo nezačne používat epel). Mně politika CentOS s bezpečnostními aktualizacemi vždy více vyhovovala i za cenu zpoždění.
> Např. debian buster, php 7.3 a CVE-2020-7070 z počátku letošního roku pořád není opraveno v stable a přitom lze zneužít z venku přes podvržené cookies.
Jak se koukám, tak se koukám, ale tady to nevidím jako nahlášený bug: https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;dist=unstable;ordering=normal;repeatmerged=0;src=php7.3
A mimochodem CVE-2020-7070 bylo v upstreamu opravené v říjnu: https://www.php.net/ChangeLog-7.php#7.3.23, tak to nepřehánějte...
máš pravdu, CVE-2020-7070 jsem řešil někdy na konci jara, bylo na něj asi embargo, nedávno jsem na něj znovu narazil, že v debianu ještě není plně vyřešený.
Podle trackeru se čeká na další verze v upstreamu https://security-tracker.debian.org/tracker/CVE-2020-7070
Zrovna volit jako ukázku php nebyl dobrý nápad, to je zrovna balíček, který je v debianu aktivně spravovaný, díky že jsi to upřesnil.
já vím :), odvádíš dobrou práci a nemyslel jsem to nijak zle. Díky za pošťouchnutí aktualizace.
To ale nebyla hlavní myšlenka, v debianu jsou prostě některé balíčky příliš neudržované, člověk si to sám pohlídá, ale pokud se takový systém dá jako základ do firmy, kde vývojáři si vyžadují nějaké balíčky z repa, už je těžké to udržet zdravé.
Jo může bejt. Lepší něco než kdyby někdo SELinux vzdal pro komplexnost.
Na toto téma: Kdyby snad někdo toužil po tom se na SELinux psaní politik podívat, tak můj talk by mohl pomoct. Pojak jsem to čistě z praktického úhlu:
https://www.youtube.com/watch?v=g2aBZrQ2eEk (EN)
https://www.youtube.com/watch?v=VDXr86c8V9E (CS)