Portál AbcLinuxu, 6. května 2025 17:57
produkt, ktery ma rozliseni horsi nez lowend mobil
To už je nějaká smysluplná formulace. Ale zrovna 245 ppi není žádná katastrofa.
Ze specifikací mě spíš praštilo do očí aktivní chlazení, pouze touchpad jako polohovací zařízení (nikde tam nevidím ani digitizér v displeji), zjevně lesklý displej (kvůli použití venku), výdrž na baterie prý 6-8 hodin,…
Vis, problem je v tom, ze patloweby sou navrhovany cim dal vic tak, ze ani na 2x vetsi rozliseni se nevejdou.
Nějak jsem si nevšiml.
(Monitor s 2560 body na šířku a okny přes max. polovinu.)
26.2.2019 15:06
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
No, mam pustene dva browsery (kazdy pod jinym uzivatelem)
Mám jeden browser s 2 tabmi, bez databázy a spotrebovaná pamäť je 3GB. Prázdny desktop má 70MB ak by niekoho napadlo, že používam náročné DE.
Kompletni rekompilace celeho systemu v 20 vlaknech si samozrejme vezme, co dam, ale probehne i na 2GB
Pred mesiacom som sa pokúsil skompilovať webkit na stroji s 3GB RAM bez žiadnych ďalších spustených aplikácií. GCC si zobralo v priemere 700MB na proces, v špičkách 2.4GB. Pri -j2 som sa uswapoval k smrti a musel som 20h kompilácie zahodiť.
Ako teda máte nastavený systém aby sa dal používať s tak málo RAM?
24.2.2019 12:04
25.2.2019 17:12
26.2.2019 08:42
distcc), a nebo soukromá kompilační farma, ze které si budeš tahat rovnou binární balíky.
A tím se dostáváme k té binární Gentoo-based distribuci, o které jsem mluvil. Prve jsem zkoušel dohledat nějaké benchmarky mezi generickou binární distribucí a Gentoo a nenašel jsem nic – vše nasvědčovalo tomu, že ty rozdíly budou na většině hardwaru marginální. Teď jsem namátkou našel tohle, které to v podstatě potvrzuje, a jinak bych se vesměs ztotožňoval s touto odpovědí.
A konečně, pokud by ty rozdíly přecejen byly větší než zanedbatelné, tak pořád stačí jen přidávat další platformy. Nebudeš to dělit jen na i686 a x86_64, ale jemněji (v nejhorším až na úroveň těch jednotlivých kompilačních flagů, aby i těch pár sebevrahů s -O3 mohlo používat binární balíčky). Větší problém je s USE flagy, tam to už může nabotnat pořádně. AFAIK ale stejně budou mít nějaký reálný význam málokde (párkrát jsem někde zahlídl kompilaci PHP s tunou voleb, právě kvůli optimalizaci na výkon a bezpečnost).
No, zajímavý krypto-like projekt by bylo něco na verifikaci kompilace. Jde o to, že kdybys chtěl postavit repozitář, kam Gentooisti budou moct uploadovat balíčky (spolu s použitými flagy nebo případně modelem CPU [kvůli --march=native]), tak potřebuješ nějak ověřovat jejich korektnost. Nejjednodušší by bylo udělat hlasování – uploadne se to jednou, když to někdo další lokálně zkompiluje, tak už pošle jen hash. Porovnáváním hashů pak můžeš udělat „hlasování“. Problém je, že pokud každé odeslání hashe bude mít stejnou váhu a navíc bude levné, tak útočníkovi stačí poslat malware a pak si ten hash párkrát potvrdit curlem. Tady se nabízí několik myšlenek.
Tou první je, že každý hlas nebude mít stejnou váhu. V každé instalaci systému budeš mít náhodný klíč, který se vždy odešle spolu s hashem. Repozitář pak bude jednotlivým klíčům stanovovat váhu na základě (opět váženého) souhlasu s ostatními. Hashe zkompilovaných binárek samozřejmě nemůžou být volně k dispozici, čímž se docílí toho, že pro „naboostování“ klíčů útočníka bude potřeba opravdu zkompilovat nějaké množství balíků. Zásadní problém je, že zkompilováním jediného balíku by bylo možné odeslat pak totožný hash pod libovolným množstvím klíčů.
Další myšlenka je, že na server netřeba nahrávat rovnou zlinkované binárky, ale jen objektové soubory. Server pak náhodně ověří několik z nich. To je relativně levné a je to lepší než nemít vůbec žádnou verifikaci, ale pokud pravděpodobnost, že to narazí na nesrovnalost u jednoho souboru, bude 1%, tak v 99 % případů útočníkova binárka projde.
Chtělo by to mít možnost bezpečně vyhodnotit kód na cizím počítači tak, aby po jeho vyhodnocení bylo možné snadno ověřit, jestli opravdu proběhl tak, jak bylo zamýšleno, a nebo s ním bylo manipulováno. Čili bys vzal kompilátor a zdrojáky, udělal z toho jeden program, ten celý nějak zašifroval tak, aby ho bylo možné provést, ale třetí strana se vůbec nemohla dozvědět, co vlastně provádí, a pak bys jednoduše zvalidoval a rozšifroval výstup a měl jistotu, že je korektní.
No, ale to trochu ujíždím v diskuzi někam jinam. :] Tohle je zajímavá úloha, ale našly by se pro ni daleko lepší uplatnění než je kompilování balíčků pro Gentoo. IMHO ten rozdíl fakt bude směšně malý.
26.2.2019 01:04
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Možna cesta. Ignorovať.
25.2.2019 08:30
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Škoda, že namiesto touchpadu nepoužili trackpoint tak ako Sony Vaio P. GPD pocket mal síce trackpoint, ale tak príšerne umiestnený, že človek najskôr musel posunúť ruku preč z klávesnice a prsty otočiť do dosť nepríjemnej polohy.
25.2.2019 11:58
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Jaj nevšimol. Tak mi to dáva už trochu viacej zmysel.
26.2.2019 01:05
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Škoda, že namiesto touchpadu nepoužili trackpoint tak ako Sony Vaio P.Mimochodem Sony Vaio P jsem si před pár lety v rámci průzkumů koupil a musím říct, že je to úplně k ničemu. Podpora linuxu špatná, zastaralý hardware a tak. Ale form factor fajn.
10.7.2019 00:20
jose17 | skóre: 44
| blog: Joseho_blog
| Bratislava
10.7.2019 07:54
jose17 | skóre: 44
| blog: Joseho_blog
| Bratislava
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
26.2.2019 01:51
25.2.2019 10:40