GPD MicroPC

Na Indiegogo běží kampaň na podporu miniaturního notebooku GPD MicroPC. Notebook se může pochlubit 6 palcovým displejem s rozlišením 1280 x 720 pixelů, podsvícenou klávesnicí, gigabitovým ethernetem nebo sériovým portem. K dispozici by měl být v srpnu. Vedle Windows 10 bude podporováno také Ubuntu MATE. V rámci kampaně lze notebook koupit za 299 dolarů. Společnost GPD stojí také za miniaturními notebooky GPD Win, GPD WIN 2, GPD Pocket nebo GPD Pocket 2.

24.2.2019 03:00 | Ladislav Hagara | IT novinky

Komentáře

Náš administrátor shledal tento komentář závadným.

vulgární výkřik

Zobrazit komentář

[Odin1918]

Je hezke, ze sis zauradoval kolibaci, ais ti to dela dobre, ale cenzurovany vyrok mel pravdu. Co s tim? Zebrat penize na produkt, ktery ma rozliseni horsi nez lowend mobil?

[ʚĭɞ 🍉]

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,…

[qw11]

Ze vas trapia take veci. S tym procesorom to aj tak bude taky lepsie vybaveny poznamkovy blok. Kvoli rozliseniu a procesoru to nebude ani na web. Jedine ze by sa s tym chodilo na mobilnu verziu webu. :D

[ʚĭɞ 🍉]

Nechápu, proč by mě měl trápit procesor – krom toho, že by mohl být mnohem úspornější nebo svobodnější.

1280 pixelů by mělo stále stačit na zobrazení desktopových verzí aplikací a webů, problém je ve fyzických rozměrech: příliš malé ovládacích prvky (nebo písmenka).

Na čtení a psaní je to OK, což píšu jako majitel starší Nokie N800 nebo OpenPandory. Jenže vyjmenované problémy ukazují, že to není zrovna upgrade, ačkoliv solidní konstrukce do terénu by byla fajn.

[j]

Vis, problem je v tom, ze patloweby sou navrhovany cim dal vic tak, ze ani na 2x vetsi rozliseni se nevejdou. Osobne pak vidim daleko vetsi problem v ... malo ram. Na 4 GB ty widle sotva nastartujou, a ani s tim tuxem to nebude zadna slava.

Dalsi vec je read:576MB/s, write: 465MB/s ... => sata. Pritom by tam mohlo byt nvme, coz tezko rict jestli tam dat vubec pujde.

Pak tu mame rozebiratelnost, ktera bude dle fotek naprosto mizerna - nikde zadnej sroub => vsechno to bude zacvakavaci plast, kterej pri prvnim pokusu o demontaz rozlomis. K tomu zjevne celoplastova konstrukce, vcetne toho pantu, takze jen otazka (velice) kratkyho casu, nez se rozlomi pri beznym pouzivani.

A ve finale, naprosto nepouzitelnej layout klavesnice. Davat na neco takovyho jeste k tomu takhle touch muze leda chorej mozek. Tam patri tak maximalne trackpoint.

[ʚĭɞ 🍉]

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.)

[k3dAR]

prohlizece maji zoom, desktop ma dpi/zoom, 4GB je az moc RAM na UMPC pouziti, Xubuntu na ARM s 512MB RAM pustim Chromium s 10 listama (s uBlockOrigin/PrivacyBadger) a jeste neswapuje... s netbookem a 2GB naprosto v pohode vcetne zaroven bezicich terminalu, VNC, prehravacem MP3, email klientem atd, atd...

ze by u UMPC bohate nestacilo "read:576MB/s, write: 465MB/s" uz je spis uchylka, i polovicni rychlost by nebyla problem pro use case takoveho zarieni...

rozebiratelnost je problematicka i u vetsiny aktualnich 15" NB, cekat ze UMPC rozeberes na par sroubku...

jen s trackpoint se da castecne souhlasit, i na NB pouzivaj jen ten...

[j]

Nezvan, libovolnej aktualni browser si hned pri spusteni schroupe 1/2 GB jak nic. A to zcela prazdnej. Jakmile chvili bezi tak preleze klidne i 2GB jen ten browser. Widle samy o sobe potrebujou 4GB jen na to, aby se milostive aktualizovaly. A i tak to trva klidne par hodin. Pracovat se s tim neda naprosto vubec. A to nemluvim o tom, ze na tomhle si uzivatel bude chtit spustit hromadu dalsich nastroju a disgnostickych tools. Nespusti, protoze na to nema ramku. Viz kolik sezere trebas M$ SQL management studio?

Pokud to ma byt zarizeni pro ITka tak ocekavam ze bude mechanicky nejak vypadat, a ne ze to bude plastova sragora. BFU seriovej port ani eth nepotrebuje.

[Gilhad]

No, mam pustene dva browsery (kazdy pod jinym uzivatelem) a databazovy server. Zabrana pamet (vcetne systemu a par dalsich drobnosti) 908M, swap 0. Kompletni rekompilace celeho systemu v 20 vlaknech si samozrejme vezme, co dam, ale probehne i na 2GB (bezne provozuju na druhem NB, ten vic nema) a samozrejme to nejakou dobu trva, ale bezi pouze pokud ji explicitne spustim a kdykoli ji muzu stopnout. Takze pokud si to chrousta, zatimco spim, tak problem nemam. A i kdyz bezi, tak se pracovat da. Diagnostickych veci si tam (na tech 2GB) pospoustim taky furu, bezne vyzkouseno.

Kolik sezere M$ SQL studio netusim, stejne jako kolik sezerou widle aby milostive nechciply. Pocitace mam na praci a zabavu, kdybych chtel neco, o co se budu muset furt starat, aby to nechciplo, koupim si tamagochi a stejne mi chcipne. Na BFU ten pocitac zjevne nemiri, eth povazuju u NB za samozrejmost a HW serial by se mi kolikrat hodil.

Fakt je, ze kdyz jsme se bavili o tom, co clovek chce mit naraz pospoustene na jednom pocitaci a ja vyjmenoval, co mi tam bezne bezi, tak me vyhazovali z nejmenovaneho diskuzniho fora, ze je rec o normalnich hernich pocitacih za 30-50K, tak at tam nemachruju se superpocitacem za nekolik mega. Ovsem taky je fakt, ze jsem tam machroval s tim, co mi normalne v tu chvili bezelo na 6 let starem netbooku se 2G RAM, plotnovym diskem a Atomem, v puvodni cene 6.5k Kc.

Takze ano, dohodneme se, ze pro BFU tohle zarizeni neni (ani pro nej neni zamysleno) a BFU neni na nem schopny ani poradne rozbehnout system, ale na druhou stranu pro nekoho, kdo pocitacum rozumi a umi je pouzivat to muze zastat spoustu prace a nebyt te ceny (vcetne dopravy)(a toho, ze mi ten druhy notas stale chodi, jen uz ma za ta leta treti baterku), tak bych to klidne jako druhe zarizeni na praci v terenu bral hned, dimenzovane je to na to vic nez dost.

[mirec]

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?

[Gilhad]

Nijak zvlast extra, mam v USE flagy procesoru (takze to podle toho kompiluje), mam vyhazene nektere nesmysly jako xdg a zeroconf a mam naopak povolene veci ktere pouzivam (vsechny ty jpg, png, mp3 a tak - to je nejdelsi seznam zmen proti defaultu)

v eselectu mam zakladni system (tedy zadny desktop, systemd, selinux, gnome, kde ...) a z kernelu jsem vyhazel veci co nemam (vsechny ty apple tablety, sonic X mysi, zvukovky, sitovky a tak), co je s NB primo spojene je primo v kernelu a jen par veci je jako moduly.

Fluxbox, zadne nepomuky, semanticke desktopy a jine zbytecne zrouty vykonu.

Ale celkem zadne brutalni optimalizace...

locate webkit v podstate vyplivnulo z nainstalovanych jen dev-qt/qtwebkit (asi ho ma neco jako zavislost), ale nejnarocnejsi pri kompilaci bylo asi samo gcc a pak openoffice a firefox - alespon to trvalo vzdycky dost dlouho ...

[Bherzet]

Za mých jinošských let nemělo smysl OpenOffice kompilovat a byl k dispozici binární balík. Pro Firefox taktéž (tam by to asi smysl mělo, ale... no, při dnešní rychlosti verzování, aby se to vůbec stíhalo).

Měl jsem Gentoo na netbooku s Atomem, 1 GB RAM a mechanickým diskem. Upgradům jsem se vyhýbal jako čert kříži, to bylo vždycky na desítky hodin (měl jsem na tom Gnome, JVM, pár dalších věcí… ale ono už jen kernel a Xka se kompilovaly dost dlouho). Jinak to šlapalo pěkně, ale na Gentoo jsem stejně zanevřel. Kompilovat pro každý počítač znovu a znovu (nebo vytvářet a synchronizovat binární balíky, které pak ale musí být dost generické na to, aby fungovaly na obou procesorech – pokud je to alespoň stejná architektura… čímž se ale připravíš o všechny ty „zázračné“ optimalizace) je takové trochu moc otravné. Vzpomínám si, jak jsem jednou někde venku potřeboval něco doinstalovat a než se to konečně zkompilovalo, už to bylo dávno passé.

To už by mi dávala smysl spíš nějaká binární Gentoo-based distribuce jako třeba Sabayon. Ono mně přijde, že zase tak moc odlišné procesory mezi uživateli Gentoo nekolují, nebo většina těch optimalizací má marginální význam. Pak se tím kompilováním v podstatě jen zbytečně pálí elektřina…

[Gilhad]

Tak uz jsem psal, ze to kompilovani je na dlouho, ale kdyz to treba pustim v patek vecer a v nedeli se vratim z chaty, tak to je davno hotove a je mi celkem fuk, zda to skoncilo v patek pred pulnoci, nebo v nedeli po ranu...

stejne CELY system kompiluju dost vyjimecne, spis jen sem, tam pridam nejaky dalsi balik, nebo novou verzi, pokud to resi nejaky existujici problem. Podstatne je, ze se to nespusti samo v nevhodnou chvili.

Stejne tak jsem uz parkrat nechal stahnout a zkompilovat cely system v chrootu na jine partisne, s tim, ze to proste bezelo, kdyz jsem spal a pokud to nestihlo, tak jsem to klidne rano stopnul a vecer pustil zas a ono to pokracovalo tam kde to skoncilo (plus minus). Takze ani na slabem stroji neni problem a zase tam ty optimalizace muzou mit docela smysl.

Misto binarnich baliku mezi pocitaci taham svuj balik zavislosti a nastaveni, takze na kazdem se totez zkompiluje jinak, na miru.

A optimalizace ma rozhodne vyznam, pokud jeden pocitac ma Core duo, druhy prastary Atom a treti je Rapsberry Pi - i kdyz vynecham tu malinu, tak i ty dva silnejsi procaky se stejne dost lisi na to, aby optimalizace pro ne znamenaly rozdil.

A ten Atom se vejde do kapsy a Rapsberry zase nema zadny odber a na mensi stacionarni veci bohate staci, takze proc tam umrtvit neco draheho, co se bude nudit jeste vic, nez ta malina?

[Bherzet]

Já na tom konkrétním počítači razil filozofii, že upgrade všech balíků se prostě neprovádí. Ono jsem to i zkusil, ale nestihlo mi to právě doběhnout ani přes ten víkend. Dnes už si ani neumím představit, že bych si počítač na několik dnů v podstatě vyřadil z provozu.

Tam je řešením buď kompilovat v chrootu na jiném oddílu, jak zmiňuješ, distribuovaná kompilace prostřednictvím jiného výkonnějšího počítače (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ý.

[Gilhad]

No ja mam tech pocitacu vic, pro ruzne prilezitosti, ale jen jedny ruce a hlavu, takze vetsinou nepouzivam vsechny naraz (takze ten aktualne zahalejici muze klidne kompilovat).

Jinak updaty taky vetsinou delam, kdyz je k necemu potrebuju (ono se cas od casu vynori novy projekt, co me zaujme, nekdy nova verze programu odstranuje chyby verze stare, nebo pridava zajimavou funkcnost a co bylo bleeding edge pred 6 lety je uz casto ponekud obsolete - tady ta kompilace pomaha, protoze se jednak casto zvladne spokojit i se starsi verzi knihoven, nez ofiko balik (zvlaste kdyz to USE flagama priosekam o veci, ktere nepotrebuju, tak tomu obcas upadne i nejaka zavislost) a kdyz ne, tak se porad jeste da sahnout do kodu a trochu to priohnout (coz jsem napriklad delal u par verzi kernelu, aby bezely s obsolete neupdatovanyma proprietalnima ovladacema grafiky, nez se dostala po mnoha verzich podpora primo do kernelu)) - a na druhou stranu takhle muzu pri zivote udrzovat i obsolete veci, ktere uz jsou ofiko par let mrtve a nepodporovane, ale me na tom NB dosud funguji)

Takze dokud to jde, tak pridavam jen nove projekty, ci vyrazne vylepsene verze, ale nekdy si tyto nesou zavislosti na vyrazne novejsich knihovnach a pak je potreba provest update dukladnejsi.

Krome toho mam na vetsine pocitacu vic verzi systemu, kvuli ruznym pozadavkum toho, co na nich bezi, nebo co naopak chci otestovat.

Tedy update systemu pak udelam na jine partisne a teprve pokud se osvedci, tak ne nej prejdu a stary zrusim, kdyz tam jsou nejake problemy, tak naopak zvazim, zda nezustat u stareho - treba kvuli podpore starych her - nebo zda nejet vic verzi a bootovat podle potreby, dokud se to nejak neusadi.

Pricemz rozdily mezi malinou a Intelem jsou takove, ze proste tam ty druhe binarky nebezi. Co se vytvareni vlastni binarni distribuce (a jejiho deleni a zjemnovani) tyce, tak by mela v podstate tri hlavni vetve, pro kazdy pocitac jednu - to uz je jednodussi to proste zkompilovat pro ten pocitac rovnou.

Dalsi veci jsou prave ty USE flagy, kdy bych musel hledat distribuci, ktera ma nejake baliky nastavene prave tak, jak potrebuju (cili to neni o optimalizaci na rychlost a prostor - ta je jen bonus - ale o optimalizaci na funkcnost, kdy nektere vlastnosti chci a jine naopak vyrazne nechci - a ne vsechny moje volby jsou mainstream). S tim taky souvisi to, co si hlavni programy a system nataha za zavislosti - taky o nektere vylozene nestojim.

Coz mi zase prijde prihodnejsi resit si na svych pocitacich sam na miru, nez zkouset, kde to kdo jak ma a pritom objevovat, v cem mi dana distribuce nesedne a jak se toho zbavit (nebo to tam dodat). Prijde mi vyrazne uspornejsi na muj cas si nastavit par USE flagu a nechat pocitac, at to ve volnem case schrousta (a pripadne to pak prehazet jinak a zas ho nechat o samote srotit), nez venovat nekolik dni ci tydnu vyberu distribuce, ktera by splnovala moje naroky a hledani jak ji doohnout (zvlast kdyz ten vyber zas tak velky neni, kdyz vetsina velkych distribuci ma dost veci, ktere bych z nich tezko odstranoval a vetsina mensich je zase oproti Gentoo vyrazne obskurnejsi). Vysledek je ten, ze s Gentoo ztratim malo vlastniho (vzacneho) casu a dost (lacineho) strojoveho casu, zatimco s jinym vyberem bych setril (laciny) strojovy cas a mrhal (vzacny) cas svuj.

Takze Gentoo a kompilace v chrootu mi nakonec i tak vychazi jako vyrazne pohodlnejsi a primocarejsi cesta k cili, nez ohybani nejake velke binarni distribuce proti srsti, nebo vytvareni kompilacni farmy/vlastni distribuce.

Nicmene tohle vlakno se rozebehlo jako reakce na to, ze GDP MicroPC je nepouzitelny HW a moji protireakci, ze pouzivam i slabsi a nemam problemy, takze upgrade na GPD by byl pouzitelnym zlepsenim (ktere ale neni treba, protoze i ten muj slabsi je na spoustu veci silny dost). Pravda je, ze nemusim resit vecne problemy a nenazranost MS softwaru obecne, neb ho proste nepouzivam. Na druhou stranu rec byla o tom, zda ten GPC vubec muze mit nejaky smysl - zjevne pro docela velkou cilovku smysl ma a stejne tak zjevne nesplnuje neroky zcela jine cilovky, pro kterou urcen nebyl (BFU s Windows a bez znalosti, jak je zkrotit, co s nim chce nahradit neco radove jineho)

[Bherzet]

S tou binární distribucí si asi nerozumíme. Myslel jsem to tak, že než čistě source-based Gentoo by mi dávalo větší smysl takové Gentoo na steroidech, které umí i binární balíčky (jediný rozdíl by byl v tom repozitáři, o kterém jsem se rozepisoval v druhé části toho příspěvku). To zatím bohužel neexistuje. Ten Sabayon s jeho Entropy se tomu trochu blíží, ale to prostě není ono. Neumožní ti to nastavit si kompilační flagy a USE flagy s tím, že buď to stáhne existující binární balíček, pokud existuje, nabídne to nejbližší použitelný, a nebo se to holt zkompiluje.

Ten tehdejší netbook jsem chtěl mít k ruce, tzn. vzít ho a jít (a podobně obráceně: hodit ho na poličku a nechat nabíjet). Muset startovat/ukončovat kompilaci je opruz, ještě to pak hučí…

Vím, že diskuze byla původně o něčem jiném, a neber to tak, že se ti snažím Gentoo rozmluvit. Ono je to spíš tak, že mám Gentoo nostalgicky fakt rád, ale racionálně mi už nedává smysl do něj ten čas a starosti investovat a zkouším si ty svoje úvahy validovat proti někomu, kdo ho používá. (A pak zmínit, co by Gentoo muselo mít, aby mi ten smysl zase dávalo.)

Tak dík za diskuzi a ať ti to dobře kompiluje. :]

[k3dAR]

Na rozdil od tebe nemam potrebu zvanit, browser vyzere 2GB kdyz lezes na bugweb a/nebo prasoweb a/nebo kdyz vidi volnou RAM, pokud pustim Chromium s 512MB RAM, tak tech 10listu sezere ~300MB...

[k3dAR]

to CPU ma v podstate brutalni vykon obzvlast na to k cemu je to urcene... jeste nedavno sem pouzival 5x pomalejsi CPU v Desktopu a v Vivaldi (Chromium based) mel otevrenych desitky listu a relativne v pohode...
nicmene ten HW je smerovan pro systemaky, viz dostupnej GLAN ethernet, Seriovej port... takze nejake SSH/VNC/RDP to bude zvladat do 10% zatizene CPU...

[k3dAR]

srovnani s tim 5x pomalejsim D525 co sem pouzival: https://cpu.userbenchmark.com/Compare/Intel-Atom-D525-vs-Intel-Celeron-N4100/m5666vsm407836

[qw11]

Hmm, zaujimave. Ked som to hodil do notebookcheck - mobile procesor tak to vyzeralo ovela slabsie.

[k3dAR]

a nemusel sem vlastne chodit tak daleko, a zustat u UMPC, mam Viliv N5, ten ma Atom Z520 + 1GB RAM a na podobnej ucel jako ma byt MicroPC sem ho v pohode pouzival, vykon neschazel vubec, rozliseni bylo horsi(1024x600), ETH sem musel pres USB port redukci, USB to ma jenom 1, SSD rozhodne mnohem pomalejsi...

[miloš19]

to už tento terminal je lepsi a lacnejisi https://youtu.be/ndflyslzAEU

[miloš19]

alebo tento , ten ma aj lepsi obal https://youtu.be/SO4amBc0Tbw

[Bystroushaak]

Lepší v čem proboha? Vždyť ta klávesnice je totální vtip, by ses posral na tom napsat tři věty.

[Jendа]

Raspberry Pi nemá power management!

[D-Evil]

Vyráběj už asi pátý zařízení a pořád na to potřebujou crowdfunding? Trochu divný...

[Aleš Kapica]

Bez toho by museli zaplatit distribuční síť.

[Nereknu]

Zjistí, jestli je o to zájem a jak velký a pak můžou podle toho nastavit oficiální prodejní cenu. Udělají si celkem pěkné promo. A nenarvou do vývoje svoje prachy a tak se nestane, že by na tom prodělali.

[snajpa]

Proc je to divny? Ono je nekde psany, nebo aspon naznaceny, ze se to muze jenom asi ctyrikrat, aby to divny nebylo?

[j]

Zjevne duveryhodna firma ...

[k3dAR]

Jake UMPC vyrabis Ty? Nebo jinej produkt? Blbe kecy se nepocitaj...

[Peter Golis]

Dá sa to kúpiť aj bez tých Windows?

[2017]

Fullhd lepsi displej za $250 COTS https://www.alza.cz/visionbook-13wa-plus-d5495515.htm

[Jendа]

Ach jo, to se po zavedení moderovaných diskuzí na Rootu přesunuli všichni tro(t)lové sem? Jeden to srovnává s mobilem, který nemá klávesnici a neběží na něm normální Linux, druhý zase jako reakci na 6" 440g krabičku pošle odkaz na 13.3" 1.3kg notebook.

Možná bych si místo blokovaných uživatelů měl naopak zařídit povolené uživatele, protože tohle je akorát otrava.

[ewew]

Možna cesta. Ignorovať.

[mirec]

Š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.

[Josef Kufner]

Je to stavěné na ovládání palci. Na to se trackpoint moc nehodí. Všimni si, že to má na jedné straně touchpad a na druhé tlačítka myši.

[mirec]

Jaj nevšimol. Tak mi to dáva už trochu viacej zmysel.

[Bystroushaak]

Š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.

[k3dAR]

to je podobne(i kdyz s vetsim LCD i rozlisenim atd) memu Viliv N5, od 2010(11?) sem na tom mel Linux, bylo z pocatku par problemu, nesla Wifi/3G/Camera, ne ze by nebyl ovladac, ale neslo to aktivovat, jeden typek na umpcportal tehdy vykomunikoval s vyrobcem specifikace a udelal (bohuzel) closedsource tool na aktivaci, od te doby chodilo v pohode vse az do *buntu 18.04(16.04?) kdy doslo k nejake zmene ze po aktivaci Wifi po natazeni FW to cele zatuhne...

[k3dAR]

https://reverserplus.wordpress.com/2011/02/04/using-gribs-ectool-on-viliv-n5-to-control-ancillary-devices-on-off-status/

[jejda]

Chybí mi na tom nějaká miniaturní optika. U takovýho mobilního prcka je celkem škoda, když neumí pořizovat obrázky z terénu.

[PetebLazar]

Kompatibilitu Win/Linux x86_64 "na cesty" jsem před časem vyřešil pomocí Android tabletu+LTE+VPN+RDP/VNC+stacinarniho_NTB (potažmo BT mini KB/MS na delší výlety). Poslední HW pokus s Atom@W10_tbl, který sešíval v batohu sešíval v Huginu panorama cca ctyři pěší kilometry mne přesvědčil, že tudym cesta nevede. K tabletu mám Ethernet redukci, takže jde dělat i drobná síťová diagnostika.

Posledním mým mini-ntb byla asi HP Jornada 720 a pak jen dlouhodobý platonický vztah k waporware OQO. Kterýžto by se asi dal označit za předchůdce následujících pokusů.

[gnat]

Byl bych s tou deklarovanou podporou Linuxu opatrný. Mám GPD Pocket, kde jí deklarovali také a vydali jen základní polofunkční image Ubuntu 16.04 (např. nefunkční HDMI over USB-C, takže nešel používat dock, nefunkční regulace ventilátoru, ...) Něco se dalo dohromady v komunitě (např. HDMI alespoň bez zvuku), ale dodnes to pořádně nefunguje a potřebuje to vlastní kernel.

[jose17]

nastastie tentokrat to soudrozi celkom zvladli. jedine, co (zatial) nefunguje je flashovanie biosu z linuxu.

[jose17]

co tak pozeram https://wiki.archlinux.org/index.php/GPD_Pocket, tak s tym Pocketom to zas az tak tragicky nevyzera. ze by sa to pohlo vpred?