Neni lepsi nejdriv se nad dotazem zamyslet, pred tim nez zacnes prudit?
Kdyz pri instalaci zvolim "nesouhlasim se sberem telemetrie" (nebo jak to tam maji nazvano), jak se to Canonical dozvi, kdyz i moje odpoved je telemetrickej udaj? Bez znalosti poctu zamitavejch odpovedi by Canonical nemohl zjistit ten pomer "67% souhlasilo"...
To určitě ne, vztah mezi počtem stažených obrazů a počtem instalací je tak volný, že by to vůbec nedávalo nějaký rozumný výsledek. Nedokážu si představit jiný způsob, jak se k tomu dostat než to, že Ubuntu volá domů, i když člověk s tím odesláním informací o počítači a instalaci nesouhlasí. Může to být jenom prostá informace o nové instalaci.
A pritom by stacilo jenom otevrit nalinkovany odkaz na ubuntu report - https://github.com/ubuntu/ubuntu-report
Data being sent if agreement if denied The data is pretty printed here to be more readable. { "OptOut": true }
@xy
Vidím. Řešíš krávovinu která nenastala. Hele, nalij si trochu vody, párkrát se nadechni, pak se pohodlně posaď a zamysli se, jestli náhodou není tak trochu rozdíl mezi nehylášeným zasíláním odposlechu do cloudu a odesláním jednoho 'no' s tím, že dál nic nesbírají. A ikdyby se tam děla nějaká šílená nepravost, tak jsi stejně nic než 100% spekulaci + 50 do paranoie nepředvedl ...
@yx
Druhou část? Co s ní? Jediný význam tvé otázky, aby mělo smysl se na to ptát, je že toho tím musí teda sbírat více, ale přece stačí aby to slavné "NO" posílali na adresu podle distra, třeba:
https://kdyz-uz.je-to.zadarmo/tak-aspon/Release/?opt=no
nebo něco podobného a nepotřebuješ žádnou přidanou telemetrii, žádné ipčka, žádné čáry máry ...
"Displeje s HiDPI a 4K ještě nejsou mezi uživateli příliš rozšířené"
Nebude to spise tim, ze linux a HiDPI si porad moc nerozumi a bez rucniho ladeni to nejde ? Kdyz se zeptam kolegu v kanclu jake monitory za posledni 2 roky kupovali tak na 90% 4K. Ale doma versinou maji win nebo mac. Ale napocital jsem 3 lidi co zvladli 4K i na linuxu a pry je to pouzitelne.
kde ma ui scaling a kdyby v jinych ohledech ktere ho vyrazuji z uvahy nestslo uplne za hovno tak by se dalo rici ze nejen hidpi (vetdi problem viz dale maji displeje co jsou mezi normalem a hidpi coz je vetdina) zvlada
gnome na xorgu zvlada jen 96 dpi nebo dvojnasobek na waylandu umi i necelociselny scaling
vsechna ostatni relevsntni (tim vylucuji picoviny jako enlightenment apod) si neumi s faktem ze dnesni displeje nemaji 96 dpi nijak poradit u vsech bezne pouzivsnych toolkitu lze jen zvetsit pismo ale graficke elementy ui zustanou tak jak byly navrzeny pro 96 dpi
ve zkratce - pokud ma clovek presne 4k, je na tom relativne lip, pokud ma cokoli jineho, je v pici, protoze ti curaci, co to programuji, stale jeste ignoruji fakt, ze ruzne displeje maji ruzne dpi; naprosta vetsina tech sracek je delana tak, aby vypadala ok na necem jako 24" nebo 27" ve fullhd a vic ty curaky nezajima
Jedná s velkých výhod GUI v Linuxu je že tu jsou v podstatě dvě hlavní skupiny. GNOME a KDE neboli Gtk+ a Qt. A když si někdo zvolí prostředí s Gtk+, zřejmě až na pár výjimek bude používat aplikace v Gtk+. A s Qt to samé. Takže když to máme vše v jednom frameworku, tak se to bude lépe škálovat a ne jako ve Windows kdy je něco v WinForms, WPF nebo MetroUI. A také Win32. Tam je milion najednou používaných frameworků.
To je pravda, ale jediny desktop kde vypada cizi toolkit dobre je Plasma KDE 5. Tam vypada GTK aplikace stejne jako nativni. GNOME ma velky problem s dizajnem Qt aplikaci bohuzel.
Ve Windows to vypada vsetcko stejne.
Navic v GTK prostredi kde se nepouziva zadna KDE aplikace to pri instalaci natahaha cele KDE a vsechno s tim skoro.
Pointa je, ze je o dost lepsi zustat na jednom toolkitu a ten druhy ignorovat
V distribucích, které toto řeší, to problém není: https://eischmann.wordpress.com/2017/02/10/dark-adwaita-and-highcontrast-themes-for-qt/ ;-)
Zdroj: vlastna prax.
Ked zoberiem nejaky mac (napr. Macbook Pro, ktory ma pri 13" rozlisenie 2560x1600, t.j. 227 dpi) a pripojim ho na tento monitor, tak sa k nemu sprava presne ako k internemu displeju: system hodi UI a aplikacie do @2 scalingu. Na to, aby som ho donutil zobrazovat @1, tak musim robit rozlicne prstochmaty v systemovych nastaveniach, aby mi tu moznost vobec dal. Na "low DPI" displejoch to nerobi.
Ako uz Ondra spominal, absolutna hodnota ppi nie je jedinym kriteriom, dalsim je bezna vzdialenost od oci pri pouzivani. Mobil - laptop - externy monitor maju preto rozlicne tresholdy.
Ano, HiDPI to moc není, nicméně pro desktopové prostředí a aplikace to je větší oříšek než něco, co má >=192 DPI. Na to totiž stačí celočíselné škálování, které funguje pěkně na všech systémech (Windows, Mac, Linux). U těch 163 DPI je potřeba neceločíselné škálování a to úplně optimálně nefunguje nikde. Apple to vyřešil tím, že prostě zdvojnásobil rozlišení, takže mu stačí škálovat 2x. Funguje to super do té doby, dokud člověk nepřipojí monitor s jiným DPI. Pak musí řešit stejné problémy jako Windows nebo Linux, kterým nezbývá než být připravený na jakékoliv DPI.
Oni v Apple vyriesili aj necelociselne skalovanie, ale nekomplikovali tym software. Software stale staluje iba integerom, teda @2 na pocitacoch a @2 a @3 na mobilnych zariadeniach. Finta je v tom, ze rozlisenie framebuffera, do ktoreho software kresli, nemusi byt rovnaka ako je rozlisenie displeja, na ktorom sa zobrazuje.
Vyssie spomenuty MBR pri 2560x1600 je @2 ekvivalentom 1280x800 (co je pomerne tragicke...). Umoznuje ale pouzivatelovi nastavit 2880x1800 alebo 3360x2100 s tym, ze s rozdielom sa ma vysporiadat scaler, ktory ma dnes kazdy hdmi a displayport enkoder.
V X11 je ekvivalentom `xrandr --scale`, ktory urobi presne rovnaky vysledok. Ono to funguje velmi dobre, za podmienky, ze framebuffer ma vyssie rozlisenie ako displej - teda presne naopak, nez to robi Xwayland, ktory skaluje z @1 na >@1, a potom vysledok je rozmazany.
To neni celkem pravda s tim celociselnym. Treba na MBP 13" s Retina (2560x1600) je sice default scaling 2x ale mas uz v zakladnich nastavenich moznost:
1024x640 = 2.5x
1280x800 = 2x (default)
1440x900 = 1.7777x
1680x1050 = 1.5x
A kdy pouzijes utilitky tretich stran (napr. EasyRes) tak mas k dispozici desitky dalsich necelociselnych zoomu, vcetne 1x. Minule jsem pripojil ten macbook k 4k projektoru, automaticky navolil ty 4k na monitoru ale z nejakeho duvodu mi na notasu prdlo 1x :-) Nos 5cm od monitoru kym jsem se strefil a nastavil to spravne... O cele to skalovani se stara macOS pres Metal takze uzivatel ani vyvojar nemusi nic resit.
Ale to pro mě není žádná novinka. Upscalingem a downscalingem framebufferů si můžu vyčarovat jakou velikost budu chtít i na Linuxu (Mutteru jdou vnutit dokonce i hodnoty pod 1x). Drtivá většina moderních grafických frameworků podporuje celočíselné škálování a neceločíselného se dosahuje právě tím zmenšováním a zvětšováním bitmap framebufferů na úrovni display serveru, které prostě nikdy nebude dávat stejně kvalitní výsledky jako škálování pomocí vektorů ve frameworku.
A taky není pravda, že jako vývojář se nemusím o nic starat a Metal za mě všechno zařídí. Nezařídí. Funguje to stejně jako u Mutteru, prostě to pracuje s framebuffery oken a pokud aplikace neumí škálovat, tak to za ni (kvalitně) neudělá. Stačí se podívat, jak vypadá Inkscape nebo GIMP, které používají GTK2, na Retina displeji. Má to úplně stejné problémy jako v Linuxu a dokud jejich vývojáři neudělají svoji práci a nepřejdou na GTK3, které škálování podporuje, tak to dobré nebude.
Vyssie som presne vysvetlil, ako to macOS robi... software vie len integer; **zvysok robi scaler**. Kludne si nastav jedno z tych non-integer rozliseni, potom si urob screenshot celej obrazovky, pozri si jeho rozmery a preskumaj pixely, ktore su v nom. Uvidis, ze je to stale iba integer scaling.
Ale XWayland to dělá z jednoho prostého důvodu. Na XWaylandu běží typicky aplikace, které závisí na Xorg, protože používají starší grafický toolkit, který neumí škálovat. Pokud takové aplikaci dám plochu o větším rozlišení na vykreslení obsahu okna, tak se nenaučí z ničeho nic škálovat a vykreslit obsah okna správně na vysokém rozlišení. Výsledkem pak často je rozbité UI, protože prvky, které nastavují velikost podle písma, se zvětší a zbytek zůstane malý. Jde tady tedy o kompromis mezi ostrostí a správnými proporcemi rozhraní aplikace.
Problém byl v tom, že Mutter automaticky předpokládal, že všechny aplikace běžící na Xorg neumí škálovat, což není pravda minimálně pro prohlížeče (Firefox, Chrome...). Těm předhazoval zbytečně malé rozlišení a potom upscaloval jejich framebuffer. Olivier Fourdan ale momentálně do XWaylandu implementuje podporu pro více displejů, kdy jeden se standardním DPI bude pro aplikace, které neumí škálovat, a druhý se skutečným DPI bude pro aplikace, které škálovat umí.
U aplikací, které běží nativně na Waylandu, to funguje stejně jako na macOS. Okna jsou škálovaná na 200 % a Mutter potom jejich framebuffer zmenší na požadovanou finální velikost, třeba 150 %. Ani v tomto případě (stejně jako na jakémkoliv jiném systému včetně macOS) nejsou výsledky úplně dokonalé, ale už dostatečně dobré na to, aby to uživatele netrápilo.
Mal som dojem, ze vo Waylande (tym myslim Mutter) to funguje trocha inak ako v macOS: Wayland to robi per surface pomocou GPU (nastavi kazdy surface ako texturu a potom necha texture sampler, nech to da v spravnej velkosti do skompozitovaneho desktopu?), zatial co macOS to robi per framebuffer pomocou hdmi/dp scalera. Nech vo Waylande nastavim skalovanie ake nastavim, vysledny framebuffer ma vzdy velkost rovnaku ako rozlisenie displeja, zatial co macOS nie. Pristup macOS ma trochu vacsie naroky na VRAM, ale potencionalne menej artefaktov na hranici surfaces, pristup Wayland setri VRAM za cenu vykonu GPU.
Problem Xwaylandu a jeho fixnych 96 dpi bol prave firefox/chrome, potazmo electron aplikacie. Kedze tieto dve su najpouzivanejsie aplikacie na pouzivatelovom desktope, mat ich rozmazane je neakceptovalne. To bol jeden z dovodov, preco aj ja dodnes preferujem X11. Pokial Olivier toto vyriesi, bude to velky krok pre Wayland.
„Většina uživatelů (54 %) preferuje smazání celého úložiště a automatickou instalaci nového systému.“
V tom případě by mne zajímala i statistika počtu disků v systému a korelace mezi touto volbou (smazání celého úložiště) a vícediskovým systémem.
„Druhou nejoblíbenější možností (22 %) je ruční dělení disku. "To znamená, že ruční dělení musíme zachovat a měli bychom prozkoumat, jak ho zjednodušit."“
Za mne, prosím, nezjednodušovat, ale lépe cachovat (jestli lze) - vím, že je to kravina, ale trošku mne rozčiluje, když naklikám parametry jednoho oddílu a po potvrzení se instalátor zasekne a znovu (zřejmě?) skenuje celý systém. (Zvlášť ve srovnání s gparted, který jednou načte, pak člověk nakliká všechny oddíly a nakonec potvrdí všechny operace.) Samozřejmě, pokud je za těmi záseky nějaký důležitý důvod, tak to přežiji, ale jinak si myslím, že by snad neměl být problém vše počítat v paměti a při potvrzení validovat... (Disclaimer: naposledy jsem instaloval 16.04, k 18.04 jsem se ještě nedostal...)
Jóóóó, Vim drtivě porazil Emacs! :-D Ale od koho to sbírali data, že ještě drtivěji vyhrál Gedit? Jako není špatnej, ale oproti Vimu? ;-)
Btw. to je opravdu ohyzdnost tyhle grafy exportované do JPG s nízkou kvalitou. Co za amatéra to dělalo, že neví, že na grafy a obecně grafiku s takovými jednolitými plochami se používá PNG? Nejde to skoro přečíst...
Gedit je myslím v ubuntu výchozí volba, ve Windows by možná taky zvítězil poznámkový blok nad notepadem++ (pspadem a vimem teprv). Že něco používá nejvíc lidí neznamená, že je to nejlepší, ale že to většinou stačí. Pokud je ve Windows výchozím prohlížečem Edge a nepoužívá jej nikdo, je to dost k zamyšlení (i když mám za to, že za úspěchem chromu stojí především to, že je to téměř malware, který se instaluje ze vším a google ho cpe silou a až pak, že není úplně špatný)
Takže závěr je, že na 1GB netřeba brát ohled a začneme na 2GB. Ty se tak stanou nepoužitelný a všichni přidají RAMku na min. 4GB, aby to jelo. Za rok-dva z toho vypadne "2GB nikdo nepoužívá, můžeme začít od 4GB"... a za pár let bude 128GB maximum. Super.
(Ono úplně stačí že NTB s 8GB RAM (z toho 2GB grafika) s Gnome je reference rychlosti pro slimáky... :( )
https://wiki.archlinux.org/index.php/Zswap
Na 3 GB RAM mi to docela pomáhalo :)
Jedna zajímavost k té oficiální verzi 18.04, po úspěšné instalaci na PC a prvním provedeném příkazu "apt-get update && apt-get upgrade" a následném restartu, již tato verze odmítala provést přihlášení jakéhokoliv uživatele. Zkrátka nic, to ani nově založený účet, účet zadávaný při instalaci...atd. Prostě vadný Linux !!! Proč se s tím hned otravovat, takovej Kali Linux vyšel před nedávnem ve verzi 2018.2
a funguje skvěle
asi si neco podelal, me 18.04 na 2x NB po upgrade, na 1x NB po ciste instalaci a nasledne aktualizaci balicku&restartu normalne nabehne a prihlasi ;-)
dalsi vec je ze si udelal jen castecnou aktualizaci (apt-get upgrade) a neudelal si kompletni aktualizaci (apt-get dist-upgrade)... pripadne ja uz roky pouzivam: apt update && apt upgrade && apt full-upgrade
moze doplnit o odinstalace nepotrebnych a smazani cache (apt --purge autoremove && apt clean)
btw: jak zakladas noveho uzivatele kdyz na stavajiciho se nemuzes prihlasit? ve stejnem "miste" muzes zkusit provest znovu aktualizaci a uvidis zda se ti neco nenaborilo... nebo rovnou: apt --fix-broken install
nepredpokladam ze by mluvil o povyseni, po nainstalovani 18.04 ;-) chtel jen aktualizovat ale vynechal full-upgrade (+ mozna upgrade nenechal dobehnout, nebo ignoroval zobrazene chyby, nebo proste jen keca ;-)
z man apt:
update [...] New packages will be installed if required to satisfy dependencies, but existing packages will never be removed. If an upgrade for a package requires the remove of an installed package the upgrade for this package isn't performed
full-upgrade performs the function of upgrade but will remove currently installed packages if this is needed to upgrade the system as a whole.