Portál AbcLinuxu, 3. května 2024 01:17
jj sme teraz prpesne v tom procese ze vyberame support company..a nam ponukol SUSE ze sa bude starat o Redhat...problem je ze je tam nejaky legal problem pac oni to nemozu podla toho co sme vyrozumeli....
Člen L3 týmu by tu nuanci ve významu slova podporovat chápat měl, ale typický čtenář ABCLinuxu?
A tohle je možná tak trochu jádro pudla. Blogpostu jako takovému jsem se s chutí zasmál. Ale dávat ho sem, kde je téměř jisté, že většina čtenářů ty narážky nepochopí, to asi nebylo úplně šťastné. Kolik čtenářů si skutečně zkusilo najít, co je Expanded Support nebo VMDP, na koho a co se vztahují, a zamyslet se, proč firma takové služby poskytuje? Rád bych se pletl, ale obávám se, že naprostá menšina. Jenže pak to, co bylo myšleno jako nevinný vtípek v podobném duchu, jako že po fúzi s MFI budeme muset do SLE přidávat podporu Cobolu, vyzní trochu jinak.
Mimochodem, ono to s tou (ne)podporou openSUSE taky není tak jednoznačné. Na jedné straně je asi každému soudně uvažujícímu jasné, že komerční podpora kompletního openSUSE by byl ekonomický nesmysl srovnatelný s jídelními lístky o stovce položek v některých epizodách Ano, šéfe. Ale jednou z motivací pro Leap byla právě určitá symbióza, kdy přinejmenším části bugů na core balíčky může být dávána větší váha, protože jsou to vlastně zároveň bugy na SLE. Bohužel to zatím AFAIK nefunguje v takové míře, jak by mohlo, a v případě jádra ve 42.1 skoro vůbec (což nakonec trochu supluje Evergreen 13.1), ale Řím taky nepostavili za den.
24.3.2016 19:52
rADOn | skóre: 44
| blog: bloK
| Praha
Bohužel to zatím AFAIK nefunguje v takové míře, jak by mohlo, a v případě jádra ve 42.1 skoro vůbec (což nakonec trochu supluje Evergreen 13.1), ale Řím taky nepostavili za den.Existuje vubec nekdo, kdo by si myslel, ze Leap 42.1 neni prusvih?
Richard Brown, přinejmenším. A pokud ne, předstírá to opravdu přesvědčivě. :-)
Na druhou stranu, jakkoli ze 42.1 nejsem moc nadšený, jsem přesvědčen, že pokud by se místo toho vydala 13.3 vytvořená podobným způsobem jako předcházející verze, nebyl by výsledek o nic lepší a v mnoha ohledech by byl spíš horší.
Momentálně mne spíš zajímá, do jaké míry se podaří ve 42.2 odolat pokušení upgradovat všechno možné na nejnovější verze. A taky s jakým jádrem vyjde 42.3, ale to je ještě daleko.
Na druhou stranu, jakkoli ze 42.1 nejsem moc nadšený, jsem přesvědčen, že pokud by se místo toho vydala 13.3 vytvořená podobným způsobem jako předcházející verze, nebyl by výsledek o nic lepší a v mnoha ohledech by byl spíš horší.Proc myslis? V cem by byl s 13.3 takovy problem?
Momentálně mne spíš zajímá, do jaké míry se podaří ve 42.2 odolat pokušení upgradovat všechno možné na nejnovější verzeNektere veci jako KDE nebo kernel by si zaslouzili update, nejlip okamzite, aby se daly vubec pouzivat...
Proc myslis? V cem by byl s 13.3 takovy problem?
Podle mne je největší problém Leap 42.1 Plasma 5. Jsem si celkem jistý, že ta by v klasicky pojaté 13.3 byla nakonec taky, a to z víceméně stejných důvodů. I jádro by tam nejspíš bylo stejné, v horším případě bychom skončili s verzí 4.2, která není long term. Jediný rozdíl by byl v tom, že novější a hůř odladěné verze by tam byly i u core balíčků, které ve 42.1 jsou ze SLE12 SP1.
Nektere veci jako KDE nebo kernel by si zaslouzili update, nejlip okamzite, aby se daly vubec pouzivat...
Tady mi není úplně jasné, jestli mluvíto o updatech v rámci 42.1 nebo o 42.2. Updaty v rámci 42.1 se samozřejmě dělají, ale je potřeba k tomu přistupovat s rozvahou, protože version upgrade není žádná magická hůlka, která automaticky vyřeší všechny problémy. Zrovna u KDE bych ho ale úplně nevylučoval.
Co se týká 42.2, tak tam se KDE updatovat bude určitě, ale nejsem si jistý, jak moc to pomůže. Jádro by mělo být, jak pevně doufám, 4.4 založené na SLE12-SP2. Věřím, že se podaří odolat tlakům, že tam musíme dát něco novějšího; u 42.3 to nejspíš bude podstatně těžší. Jak to bude s dalšími balíčky, to se uvidí v nejbližších měsících.
Jak to bude s dalšími balíčky, to se uvidí v nejbližších měsících.Některé budou muset být upgradovány už kvůli tomu jádru. Za sebe už například s jistotou vím, že celý kernel dump toolchain (kexec-tools, kdump, makedumpfile, crash, libkdumpfile, kdumpid), tj. všechny balíčky, o které se starám. :-|
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
23.3.2016 15:02
24.3.2016 09:36