První netbook s MeeGo

Fujitsu-Siemens bude prodávat tuctový netbook LifeBook MH330 s předinstalovaným MeeGo. Jde o historicky první netbook s MeeGo ve výchozí výbavě. Informuje např. Engadget.

13.2.2011 19:35 | Fluttershy, yay! | Nasazení Linuxu

Komentáře

[Lol Phirae]

Tomu říkám s křížkem po funuse...

[Fluttershy, yay!]

V čem? Nokia není zdaleka jediný, kdo na MeeGo pracuje.

[Neel]

http://www.engadget.com/2011/02/13/intel-promises-teases-meego-smartphone-and-tablet-for-mwc/

[David Heidelberg]

Hlavní je, že MeeGo není na Nokii nezávislé, i když se zavázali pokračovat ve vývoji

[pic]

a co je na mego tak super? měl jsme ho na netbooku na který bylo určeno a nic výraznýho - jak v rychlosti, tak ovládání

[Fluttershy, yay!]

To ti nevím, na všech mých netboocích bootovalo výrazně rychleji než třeba Ubuntu pro netbooky, přitom nevím o tom, že by existovalo obdobné UI, Netbook UX bylo první DE/UI, v němž jsem opravdu používal poznámky a kalendář, jinde mi to přišlo hrozně nepohodlné.

[pavlix]

Meego, v podstatě je to jenom další distribuce, zajímavé jsou ale uživatelská rozhraní, která s Meego přišla.

Pak jsem alespoň já očekával, že se z Meego stane taková stabilnější varianta Fedory (aspoň z mého pohledu) pro mobilní zařízení apod.

[heh]

Proč furt všichni plantají dohromady Meego a Fedoru?

[Fluttershy, yay!]

Moblin byl částečně založený na Fedoře a i MeeGo je jí v něčem dost blízko.

[Tutor]

Ono to zřejmě vychází z požadavků Intelu, který prostě preferuje RPM. Zajímavé také je, že k buildování používají nástroje Opensuse. A podporu core částí Moblinu/Meego implementuje řada distribucí, jako třeba Ubuntu. Takže není Meego jako Meego.

[Fluttershy, yay!]

Zrovna Ubuntu (až na ten Moblin Remix) ani ne, spíš ta Fedora a openSuSE. YUM se už opustil, zůstal zypper, OBS k tomu, ale balíčky se občas používají z Fedory.

[Tutor]

Yum mi sice přijde pořád lepší než Apt (no flame), ale Zypper je skutečně lepší než cokoli jiného. Upřímně nechápu, proč s ním Fedora nepočítá? Člověk by si tipnul, že Fedora nasadí Zypper jako defaultní správce balíků, ale oni ho nemají ani v repozitářích a kdyby OBS nevytvářelo balíčky Zypperu pro Fedoru, vůbec by pro Fedoru neexistoval.

[lukve]

a čo tak kombinacia RPM5 a Smart Package Manager ??? ta rychlost je nenormalna

[pavlix]

Popravdě řečeno Zypper je trochu odlišný, a málokdo má důvod se přeučovat, když na Yumu jsou třeba skupiny balíčků řešené uživatelsky daleko jednodušeji a pohodlněji.

Těžko říct, jestli je Zypper až tak úžasný, jak říkáš (na Meego ho používám).

[heh]

Já když si srovnám Yum a Zypper tak mi vyjde asi toto:

1) Zypper je napsán v C-čku, Yum v Pythonu. Z toho vyplývají podstatné vlastnosti jako rychlost, paměťová náročnost, a napadá mě také nepoužitelnost Yumu, při rozbití Pythonu / instalaci nekompatibilní verze.

2) Zypper má lepší syntaxi (používá zkratky)

3) Zypper umí komplexní SW management, Yum spravuje pouze balíčky (neumí spravovat repozitáře, atd...)

4) Zypper používá SAT-solver. Nevím co používá Yum, ale srovnat se to ve výkonu solveru prostě nedá.

[pavlix]

1) Zypper je napsán v C-čku, Yum v Pythonu. Z toho vyplývají podstatné vlastnosti jako rychlost, paměťová náročnost

To jsou zjevné výhody zypperu, ok.

a napadá mě také nepoužitelnost Yumu, při rozbití Pythonu / instalaci nekompatibilní verze.

Problémy s nekompatibilními závislostmi trpí i céčkové moduly, takže tady +/-. Navíc v takto extrémních případech budu pravděpodobně opravovat pomocí rpm, ne yumu ani zypperu.

Zypper má lepší syntaxi

Určitě? Tak mi zkus napsat obdobu yum groupinstall software-development či yum install @software-development.

3) Zypper umí komplexní SW management

Buzzwords přenechám manažerům :).

Yum spravuje pouze balíčky (neumí spravovat repozitáře, atd...)

Tedy dělá, k čemu je určený :).

4) Zypper používá SAT-solver. Nevím co používá Yum, ale srovnat se to ve výkonu solveru prostě nedá.

Fajn.

[heh]

Problémy s nekompatibilními závislostmi trpí i céčkové moduly, takže tady +/-. Navíc v takto extrémních případech budu pravděpodobně opravovat pomocí rpm, ne yumu ani zypperu.

Spíše jsem měl na mysli, že si uživatel spíše rozbije Yum například instalací nového Pythonu, než Zypper rozbitím libc. Rozbitý libc je hádám nohem fatálnější problém (z hlediska celého systému) než Python.

Určitě? Tak mi zkus napsat obdobu yum groupinstall software-development či yum install @software-development.

Ano. Toto Zypper umí, myslím že dokonce déle než Yum. Zypper rozlišuje 4 typy objektů:

• package
• pattern
• patch
• product

Takže obdobou je nainstalovat pattern software-develoopment

Buzzwords přenechám manažerům :). ... Tedy dělá, k čemu je určený :).

Koukněte sem. Je naopak dost efektní, pokud můžu přidávat, povolovat, zakazovat, nastavovat repozitáře, zapínat a vypínat autorefresh.

Schopnosti Zypperu jsou fakt dost rozsáhlé, nemůžu se ubránit dojmu, že je to první nástroj, u kterého tvůrci skutečně mysleli na uživatele a na funkce, které bude potřebovat. Syntaxe pomocí zkratek je také dost návyková. A nejlepší je, že je to navíc pekelně rychlé

Koukněte sám, co všechno to umí.

[Petr Ježek]

Docela se divím, že ještě někdo neupravil pacman z archu pro jiné balíkové systémy - těžko se hledá, co to neumí a rychlost je maximální možná pro nezbytné kontroly závislostí...

[Jakub Lucký]

Pokud se nepletu, neumí to podepsané balíky...

[pavlix]

Docela se divím, že ještě někdo neupravil pacman z archu pro jiné balíkové systémy - těžko se hledá, co to neumí a rychlost je maximální možná pro nezbytné kontroly závislostí...

Možná proto, že by to málokdo byl ochotný používat.

[heh]

Pacman Archu je typický příklad toho, jak se o nemá dělat. Je to jako kdyby integrovali DPKG a APT nebo YUM a RPM do jednoho nedělitelneho celku. Solver určitě nemá tak výkoný jako je SAT. Koukal jsem na wiki, a pracovat s repozitáři to taky neumí. V zásadě nechápu, co je na tom ak skvělého. Z mého pohledu nejhorší toolsa by design.

[gtz]

Nevím, ale třeba já na něj nedám dopustit.

Skupiny? proč by to nešlo přes zypper zypper install --type pattern xfce

výhodou je integrace správy repositářů a manipulace s nimi. Přes zypper jsem prováděl online upgrade 11.2 na 11.3 v pohodě.

[pavlix]

Skupiny? proč by to nešlo přes zypper zypper install --type pattern xfce

Na čí komentář reaguješ? Nevšiml jsem si, že by někdo psal, že nejdou instalovat skupiny.

výhodou je integrace správy repositářů a manipulace s nimi.

Asi neumím tuto "výhodu" plně docenit, repozitáře mám nastavené v konfigurácích, které jsou zabalené do RPM balíčků (Fedora).

[gtz]

Však vy jste psal, že Yum má správu skupin řešenu jednodušeji. Nechci se zbytečně dohadovat co je lepší a proč, prostě si každý zvykl na něco co používá.

Já jsem si na něj prostě zvykl a Fedoru jsem viděl naposledy ve verzi FC7-8, kdy byla totálně fuj a proto jsem přešel na 9.3 Suse.

Já jsem si třeba hodně zvykl na aktualizaci SW jen z jednoho definovaného repositáře.

stačí mi jen zypper dup -r 4, kdy se provede aktualizace repositáře č.4 tedy v mém případě KDE.

[pavlix]

Však vy jste psal, že Yum má správu skupin řešenu jednodušeji.

Přesně tak, to je to, co jsem psal, tedy nic o nemožnosti správy skupin v zypperu.

[heh]

Já jsem si třeba hodně zvykl na aktualizaci SW jen z jednoho definovaného repositáře.

stačí mi jen zypper dup -r 4, kdy se provede aktualizace repositáře č.4 tedy v mém případě KDE.

Jo no. Tohle by bylo dobré ukázat Debianistům

[gtz]

Já jsem před nějakou dobou hodil KDE-SC z factory do systému a nějak se pak cosi dělo. Tak jsem jen přepsal adresu repositáře a udělal zypper dup -r 4 a KDE se zpět obnovily do funkční podoby. Lze to řešit sice přes Yast, ale ten zbytečně zdržuje.

Buntu si o něčem takovém může nechat jen zdát

[heh]

Ono je to i tím, že Apt nepovažuje downgrade za řešení. Filozofie aptu je jasná - lepší rozbitý systém, než donwgrade balíčků z jiného repo.

[Petr Ježek]

Přiznejme si, že tato filozofie debianu se jinde aplikovat nedá, a to ani u rpm dister s půlroční periodou, o archu nemluvě, kde je downgrade občas potřebný, ale nikoli komfortní...

[heh]

Já si to klidně přiznám. APT je nástroj Debianu, určený pro správu balíčků DEB v repozitářích Debianu. To dělá velmi dobře. Bohužel, k ničemu jinému se nehodí, což je ostatně vidět už na Ubuntu pokud se využvá množství PPA.

[Erbureth]

Ale považuje, stačí si nastavit pinningy.

(Čti: RTFM, noob)

[heh]

Zabalení repozitářů do RPM balíčků je nesystémové řešení.

zypper ar URI repository_name

je prostě univerzální a jednoduché řešení.

[pavlix]

Zabalení repozitářů do RPM balíčků je nesystémové řešení.

Právě naopak, na Fedoře se to používá jako systémové univerzální řešení.

[heh]

Takže když máte repozitář třetí strany (vymysleme si třeba VLC) tak musím jít na web VLC, stáhnout si RPM balíček VLC_repository.rpm, ručně ho nainstalovat, pak yum check-updates....

Alternativou v SUSE je jít na stránku VLC a kliknout myší na tlačítko "one-click-isntall", nebo si přečíst URI rpozitáře, a zadat: zypper ar URI VLC S příslušnými parametry mohu rovnou refreshnout obsah repozitáře, repozitář povolit nebo zakázat, zapnout nebo vypnout autorefresh atd... To vše jedním příkazem. Kdybch to řešil RPM balíčkem, musel bych mít 20 RPM balíčlů pro všechny kombinace nastavení, nebo to dodatečně editovat v repos.d.

[pavlix]

Takže když máte repozitář třetí strany (vymysleme si třeba VLC) tak musím jít na web VLC, stáhnout si RPM balíček VLC_repository.rpm, ručně ho nainstalovat, pak yum check-updates....

Jen pokud to tímto způsobem dělat chceš .

[heh]

A jak to tedy jinak udělám? V případě Zypperu můžu ještě zkopírovat .repo soubor do /repos.d/. Jde o i u Yumu?

(YUM a Zypper jsou kompatibilní, takže by to možná šlo)

[pavlix]

A jak to tedy jinak udělám? V případě Zypperu můžu ještě zkopírovat .repo soubor do /repos.d/. Jde o i u Yumu?

Vždyť je to standardní způsob, ty RPM balíčky obsahujou .repo soubory (a podepisovací klíče, pokud vím), co jiného bys tam čekal?

Mimochodem, myslel jsem si, že mluvíš z pozice znalého.

[pavlix]

Proč furt všichni plantají dohromady Meego a Fedoru?

Jaký s tím máš problém?

[heh]

Meego není Fedora.

[pavlix]

A kočka není myš.

[heh]

Já jsem rád, že to postavili původně na Fedoře, a né třeba na Ubuntu.

[pavlix]

Že by jiný heh, nebo popíráš sám sebe? :)

[heh]

Nepopírám. Části Meego 2 postavili na základech Fedory. Což ale není totéž jako Fork Fedory. Nejsou myslím ani kompatibilní. Další nástroje využívají ze SUSE (Fedora a SUSE jsou částečně kompatibilní). Takže je to kočkopes

[pavlix]

Tak proč jsem dostal od tebe vynadáno, když jsem se zmínil o blízkosti Fedory a Meego?

[the.max]

tak jen aby take nebyl posledni

[Beetljuice]

A já myslel, že je to do loňska už zas jenom Fujistu Computers a né Fujitsu-Siemens.

[Tutor]

Dneska je to Fujitsu. Siemens dávno vycouval. Ostatně jako u Mobilů.

[Ravensun]

Já myslel, že Meego je zaměřená na ARM procesory. Když jsem verzi 1.1 zkoušel nabootovat na Asus Eee T91 (Atom 2x1,33GHz), tak to nenaběhlo (škoda). Možná jsem tu flašku blbě připravil... No každopádně jsem rád, že se nějaký výrobce odvážil tuto zajímavou distribuci vtáhnout do trhu, ale obávám se, že nasazení této distribuce na tento HW není zrovna šťastné... Spíš bych to viděl na nějaký dualsim smart mobil. To by mohla být dobrá volba. Dualsim mobilů není zrovna moc (pokud nepočítám čínské výrobce).

[Tutor]

Meego Vzniklo sloučením Maemo (ARM, Nokia) a Moblin (x86, Intel). Podporovány byly obě platformy, ovšem na straně x86 byl díky Intelu (a dnes i AMD) podle mého skromnéo názoru mnohem větší zájem, než u ARM (což se potvrzuje ve světle posledních událostí v Nokii)

[Fluttershy, yay!]

GMA 500?

[Ravensun]

Integrovaný grafický akcelerátor Intel GMA 500

Ano to asi bude ono. Vzhledem k tomu, že toto je snad první Intel grafika se kterou jsem se setkal, nejsem teď v obraze jak to s ovladači pod linuxem je. Ale pokud si matně dobře vzpomínám, tak právě s těmito řadami byly největší potíže. Snad se to zleší, protože by to moc rád vyzkoušel na tom Asus Eee T91, potenciál by na to díky otočnému displey a dotykové obrazovce měl.

[stativ]

Vzhledem k tomu, že toto je snad první Intel grafika se kterou jsem se setkal, nejsem teď v obraze jak to s ovladači pod linuxem je.

To je problém – GMA 500 totiž není od Intelu ale od PoverVR, které na rozdíl od Intelu nechce/není schopné vytvořit ovladače pro Linux.

[Petr Ježek]

Přesně tak, nehledě na intelí nechuť dělat něco navíc pro tržně problematický segment, zde požadovat po PoverVR source...

[Kaacz]

Pripada mi takove uchylne davat MeeGo na iAtom netbook s klasickym non-touch displejem a beznou klavesnici.

Jo kdyby nekdo udelal netbook s ARM/Tegra2, tak neni moc jine volby.

A hlavne tablet s ARM/Tegra2 - vyuzit touch ovladani (samozrejme ne s Netbook UI, MeeGo ma nekolik ruznych UI pro ruzna pouziti). Tam je sila MeeGo.

[Ravensun]

Pozor! Tento NB by měl mít multitouch screen (údajně) viz:

http://www.notebook-tips.com/fujitsu-lifebook-mh330-netbook-meego/

Intel Graphics Media Accelerator 3150th Further details are Wi-Fi, Bluetooth, a trio of USB 2.0 ports, multigesture touchscreen, a 5-slot available in 1, a 0.3 megapixel camera and a 6-cell battery.

[Kaa]

Ano, a na tento netbook s multi-touch lcd dat MeeGo Netbook-UI, ktere s touch lcd ani vlastne nepocita .. je zcela spatne pouziti. Nenechme se tedy mast nicnerikajicimi jmeny jako netbook.

[Fluttershy, yay!]

Netbook UX v MeeGo 1.1 s vícešmatláním počítá a to UI mi od začátku přišlo vhodnější pro dotykový displej než pro šmatlaplošku.

[Petr Ježek]

No bodejť, k čemu Meego na nešmatlací displeje? Tohle je podstata věci!

[Ravensun]

No právě! Vzhledem k tomu, že Meego se mi nepodařilo pod Eee T91 spustit, tak spekuluji, ale mám pocit, že Meego nemá od základu ani kurzor myši. Tak jak by se pak člověk s touchpadem pohyboval? :) Řekl bych, že Meego je připraveno na matlání po displayi lépe než na matláni po té plošce pod klábosnicí :)

[Rezza]

Intel uz Netbook UX zabil...