Petre, me konkretne tyhle snahy prijdou asi tak stejne posetile, jako snahy peclive hasit popelnik, kdyz hori cely barak.
Je sice hezke, ze se nekdo (?) snazi zbavit prebytecnych adresaru, ale uprime organizace Linuxoveho filesystemu je s odpustenim tak velky mrdnik a cochcarna, ze otazka duplictnich adresaru aka /bin, /usr/bin a /usr/local/bin (atd...), nebo vubec oduvodnitelnost existence /usr ci /opt, je opravdu ten nejmensi problem, ktery podle me Linuxove systemy na tomto poli maji. Staci se podivat na ten bordel co delaji programy v ~. Nebo jak jsou konfigurace a data organizovany v adresarich /etc /usr/share. Kdyz chces pracovat s konkretnim programem (ci nejkym objektem - kdyz proste predne vis co hledas) tak treba neco najdes. Ale kdyz mas jen predstavu co ches najit tak to muze byt pekne zapeklity orisek ci rovnou za nesplnitelny ukol. A jak ti s tim pomuze organizace dat v techto adresarich? Dost casto pramalo. Me osobne treba toto prijde jako mnohem vetsi problem nez existence tri, ctyr adresaru pro spustitelne soubory.
Poslednich cca 10 let si vsimam, ze Linuxova komunita (pokud vubec kdy nejaka byla) se rozpadla na decentralizovany system suverenich komunit tocicich se kolem nejakych projektu a pramalo se zajimaci o problemy a potreby tech ostatnich komunit. V Linuxovych sytemech je obsazeno a zarizeno vse podle toho, co do nich da tvurce konkretniho distra, jak to vytvori a nastavi autori jednotlivych programu a ruznych subsystemu a pak jeste podle toho, jak kdo dostatecne hlasite a vytvale rve. Tvurcu nezavyslich na komunitach, kteri jsou schopni videt Linuxove systemi s nadhledem je malo a jsou v dost obtizne situaci. Konec koncu, schyza kolem X a Waylandu je toho jen krasnym dokladem. Takze by me zajimalo, kdo pripadne zmeny vubec prosadi do praxe. Tri mainstreamova distra a zbytek Linuxoveho sveta si to bude delat dal po svym, ci(li) po staru. Vysledek? Dalsi nekompatibilta a rozdily, jako by tech soucasnych nebylo malo.
Když potřebuji u konkrétního softu, kde co najdu, na debianu/ubuntu obvykle zjistím název balíku přes dpkg -S a pak si vyjedu seznam jeho souborů přes dpkg -L. Ostatní balíčkovače mají podobnou funkci. Konkrétně problém různých umístění mě na linuxu nepálí. Ale jo, nejsem vývojář softwaru pro libovolné linuxy, takže se nemusím rozhodovat, co kam dát.
Timhle zpusobem typicky nezjistis, kde je konfigurace. A jak predrecnik velmi spravne podoktnul, je to nehorazny megabordel. O to vetsi, ze pokazde prijde nekdo "chytrejsi" a vymysli, ze by se to melo nekam presunout, coz pak vede jen k tomu, ze se ten bordel znasobi.
Neni pak zadnou vyjimkou, ze ty zmenis nekde konfiguraci protoze tam si ji menil vzdy ... a pak zjistis, ze to nema zadny efekt, protoze v mezidobi nekdo vymyslel, ze to nebude v /etc, ale treba ve /var.
Automaticky to nezjistím, ale z výpisu souborů debianího balíku je obvykle na první pohled vidět, kde jsou konfigy (např. /usr/share globální + /etc/ lokální - minimálně ukázky). Když se to přesune, opět dpkg -L na aktuálním balíku ukáže /var místo /etc. Neříkám, že je v tom pořádek či systém, ale nepřijde mi to jako zásadní problém.
Daleko nepříjemnější je změna konfigurace konkrétního balíku mezi verzemi, kdy se musí služba po službě po větším dist-upgradu ručně překonfigurovávat. Ale těžko tomu zabránit, pokud se nemá vývoj úplně zastavit.
8. 6. 2023, 09:49 editováno autorem komentáře
To ale máš 10 let ty stejné Windows bez aktualizací, ne? Nastavení ve Woknech je peklo. Nelogické a navíc ho Microsoft neustále překopává. Takže málokdy se mi stane, že potřebuju něco méně obvyklého nastavit a je to na stejném místě jako minule. (Nejsem admin, jen uživatel.)
Zrovna to IP jsem teď vyzkoušel... no, proklikal jsem se k němu, ale ten dialog jsem v životě neviděl.
8. 6. 2023, 12:39 editováno autorem komentáře
Nejlepší věc, kterou Microsoft v nastavení udělal, je fulltextový vyhledávač. Není potřeba zjišťovat, kde které nastavení je – stačí si pamatovat, pod jakým klíčovým slovem ho hledat. (Někdy mám pocit, že se to nastavení nestěhuje jen s novými verzemi Windows, ale že to závisí i na dni v týdnu nebo fázi měsíce.)
/etc/network/interfaces
Zhodou okolnosti, konfiguracia siete je jednou z veci, kde je debian, povedzme to diplomaticky, sa zastavil cas a dodrziava tradicie z 90-tych rokov. RHEL stihol prejst krokmi: a) zmena na NetworkManager (s pluginom, ktory ukladal konfiguraciu do tradicnych redhatovskych konfigurakov), b) deprecation tohto pluginu a c) odstranenie tohto pluginu, s konfiguraciou len cez standardny NetworkManager.
ten konktretny stroj na ktorym som si trhal vlasy to mal v NetworkManageri a teraz pre istotu som sa pre istotu uistil, ze o sebe pri prihlaseni tvrdi, ze to je Debian :).
Rozhodne to nebolo v interfaces, pretoze tam som to hladal samozrejme ako prve.
Tu konfiguraciu v NetworManageri som napokon nasiel rano cez grep.
Co uznavam, ze na Windowsoch nie je pouzitelna strategia :).
V pripade NM sa treba naucit pouzivat nmcli, ved je tu len nejakych 19 rokov... ;). NM totiz moze mat pluginy na ukladanie konfiguracie, takze aj ked system pouziva NM, ulozene to teoreticky moze byt vselikde.
Horsie je, ked to niekto zoberie ako Canonical a natlaci tam dalsiu zbytocnu vrstvu, ako netplan.
Vsak chtit konzistenci po linuxu :-))) Nez nekdo vymysli "konzistentnejsi" nove reseni a rozmrcasi stavajici system s cilem lepsi konzistence
NM dobry sluha na desktopu( po tom co pan simerda vymetl augiasovy chlevy), zly na serverech.
Uz jsem par NM only server konfiguraci taky videl u startupu.
Delat pak nejake zmeny config managementem nad jiz existujici konfiguraci NM je za trest.
Nikdo z adminu poradne netusi jak nm funguje uvnitr a v jake fazi si pod sebou uriznou vetev - startupy vetsinou na out of band management kaslou.
Vsetko prebieha nejakym vyvojom a zrovna NM bol vyraznym krokom vpred. Ano, konzervativnym distribuciam dokaze trvat dekadu, kym nieco uzitocne adoptuju a konzervativnym adminom potom dalsiu dekadu, kym si to vsimnu, ale prave to je jeden z faktorov, co sposobuje tu roztriestenost.
A ktory to config management ma problem s NM?
Saltstack.
Ale zatim je to jedno vsechny RH masiny maji uz z provizioningu NM_MANAGED=no nebo tak nejak. Az to prestane fungovat - na coz se prijde pri akceptacnich testech - tedy minimalne 1-2 rok pred nasazenim tak bude dost casu otriskat nefungujici veci co potrebujeme redhatu o hlavu. Resili jsme nefunkcni bonding s ip aliasingem a DCB.
Na tom vsem je nejdebilnejsi ze kazdou sitovou konfiguraci je treba rozebrat, sepsat risky, udelat upgrade testy a byt extra opatrny. Pokud by NM fungoval, tak prechod bude trvat tak 5 let optimisticky. A to se tomu bude venovat clovek full time vcetne callu s inzenyrem u RH aby si spravili svoje lejna.
Jeste jsem ani netestoval scenare typu mam 4 portovou kartu a jsou tam tyhle sfp. Mam 4 x 4 portove karty a jednu z nich prekonfiguruji a zmeni se logicke interface - jak na ne navesit predchazejici konfiguraci. A 2x4portova karta je uplne bezny default u vetsich serveru.