Názory k článku
GNOME Recepty jsou hotové, dobrou chuť!
-
nobody (neregistrovaný)
az na to ze Snap je drivejsi v roce 2014 byla prvni verze, kdy s Lennart Poettering teprve prisel s napadem na Flatpack ;)
a dale tvrdit ze jde o nekompatibilni reseni se zbytkem sveta je take KRAVINA ;)
https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on-multiple-linux-distros/
"Snaps now work natively on Arch, Debian, Fedora[...]. They are currently being validated on CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt and RHEL, and are easy to enable on other Linux distributions."
tak ci tak, kdyz nekdo udela vlastni reseni pro vlastni potreby aby mohl implementovat bez omezeni vlastni napady a vlastni sny, tak je to jeho vec, mysleno napr. Unity a Mir...
podobne kdyz prislo Ubuntu s UpStart initem tak ten plnil vetsinu toho co v te dobe ostatnim initum schazelo a proc (prvotne) vzniklo "jine nestandartni" reseni systemd... na ktere pak bohuzel pod natlakem preslo... -
Pár upřesnění:
1. není to Flatpack, ale Flatpak ;)
2. Lennart nepřišel s nápadem v roce 2014, ale už v roce 2013. Minimálně v půlce roku 2013 už byl ten nápad na stole, protože se to hodně řešilo na GUADECu v Brně. Autor Flatpaku Alex Larsson s multi-distro aplikacemi experimentuje už od roku 2007. Je fakt, že samotné repo vzniklo až v prosinci 2014, což lze považovat za oficiální začátek projektu.
3. jinak k té kompatibilitě, doporučuji: https://kamikazow.wordpress.com/2017/02/09/adoption-of-flatpak-vs-snap/ a to je srovnání jenom toho, kde lze ony aplikace spustit, ne, kde je vytvářet. Samotný snapcraft, pomocí kterého lze snapy vytvářet, AFAIK funguje pouze na Ubuntu (a možná Debianu) a používá k vytváření snapů Ubuntu Core. Je prostě vidět, že ta technologie vznikla pouze pro Ubuntu a v určité fázi došli autoři k tomu, že aby se to prosadilo, je potřeba podporovat i ostatní distribuce, ale vzhledem k tomu, že původní návrh nebral multidistro podporu v potaz, jde to dost krkolomně a je to hodně za jejich veřejnými prohlášeními.Jinak souhlasím, že si každý může programovat, co chce. Nakonec o tom open source je. Poznámku o nasazení systemd pod nátlakem přejdu mlčením. Nehodlám tu otevírat láhev se systemd džinem. O tomto tématu už bylo proflamováno hodně MB komentářů :-)
-
nobody (neregistrovaný)
diky za upresneni :) ad poznamka: samozrejme s trochou nadsazky, ale je fakt ten ze pro Canonical bylo snadnejsi to prijmout, nez aby soucasti ktera na nem zaviseji (a do budoucna vice a vice) vsechny predelavali "jen" aby zustali u UpStartu... jinak aspon maji v defaultu journal do rsyslog a v grub/advanced pro kazde jadro polozky i s "upstart init" :) i tak ale na 90% zarizeni s Xubuntu drzim 14.04 :)
-
luv (neregistrovaný)
Jak jsem ostatne naznacil v mem prvnim komentari - ten problem nejde vyresit.
Napriklad to renderovani fontu:
Mam nasledujici moznosti:
1) Pouziju bundlovanou knihovnu - fonty se budou renderovat jinak nez chce uzivatel
2) Pouziju knihovnu ze systemu - pak musim definovat jakou (minimalni) verzi knihovny musi mit systemy, ktere flatpak podporuje - a to jsme nekde zpatky u LSB - to moc nedopadlo. ... a i tak s tim budou jen problemy
3) Muzu zacit vymyslet silene overlays, podminky kdy se pouzije jaka knihovna ... ale tak moc nefetuje ani lennartTo ze freetype bude renderovat fonty jinak v ruznych verzich (nebo dokonce i ve stejnych verzich, staci jine defines pri kompilaci) je jen zacatek ... konfigurace - jine verze jinak interpretuji ruzne promenne prostredi, ted is k tomu pridej gnome-settings-daemon (ten treba firefox nechape dodneska), fontconfig, ...
A to jsou jen fonty. Dal tu mame treba nastaveni gtk temat - ty jsou nekompatibilni mezi minor verzema gtk - obdobna situace. Jak se resi uzivatelske a systemove ssl certifikaty?
-
luv (neregistrovaný)
V open-source svete mame historicky bezprecedentni kompatibilitu na urovni zdrojaku, na binarni kompatibilitu nehrajeme, kdyz tohle zacne clovek respektovat, tak najednou ty problemy nema - a nevytvari nove. Ocividne chce Lennart z Linuxu udelat Maca - skoda ze si neneasel praci radeji rovnou v Apple.
-
atarist (neregistrovaný)
taky me to napadlo - "aplikace", ktera zobrazuje veskrze staticke informace, ktere by navic bylo zahodno automaticky updatovat, kdyz nekdo nekde prida novy recept. Hmm na to existuje takova technologie udelana presne pro tento use case, jmenuje se tusim WWW. Ale zase proc ne, kdyz to ty lidi bavilo vytvaret...
-
Je úterý, nebe je šedý, na hradě je demokraticky zvolený prezident a je přesně ten správný čas na nákup SSD. Pokud takový nákup není v tvých možnostech, ať už finančních, nebo jiných, existuje několik DE a desítky WM, ze kterých si můžeš vybrat ten, který ti vyhovuje a obsahuje file dialog. který se chová, nebo se dá nastavit, dle tvých představ. Navíc odstranění této fičury bude velmi pravděpodobně otázkou nastavení a pokud náhodou ne, tak se stále můžeš držet doporučeného linuxového postupu - DIY.
-
hu (neregistrovaný)
Bohužel, není to otázka DE, ale GTK3 a udržovat si vlastní fork není řešení. Vážně si nebudu pořizovat terový SSD kvůli domrvenýmu file dialogu.
https://www.reddit.com/r/archlinux/comments/33x4wk/gnomegtk_316_file_chooser_typeahead/
-
Tak je otázka, v čem tě to trápí, alternativou je samozřejmě třeba plasma, ale pokud je to něco, co je na gtk navázáno, tak smolíček.
Jinak teda https://www.reddit.com/r/archlinux/comments/33x4wk/gnomegtk_316_file_chooser_typeahead/ jestli ti to k něčemu bude. -
Sadam (neregistrovaný)
A ? data na SSD rozhodne skladovat nebudu, mam 2TB disky v RAID1 plne temer po vrch, a deep search pri hledani pismenem v gnome 3 me neskutecne vytaci, doskacu do slozky v ktere vim ze se nachazi dany soubor, napisi prvni tri pismena nazvu souboru a misto focusu na dany soubor ta sracka zacne vyhledavat v podslozkach a zobrazovat mi soubory o ktere vazne nemam zajem... a na tohle je clovek schopen cucet klidne 10-15s bez relevantniho vysledku... nakonec je jednodusi proste soubory nevyhledavat ale prochazet danou slozku vizualne, je to rychlejsi a jistejsi (mam jistotu ze je to vazne dany soubor z dane slozky a ne nejaka jina verze z jine slozky)
Nemam problem s kvalitnim vyhledavanim, ale at se spousti po prikazu Ctrl+F a ne kdyz chci jen vyfiltrovat obsah slozky/focus na soubor podle pocatecniho stringu!
Diky tomuhle proste nejsem schopen pouzivat spravce souboru v Gnome 3, a nakonec ani v KDE ktere se take chova jinak a debilne (jako widle) . Jedine misto kde zustal zachovan normalni zpusob vyhledavani je Unity na Ubuntu a pak forky Gnome 2... tohle je take hlavni duvod proc pouzivam Unity... Spravce souboru je proste super
-
nobody (neregistrovaný)
k tomu "jedinemu mistu"... v Xfce 4.12 to jeste funguje postartu, ted sem ale zkusil v Xubuntu 17.04 a uz je tam GTK3 dialoh taky zprasenej... co sem nasel tak to bohuzel nelze nijak prepnout, je to natvrdo a potreba je prekompilovat GTK3, puvodni funkce kdy to filtruje jen to co je prave videt se jmenuje "typeahead" (kdyz by to nekdo chtel hledat)...
v Arch nekdo udrzuje opatchovane GTK3 kde je typeahead aktivni, lze teda snadno nainstalovat tento nahrazujici (otazka jen jak dlouho to bude udrzovat), pripane se podivat na patch co tam meni pro tvorbu balicku na jine distro (i kdyz je to urcite resene i jinde...)
https://aur.archlinux.org/packages/gtk3-typeahead/ -
nobody (neregistrovaný)
divne, zkusil sem to v Xubuntu 17.04 podruhe a nejednou zu to nehleda, ale filtruje podle jmena, kdyz jde o dir tak na nej vleze (a zobrazuje se vpravo dole filtr radkovej dialog), kdyz jde o soubor tak se zobrazuje primo v hlavni filename radku (misto dir path) kam se zobrauje psani...
takze to (GTK3) asi maji(*buntu) v 17.04 take opatchovane, nechapu proc poprve to prohledavalo :)
