The Machine - memrisztor-alapú gépben látja a jövőt a HP

 ( trey | 2014. június 13., péntek - 7:25 )

A Yahoo Finance egy érdekes cikket közölt tegnap arról, hogy a HP nyíltan szembemenne régi, jó szövetségesével, a Microsofttal és saját operációs rendszerrel próbálná megtörni a Windows hegemóniáját. A sztori onnan indult, hogy a HP közölte, egy új irányvonalban látja a számítástechnika jövőjét. Éppen ezért bejelentette The Machine elképzelését, ami nem más, mint egy memrisztorra épülő, új számítógép-architektúra.

Az új vashoz új operációs rendszer is dukál, így a HP annak fejlesztésébe is belefog(ott). Az operációs rendszer a rendkívül eredeti Machine OS munkacím alatt készül, de a vállalat azt is megszellőztette, hogy Linux és Android alapú operációs rendszer faragása is elindul a hardverhez. Windowsról nem esett szó.

Ez utóbbi tényt a Yahoo Finance úgy kezelte, hogy a HP tervei közt szerepel a Windows elpusztítása. Ennek megfelelően a cikke a "After Announcing Plans To Destroy Microsoft Windows, HP CEO Meg Whitman Pulls A Gutsy Move" címmel jelent meg.

Az oldal beszámolója szerint a HP műszaki/technikai igazgatója, Martin Fink arról beszélt, hogy cége egy vadonatúj, nyílt forrású operációs rendszert fejlesztene és a rendszer megtervezésébe, kifejlesztésébe bevonná az egyetemeket is. Fink arról beszélt, hogy a HP felélesztené az egyetemi operációs rendszer kutatást és fejlesztést, mert úgy gondolja, hogy az már évtizedek óta szunnyadó, stagnáló állapotban leledzik.

Természetesen napjainkban nagy volumenű kutatás-fejlesztési bejelentés nem mellőzheti a "Linux" szót, így a HP kiemelte, hogy van egy csapata, amely megkezdte a munkát és egy olyan Linux környezetből indult ki, amelyből minden felesleges dolgot kiszórtak.

A Yahoo Finance szerint nem nagy meglepetés, hogy a HP egyre inkább függetlenedni akar. A HP vezérigazgatójának, Meg Whitman-nek már voltak olyan elejtett szavai, hogy mélyreható változások tapasztalhatók a versenyben. Ez egyebek mellett abban nyilvánul meg, hogy a jelenlegi partnerei, a Microsoft és az Intel partnerből nyílt versenytárssá lépnek elő.

Hogy a HP ambiciózus terveiből mi válik valóra (ha egyáltalán bármi is valóra válik), az természetesen a jövő zenéje...

Részletek itt és itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ha belegondolunk, azért Linus licenc választása szerintem nagyon meghatározó volt hogy idáig eljuthasson a Linux. Objektíven vizsgálva a dolgot, úgy gondolom hogy BSD szerű licenccel vagy zárt kóddal nem jöttek volna létre azok a tényezők és lehetőségek, melyekkel túlélte a kód a korai szakaszát.

he?
_____________________________
Powered by 1,3,7-trimetilxantin

Nem logikus?

Szerintem az, csak annyira nem fejted ki. Ha valakinek nem tiszta, log69 azt mondja, hogy BSD szerű licenc-szel senki nem nyitotta volna ki a forrást, tehát a linux nem fejlődött volna, mint a jelenlegi helyzetben: minden kódot meg kell nyitni ezért ha stabil akkor megy a patch a mainline kernel-be.

Értem, mit mond, de nem értem a logikáját. A BSD licenc esetén se kell semmit megnyitni (a forrást legalábbis biztos nem). Nem értem, hogy a BSD licenc ebből a szempontból miért lenne "akadályozó tényező" a GPL-hez képest.

"A BSD licenc esetén se kell semmit megnyitni..."

GPL esetén viszont mindenképpen meg kell. Ez adja a nagy különbséget.

Ez a szokásos tévedés a GPL licenszel kapcsolatban. A GPL licensz alatt fejlesztett kódnak sem kell megnyitni a forráskódját, csak akinek el/oda/átadod a futtatható binárist, annak számára korlátozás nélkül elérhetővé kell tenni a forráskódot, az összes joggal együtt (amiben a forráskód publikálása is benne van)
Gyakorlati példák:
- Kalapálsz egy drivert a Linux kernelhez, amit csak "házon belül" használtok -> nem kell senkit értesíteni róla, vagy publikálni a forráskódját
- Eladod a termékedet (benne a fenti driverrel) egy harmadik félnek -> a harmadik félnek oda kell adni a forrást, korlátozások nélkül. Senki másnak nem.
- A harmadik fél tovább kalapálja a drivert -> nem kell sem téged, sem senki más értesíteni róla, sem kiadnia a forrást valakinek
- A harmadik fél úgy dönt, hogy publikálja driver forrását -> GPL licensz alatt megteheti.

Ezt senki nem mondta. GPL-nél akkor kell kiadni a forrást, ha terjeszted. A disztribúciók pedig terjesztik. BSD-nél ekkor sem kell feltétlen odaadni a forrást. Egyetértünk?

De, te mondtad: GPL esetén viszont mindenképpen meg kell. Ez adja a nagy különbséget.

A többiben nyilván egyetértünk.

Ez igaz és több élő példa is van GPL kód kapun belül tartására. Egyik az opensource világ fekete lyuka, a Google. Mivel ő szolgáltatásokat nyújt linux szerverek tízezrein jogilag semmilyen belső módosítás kiadására nem kötelezhető. Biztonsági érvek is amellett szólnak, hogy ne adja ki saját patcheit. Bár az utóbbi időben önkéntesen nyilvánossá teszi a Google is a linux kernel patcheit annak ellenére, hogy erre semmi nem kötelezi.

Másik élő példa a katonai szervezeteknek dolgozó linuxos rendszerfejlesztők. Ott a megrendelő katonai szervezet megkapja a forráskódot, valószínű GPL licenc nélkül is megkövetelnék de mások számára nem jutnak ki a patchek. Sőt valószínűleg részletesebb hírek sem.

Az esetek nagyobbik részében mégis érezhető a különbség. A PS4 rendszere már nemcsak BSD kódokon alapul mint az előd konzolé hanem konkrétan módosított FreeBSD. Mégsem lehet sehol hozzájutni PS4 OS-hez, senki nem építhet otthon PS4 klónt. Pedig most már a hardverrel se lenne probléma, amióta a Playstation is PC lett. De a Linuxos Steam OS letölthető szabadon és bárki építhet magának saját Steam Machinet. Ebben benne van a Valve sokkal nyíltabb és szabadabb vállalati kultúrája szemben a Sonyval. De a GPL és Linux rendszerek sikere is benne van abban, hogy kialakult egy ilyen nyíltságot kedvelő és támogató vállalati kultúra, amit egyre több nagy informatikai cég felvállal. Nem azért mert így jótékonykodik hanem azért mert megéri neki.

Kicsit had vitatkozzak.

A BSD-s PS4 példádat nem értem. Ott nem kötelező kiadni a forráskódot a Sony-nak.

Illetve a korai szakaszban - hogy ezt a Linux túlélte - szerintem a sikere nem annak volt betudható, hogy mostanában szerinted kedvelik a vállalati szférában a nyíltságot. Akkor ehhez kevés köze volt szerintem.

Másik hogy megint szerintem nem sok köze van a sikerhez annak, hogy egy fejlesztő egy adott megrendelőnek felhasználja a szoftvert és így csak neki kell átadnia a kódot. Ugyanis maga a Linux nagy számban való felhasználást céloz. Úgy értem hogy az egy operációs rendszer. Tehát egy elég alacsony rétegben helyezkedik el. A fejlesztők erre csak építenek, és ha a felépített terméket közreadják, akkor máris ki kell adni a kódot - főleg ha publikus a közreadás, ekkor nagy számban.

A webes szolgáltatásban való felhasználás megint nem jelentkezik hátrányként. Tehát amiket felsoroltál, kicsit burkoltan hátrányként akartad bemutatni - némely részt, de szerintem mondhatod hogy nem pozitív egy felhasználás, de negatívnak semmiképp. Márpedig ha valami vagy semmi vagy pozitív, akkor más típushoz képest - ott ahol nem ez jellemző - csak előrébb juthat.

Illetve pont az, amit a GPL képvisel - épp ez hozta a nézetet is szerintem (amit írtál hogy kedvelik a nyíltságot). Ennek pedig egyértelmű oka szerintem, hogy a GPL-es cuccok az iparnak olyan szellemi termék, ahova bátran belefektethetnek, mert amit beletesznek, az megmarad. És mindenkinek, ez igaz. Viszont így megint másnak is vonzó lehet, tehát egy olyan kalapot kap mindenki, amibe tizen 1 forintot tesznek bele, és ezután tizen tíz forintot vesznek ki.

Ez megint a GPL érdeme _szerintem_.

Ráadásul amit pl. RH-nél látni, hogy több éve ugye megszüntette a kernel patch-ek külön publikálását és a kernel forrást csak egyben adja ki - megnehezítve a versenytársak helyzetét - ez is azt mutatja, hogy ha meg lett volna a lehetősége - pl BSD licenccel - valószínű elmehetett volna a folyamat könnyen egy olyan irányba, hogy egy időtől kezdve megszünteti a forrás kiadását. Vagy ott van a mostani CentOS és git téma. A levlistán vannak spekulációk - de független attól hogy ezeknek van-e alapja - megint csak az előbbi lenne könnyen lehetséges BSD licenccel.

Szerk.: tehát jó jó a licenc, a piacon felkapaszkódoknak tetszik is, ezért hozzájárulnak a teljes iparághoz. Aztán persze mikor nagyra nőttek, már jó lenne megtartani a piacot és ehhez jó lenne bezárni a kódot. De pont a licenc ezt megakadályozza, és a kerék gurul tovább.

A PS4-et arra hoztam példának, hogy BSD licencnél ahol lehet bezárják a kódot. Bár ahogyan gd írja valóban lehetne linux alapon is zárt konzolt csinálni, csak a szükséges minimumot adnák ki amiből nem lehetne saját konzol klónt építeni, ezt a GPL megengedné. Mégis olyan irányba terelte a GPL például a Valve stratégiáját, hogy egy teljesen nyílt konzolt csinált.
Azért tartom érdekesnek a PS4 és Steam konzol összehasonlítását mert bár mindkettő nyílt forrású rendszert használ, a PS4 FreeBSD-vel egy teljesen zárt konzolt hozott létre még a Valve Linuxszal egy nyíltat. Nem minden nyílt a Steam OS-en sem, például maga a Steam kliens zárt, de az is szabadon letölthető a rendszerrel együtt. Így ha valaki Steam konzollá akarja alakítani a notebookját megcsinálhatja magának. Hordozható PS4 viszont nem lesz.

> Így ha valaki Steam konzollá akarja alakítani a notebookját megcsinálhatja magának.

És ez mitől lesz neki jobb, mint egy akármilyen Linux + a Steam kliens? SteamOS-en is csak azok a cuccok futnak, amit már egyszer kiadtak Linuxra.

Kicsit off, de nekem mindig is az volt a fenntartásom a Steam konzollal kapcsolatban, hogy a SteamOS látszólag semmi pluszt nem ad.

"Kicsit off, de nekem mindig is az volt a fenntartásom a Steam konzollal kapcsolatban, hogy a SteamOS látszólag semmi pluszt nem ad."

SteamOS = nem tudok telepíteni egy nyomorult Ubuntu-t

Nyilván, lesz olyan, aki nem is akar / tud / nem is érdekli mi fut rajta. Nekik konzervként lesznek SteamOS gépek az áruházakban a polcon.

Aki meg eddig is maga rakta össze játékgépét, megválogatva az összetevőket, elszarakodva vízhűtéssel, extra bordákkal, overclockinggal, rikítózöld neonvilágítással, az ezután is maga tákolja az OS-t rá.

Ezek meg fogják tanulni azt a két extrém bonyolult lépést, ami egy Ubuntu telepítéséhez kell addig, amíg arra a Software Centerből feltolja a Steam klienset, illetve feltelepít egy prop. NVIDIA drivert.

Ehhez annyi sem kell, mint annó DOS-ban betölteni a himem.sys-t, az mscdex.exe-t, felparaméterezni egy Soundblaster-t vagy Gravis-t és betölteni egy egérdrivert.

Hogy a Windows elhülyítette az embereket, az tiszta sor, de attól még nem mindenki informatikai analfabéta.

--
trey @ gépház

> de attól még nem mindenki informatikai analfabéta.

Jajaja, ezért kérdezem, hogy miért akarná valaki hozzáértőként, megalapozott döntéssel lebutítani egy notebookot? Aki nem tud feltenni egy Ubuntut vagy egy Windowst, annak a SteamOS-sel is meggyűlik majd a baja.

Az majd vesz egyet valamelyik elektronikai áruházból ha nagy lesz rá a kereslet, vagy vesz mások által készre szerelt Steam Machine notebookot az Ebay-ről ha kisebb lesz rá a kereslet.
Én azt tippelem, hogy mérhető piaci igény van notebookszerű hordozható konzolokra. A Sony kipipálta ezt PSP-vel a Nintendo Gameboyokkal a hordozhatóság igényét. Csak a kézikonzol baromira nem az, inkább a mobilgaming megfelelője manapság. Lassan ki is szorítják az okostelefonok.
A lényeges különbség a nyílt és zárt konzolplatformok közötti lehetőségekben van. A PS4 soha nem lesz több annál a doboznál amit a Sony ad. A Steam konzolra nemcsak hobbi, de egy kis vagy akár középvállalkozás üzlete is épülhet.

Ez még mindig oké, de miért választana valaki SteamOS-t mondjuk bármelyik Linux disztribúció, ne adj' Isten Windows vagy OSX helyett?

Merthogy a SteamOS *tudomásom szerint* (de fixme) semmivel nem tud többet, mint az Ubuntu, kevesebbet viszont igen. Tehát tudatos vásárlók között valószínűleg hamar le fog csengeni a dolog, de persze könnyen lehet, hogy valamit kihagytam a számításból, és tévedek.

Kihagytad a hatékonyságot. Ha egy kis vagy közepes vállalkozás gyárt Steam konzolokat akkor miért töltene 20 percet a rendszerszoftverrel ha 5 perc alatt megvan SteamOS-sel?
Hobbifelhasználóknál ez természetesen ízlés kérdése. De itt is kérdés, ha veszek egy tetszetős gamer PC-t a nappaliba Steam controllerrel amiből magam faragok Steam Machinet, akkor minek tegyek rá Ubuntut majd arra Steam-et autostartra konfigurálva ha készen megkapom ezt a SteamOS-től? Egy nagy lapos tv-n Steam-et nagy képernyő módban kényelmes használni fotelből.

Nem mindenki geek, az informatika tömegessé válásával egyre kisebb a geekek aránya annak ellenére, hogy számuk nem csökken sőt vélhetően nő. Geek-szemlélettel nem lehet megérteni az átlagfelhasználó és átlaggamer igényeit, sőt megtéveszt a geek szemlélet.

A SteamOS és Steam Machine szerintem egy mézesmadzag, ami azért kellett a Valve-nak, hogy elhúzhassa a játékstúdiók orra előtt.

A Valve mindenképpen ki akarta terjeszteni a Steam birodalmat Linuxra. Azt gondolta, hogy ez a legegyszerűbben úgy fog menni, ha belenget egy egységes platform és konzol elképzelést. Ha ez megvan, akkor az AAA cégek is felfigyelnek. Így is lett.

Azt nem feltétlen kell a stúdiók orrára kötni, hogy tulajdonképpen egy Ubuntu is megteszi, illetve, ha kijönnek a játékukkal a SteamOS-re, akkor az tulajdonképpen egyenlő azzal, hogy Linuxra is kijöttek.

Hogy a Valve mennyire egynek gondolja a SteamOS-t a Linuxszal, az pedig egyértelmű.

Bele kell nézni a Steam linuxos verziójába. A Library-k alatt "SteamOS + Linux" szekció van.

--
trey @ gépház

Szerintem függetleníteni akarta a Steamet a Windowsoktól mert világossá vált az, hogy a Microsoft jövőképébe nem fér bele a Steam. Egyrészt konkurens boltot nyitott a Windows 8-ba integrálva, másrészt teljes gázzal tolta a tabletes vonalat. Egy Windows tablet még ha x86-os is kevés az AAA játékokhoz. A Microsoft jövőképében Xbox lett az AAA gamer platform még a PC-t az Android és iOS ellen indította csatába.
Időközben a Microsoft visszatáncolt, a Win 9-re már teljes visszavonulót ígérnek de korábban nagyon eltökéltek voltak a Microsoft szándékai.
A Valve szerintem úgy állította be a SteamOS-t mint egy konzolos Androidot, ami még az Android világnál is nagyobb szabadságot ad a gyártóknak. Ezt a platformot is összefogja egy központi alkalmazásbolt, azaz itt játékbolt ami a Valve kezében van. De ennek a boltnak a kínálata egyben kelendővé is teszi az egész platformot és az erre gépet építő gyártók gépeit. Az Androiddal jól jártak a gyártók, főleg azok akik időben beálltak a platform mögé, akik kimaradtak lemaradtak. Leszámítva természetesen az Applet.

A PS-Steam különbségnek szerintem az az oka, hogy a Sony elsősorban a hardverből él (így azt akarja, hogy a hardver területén minél kevesebb konkurrenciája legyen), a Valve meg a szoftverből (így az az érdeke, hogy minél többféle gépen fussanak a cuccai. Mivel olyan játékokat árulnak, amik Windowson, meg mostanában "generic" Linuxon is futnak, nyilván akárki csinálhat hozzá gépet, nem lenne értelme bezárni.

A hardveren sokat nem nyer, a szoftverből (játékeladásokból) él a Sony is.
A nagyon egyedi hardver kialakítással elsősorban biztosan nem a konkurencia kizárása lenne a cél, inkább az, hogy eddig viszonylag hosszú élettartamot terveztek a konzolnak, amit úgy tudtak biztosítani, hogy játékra és multimédiára hegyezték ki a gépet. Igaz nehezebb rá fejleszteni, de több is benne a tartalék - így nem avul(t) el olyan hamar.

"Azért tartom érdekesnek a PS4 és Steam konzol összehasonlítását mert bár mindkettő nyílt forrású rendszert használ, a PS4 FreeBSD-vel egy teljesen zárt konzolt hozott létre még a Valve Linuxszal egy nyíltat. Nem minden nyílt a Steam OS-en sem, például maga a Steam kliens zárt, de az is szabadon letölthető a rendszerrel együtt. Így ha valaki Steam konzollá akarja alakítani a notebookját megcsinálhatja magának. Hordozható PS4 viszont nem lesz."

Igen hamar jött az igazolás. SteamBoy: jövőre érkezhet a Steam OS-es kézikonzol

A hétvégén láttam már ezt a SteamBoy-t, de mivel egy teaser videón kívül még semmi infó sincs róla, egyelőre nekem erősen vaporware-szagú.

--
trey @ gépház

"Hasonló próbálkozásokat eddig leginkább játékosoknak szánt, kontrolleres tokkal felszerelt tabletek formájában láthattunk, noha azokon termesztésen nem Steam OS, hanem Windows futott, és hordozhatóság szempontjából jóval elmaradtak a SteamBoy koncepciója mögött."

Nem tudom mire gondolt a cikkíró. Én ismerek hasonló gamer tableteket analóg joy karokkal és gamepad gombokkal, de azok kizárólag Android eszközök. Mindenesetre ha vannak már ilyen Windows PC hardveres eszközök akkor ez is valami hasonló lehet belül. Sok múlik a CPU és GPU-n. Ha valami Intel Atom variáns kerül bele akkor felejtős az egész. A kis méret miatt valószínűleg CPU és GPU magokat kombináló APU-ban gondolkoznak. Ha lesz megfelelő AMD APU akkor egy underclockolt változatával még jó gép is lehet ebből.
Én egyébként konzervatívabb notebook kivitelre gondoltam, annak semmi akadálya, például az Alienware is gyárt gamer notebookokat, amik ideálisak Steam Machine notebooknak is.
Ez a hír szerintem arra jó példa, hogy egy olyan nyílt konzol mint a Steam Machine megmozgatja a gyártók fantáziáját, aktívan bekapcsolódnak a konzolplatformba az ötleteikkel. A hermetikusan zárt konzoloknál mint a PS4 vagy Xbox One erre semmi esély nincs.

Nem ismerem a PS-t, de azt tippelem, hogy itt inkább az OS fölött lévő proprietary libek az okai annak, hogy nem tudsz mondjuk egy FreeBSD-n PS játékokat futtatni, mint az OS módosításai. A fölötte lévő libeket meg Linuxon se kéne kiadniuk.

A nyílt forrású programon futó szolgáltatásokra lenne megoldás, az Affero GPL, ahol ilyen esetben is ki kell adni a módosításokat. De a Linuxnak nem ilyen a licensze.

Szinte lehetetlen küldetés, de hajrá, a verseny jó dolog..

--
arch,xubuntu,debian,windows,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Huh, szerintem nem a Windows hegemóniájának megtörésére kellett volna kihegyezni ezt a posztot. Egyrészt mert az már megtört, másrészt mert ha a Microsoft nem akarja a DEC VMS-ének a sorsát követni, akkor dobja a Windowst és az Azure-t és inkább valódi hasznot hozó termékekre koncentrál. Egyelőre ahelyett, hogy minden korábbinál magasabb szintre emelné az Office, OWA, SharePoint és hasonló termékeit, azzal vacakol, hogy mégse legyen Win8.1-ben Start menü, egy rakás pénzt beletol a WinPhone-ba és egy saját Google mentes Androidba, ahelyett, hogy Tizen + .Net alapokon lerobbantaná a Google fejét. A Windows elődjével, a VMS-sel együtt halott, igaz kell egy 20 év, mire valóban eltűnik. De ennek semmi köze a The Machine-hez.

The Machine lényege a HWSW cikkében is benne van: a cél a háttértár és operatív tár összevonása. Szerintem első körben nem kell ehhez új OS, RAM diszk is megteszi háttértárnak. A második lépés a RAM diszkről operatív tárba való másolás kiküszöbölése. Egy cél OS biztosan hatékonyabb volna, de ez meg hamarabb lenne használható (a meglévő appok miatt). Ismerve a mai szoftverek minőségét, a kikapcs-bekapcs köröket nem ússzuk meg így sem. Viszont a bootolás / app újraindítás / VM újraindítás villámgyors volna.

Azert vegyuk eszre, hogy a linuxot kepesek modositani maguk is.
ha a kernelt atirjak, hogy egysegesen kezelje a hatterben a memoriat es a hattertarat, akkor a jelenlegi API-t is megtarthatjak, vagyis az osszes meglevo linuxos program ki fogja tudni hasznalni a memrisztoros gep elonyeit, akar valtoztatas nelkul.

--
Live free, or I f'ing kill you.

Igen, erre gondoltam én is.

"Ismerve a mai szoftverek minőségét, a kikapcs-bekapcs köröket nem ússzuk meg így sem. Viszont a bootolás / app újraindítás / VM újraindítás villámgyors volna."

En a gepemet havonta 2-3x inditom ujra, kikapcsolas helyett meg sleep-elem. Egy indulas az SSD miatt win8-al a desktopig <1percig tart, de ennek mar nincs jelentosege...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Én meg pont tegnap indítottam újra az S3 Galaxy i9305-ömet, mert a default híváskezelő appja nem tudta a mikrofont és hangszórót használni. Érdekes, a többi appnak ment. Újraindítás után minden OK. A WinPhone-om meg a csempékről feledkezik meg néha. Itt is az újraindítás segít.

> dobja [...] az Azure-t
Na, attól mentsen meg minket az ég. :) Az Azure a (nekem) eddig legjobban bevált felhő, szomorú lenne, ha bedőlne. (Amúgy nem fog, mivel a MS is aktívan használja a saját cuccaihoz.)

> ahelyett, hogy Tizen + .Net alapokon lerobbantaná a Google fejét
Mitől lenne jobb a Tizen+.NET, mint a WP+.NET? WP-re eddig is C#-ban fejlesztettünk (meg vagy egy tucat másik nyelvben, de a .NET attól még ott van)

> Mitől lenne jobb a Tizen+.NET, mint a WP+.NET?

Technikailag nem jobb. R&D költségekben viszont megéri. Nem kell a zsugorodó Win platformmal szüttyögni, nem kell az IE-t folyamatosan fejleszteni, meg ilyenek.

Szerintem nem, mert akkor meg minek .net? A wp kifejezetten jól sikerült OS, azzal nincs semmi baj. A probléma az asztali winnel van, de ha lesz modern start menü (voltak ilyen képek) illetve futnak ablakban a modern appok akkor jó lesz.

Az ie-t mondjuk tényleg dobhatnák, szerintem feleseleges.

> A wp kifejezetten jól sikerült OS

Igen, ezért írtam, hogy a Tizen "techikailag nem jobb".

> azzal nincs semmi baj

Szerintem meg igen, méghozzá R&D költség oldalon.

> Az ie-t mondjuk tényleg dobhatnák, szerintem feleseleges.

Csak az az egy bökkenő, hogy WinPhone-ra nincs igazán jó alternatív böngésző. Symbianra és Androidra meg van. És valszeg Tizenre sem nagy ügy portolni egy WebKit/Chromium alapú cuccot.

WP-re se nagy ügy portolni egy webkit alapú dolgot ie néven...

A háttértár és az operatív tár összevonására most is van létező és működő megoldás:

http://en.wikipedia.org/wiki/Single-level_store

http://db2fori.blogspot.hu/2012/11/one-of-crown-jewels-single-level-storage.html

Ez csak sima lapozás, nem sokkal több, mint egy mmap (+ az IBM marketing). Amiről a HP beszél, a memrisztorok, azok olyan "izék", amik gyorsak, mint a RAM és nem felejtősek, mint az SSD, ezért kiválthatnák mindkettőt egyszerre - ráadásul bizonyos aritmetikai műveleteket is el tudnak végezni, de ez már scifi kategória. Nagyon-nagyon leegyszerűsítve a számítógépedben lesz 256GB memrisztoros memória, amiből vagy 250GB-on oprendszert meg játékokat tárolsz, és 6 GB-on fut a program, vagy csak 100GB-on tárolsz oprendszert meg játékokat, és akkor 156GB operatív memóriád marad (nem elfelejtve azt, hogy a programok meg a libek már úgyis benne vannak az memrisztoros memóriában, szóval a 6/156GB csak a program által dinamikusan generált adatokhoz kellenek, a kód futtatásához nem).

Ezt ebben a formában jelenleg egyetlen oprendszer sem támogatja.

Nem jó, még mindig tárterületben és futtatási területben gondolkozol. Egy nem felejtő memóriás gépben ezt nem kell megkülönböztetni. A programok egyetlen példányban léteznek, az egyszerűség kedvéért mondjuk úgy, hogy az operatív tárba betöltve. De igazából nem kell betölteni. Installáláskor bekerül a gép memóriájába, esetleg ekkor végrehajtódnak a megfelelő inicializációs rutinok és onnan kezdve a program mindig "fut". Persze csak amikor vezérlést kap. Innentől kezdve nincs értelmezve az, hogy a program elindítása, a program leállítása. Mert az ilyet nem tesz.
Ettől függetlenül még mindig szükség lesz háttértárolókra, adatbázisok formájában. Persze ez attól függ, hogy milyen költségei lesznek a memrisztornak. Hogy pár kilobyte-os, mega-, giga-, esetleg tera-, petabyte-os nagyságrendben lehet majd hozzájutni?
Viszont nem lesz szükség virtuális memóriakezelésre, hisz az alkalmazások installálás után mindig ugyanott lesznek. Bár azt el tudom képzelni, hogy biztonsági okokból egyes programok időnként új memória területre kerülnek.

Ave, Saabi.

Es akkor, hogy futatnek ket ls -t egyszerre ?
Vagy az ilyesmi csak mestersegesen generalt igeny ? :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

annyi ls-t indithatsz el, ahany ls van a szamitogepeden. Ha ket ls kell, meg kell venned ketszer, tiszta sor.

Es mindnek kulombozo lesz a neve :)

BTW: MMU / COW nelkul a read only reszek (code) meg mindig lehetnenek osztottak (shared).


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Arról van szó, hogy ha nincs külön háttértár és operatív tár, akkor a kód területe - függetlenül attól, hogy a program nincs elindítva, 1 példányban vagy több példányban fut - a memrisztor tárban mindig egyetlen példányban van jelen. Persze minden futtatásához (processzhez) létrejön a hagyományos adat és verem terület, tehát futtathatsz több ls-t is egyszerre.

Szerinted ha most 15 darab ls parancsot indítasz el egyszerre ugyan azon a gépen, akkor annak a kódja (a futtatható elf program + a libek) hányszor töltődnek be a memóriába?

hint: csak egyszer.

Szerintem a ro code section egyszer (kiveve ha valmiert kikerul a memoriabol), a data section egyszer, de modositasok COW (coda-ra is igaz ha modositanak), a bss meg minden processnel kulon alocalt.

A specialis reszek meg alapvetoen csinaljak valmelyiket a harom opcio kozul :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> Innentől kezdve nincs értelmezve az, hogy a program elindítása, a program leállítása.

Szerintem ez túlzás. A program attól még nem fut, hogy a kódja be van töltve. Minden futó példányához kéne pl. adat és verem terület, regiszterek (pl. instruction pointer).

Viszont ha nagy kapacitású és olcsó a memristor, akkor valóban vannak olyan alkalmazások, amiket érdemes olyan állapotban hagyni, hogy vezérlést ugyan nem kap, de nincs leállítva (adat, verem, regiszterek megmaradnak). Esetenként így lehetne olcsón példányosítani a felhőben, hogy nem kell egy VM-et bebootolni.

> Viszont nem lesz szükség virtuális memóriakezelésre

Ez ebben a formában nem igaz. Lemezre swappelésre nincs szükség, de a fizikai és logikai címek dinamikus összerendelésére igen, különben a memória foglalások és felszabadítások által létrehozott lyukak miatt egy idő után esetleg nem tudnál nagyobb területet foglalni, mert nem lesz egybefüggően elég területed.

Olvasd el az angol http://en.wikipedia.org/wiki/Virtual_memory oldalt. A magyar nyelvű cikk, főleg a bevezetője, jelenleg sajnos erőteljes javításra szorul.

Idézet:
> Viszont nem lesz szükség virtuális memóriakezelésre

Ez ebben a formában nem igaz. Lemezre swappelésre nincs szükség, de a fizikai és logikai címek dinamikus összerendelésére igen, különben a memória foglalások és felszabadítások által létrehozott lyukak miatt egy idő után esetleg nem tudnál nagyobb területet foglalni, mert nem lesz egybefüggően elég területed.

Én úgy képzelem el, hogy nincsenek memória foglalások és felszabadítások. Hiszen a programokat egyszer, telepítéskor kell betölteni a memóriában és ott maradnak az "uninstallálásukig".
A több példányban futásról meg annyit, hogy biztos, hogy ilyen helyzetben szükség van erre? Én nem valami unix szerű cucc igazítását képzelem el egy ilyen gépre, hanem valami teljesen újat. Ahol egy program egyetlen példánya szolgálja az összes felé küldött felhasználási igényt. Teszem azt: nem programot indítok el, hanem feladatot adok a meglévő, futó programnak. Ami a feladata végeztével nem leáll, hanem várja a következő feladatot.
Ne unixos fejjel képzeljétek el, hanem inkább mint egy sci-fi regényt. Rengeteg ma ismert technika az operatív memória és a háttértár megkülönböztetéséből adódik. De ha ezekre nincs szükség, akkor sokmindent egyszerűbben is meg lehet oldani.

Ave, Saabi.

"nincsenek memória foglalások és felszabadítások. Hiszen a programokat egyszer, telepítéskor kell betölteni a memóriában"

A programkódot egyszer kell felrakni, de attól még az adatoknak, amikkel dolgozik, le kell foglalni memóriát, és fel kell szabadítani. Sok algoritmus sokkal több memóriát használ futás közben, mint a bemenet, meg a kimenet. No meg nem árt, ha egy segfault se tesz be véglegesen.

Ma is így működik, lásd pl a .dll fájlokat. Egyszer töltődik be 1 példányban és kiszolgál sok kérést.

Jogos, a nagy lelkesedésben nem gondoltam át rendesen.

Ave, Saabi.

Pont ugyan azt írtam, amit te. Leírtam azt is, hogy telepített program már benne van a memóriában. ;)

De a hozzászólásodban szétválasztottad a tárolt és a futtatott kódot. Vagy félreértettelek.

Ave, Saabi.

A tárolt és a futtatott kódot annyiban választottam szét, hogy a futtatott kódnak a tárolt adatokon kívül is van memória igénye futás közben. Ha törölsz a "háttértáron" levő adatokból, akkor a futás közbeni adatoknak több hely jut, és fordítva.

"Ez egyebek mellett abban nyilvánul meg, hogy a jelenlegi partnerei, a Microsoft és az Intel partnerből nyílt versenytárssá lépnek elő."

Ha en HP lennek, nem orulnek ennek.

Ilyen memrisztorok vannak már? Amikor olvastam róla, kb az örökmozgóval egy szinten lévő elméleti lehetőségként beszéltek róluk...

Hát mindenesetre itt a wikin pont egy HP-s fotóval illusztrálták és a HP kutatásaira hivatkozik a cikk. :)

Igen, laborban, pár éve. A HP 2018 környékére ígéri a terméket: http://www.theregister.co.uk/2013/11/01/hp_memristor_2018/

Ahhoz képest, hogy a már bejáratott technológiákkal kapcsolatban is mekkora csúszások szoktak előfordulni, amikor a tömegtermelést kellene beindítani, ez a hír a "Windows elpusztításával" valahogy rendkívül magabiztosnak tűnik. Vagy az újságíró folyamodott az ebben a szakmában szokásos bombasztikus címválasztáshoz, vagy a HP tud valamit, amit nem kötött a nagyközönség orrára. A jelen hír és úgy általában a memrisztor története alapján én az előbbire tippelnék.

---
Science for fun...

2010 körül volt egy nagyobb áttörés ha jól emlékszem, szóval ez még viszonylag friss dolog. A windows elpusztítása meg IMHO a techsajtó egy része által felfújt dolog (a yahoo meg a hup, ami nagyon felfújta, pl a hwsw híre egész korrekt).
Szerintem ez a dolog arról szól, hogy a RAM és a háttértár összevonása elég komoly OS szintű fejlesztési lehetőségeket vet fel. Erre a HP nyilván egy olyan OS-t alakít át, amit tud - a windows nem ilyen, elvégre zárt forrású. Az iOS-t se említették pl.
Az MS-nek még bőven van ideje felszállni erre a hajóra. Ez először úgyis jó eséllyel a szuperszámítógép-szerver esetleg a mobil piacra jut el. Az egyszerű halandóknak szerintem még egy darabig csak annyi lesz, hogy SSD, HDD meg DRAM helyett memrisztor alapú tárakat veszünk.

Amúgy a HP kicsit tényleg túlzásba esik az ígérgetésekkel: http://www.dailytech.com/HP+to+Deploy+Memristor+Powered+SSD+Replacement+Within+18+Months/article22963.htm

Hm, most olvasgatom wikipedián, a tudományos világ nem ért egyet abban, hogy mi a memrisztor, 4 hasonló eredménnyel kecsegtető technológia verseng, és elég gyanús, hogy a HP csak marketing okokból hangoztatja, hogy ez a hiányzó elem, Chua szerint (aki nagyrészt megfogalmazta az elméletet) mind a 4 memrisztor. Mellesleg úgy tűnik nem a HP vezeti a versenyt.

Kb. egy éve voltunk fizika szakkörön a BME-n, ott mutatták, hogy kutatnak ilyeneket. Maga a technológia működik, a probléma ott volt/van, hogy nehéz gyártani és ezért nem lehet belőle bonyolult chipeket csinálni. De mintha azóta olvastam volna, hogy kitaláltak erre valamit.

wiki 1ns et irt switch timera 2010-bol 3 nm x 3 nm -en.

Itt [1] 100ps-rol irnak, na ez mar tenyleg nem semmi :)

[1] http://nanotechweb.org/cws/article/lab/47858


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

HP will bet the company on a combination of memristors and silicon photonics
http://nextbigfuture.com/2014/06/hp-will-bet-company-on-combination-of.html
“Memristors will be fast, dense and cheap enough to play both the ‘soon’ and ‘later’ roles at once, and thereby speed up throughput by eliminating most of the to and fro,” it said.

How dense? “We want you to be able to store your entire life; think of 100 terabytes on your smartphone,” Fink said. That’s more than a thousand times the storage an iPhone 5S has today.

HP is also designing new, application-specific processors for its architecture. It envisions pools of processors and memory chips interconnected with photonic cables, which Fink said will carry data at up to 6TB per second.

--
Live free, or I f'ing kill you.

Egyrészt értem, hogy ki akarják adni a kutatást egyetemeknek (talán olcsóbb, de biztosan frissebb környezet).
Azt viszont nem értem, hogy miért nem a HPUX-ot "portolnák".

Talán mert nincs olyan állapotban hozzá a HPUX és a fejlesztői köre is sokkal kisebb a Linuxénál. Van HPUX routerre? Vagy HPUX kernellel mobil oprendszer? Internet támadásainak mennyire tud ellenállni a HPUX. Az IBM AIX unixa is jó rendszer, de tele van biztonsági hibákkal ezért tűzfal nélkül csak a vakmerőek engedik ki a netre.

Ezt nagyjából én is tudom, viszont nem látom, hogy tömegével állnának a boltok polcain a memrisztoros telefonok és routerek, tehát ez az érv egyelőre mindegy.
Arra gondoltam igazából, hogy a HPUX -ot nevezhetnénk akár egy jól bevált rendszernek is, amit mondjuk a portolás során ki lehetne pucolni (bugfix, akármi) "és kész".
Még akár külső erőforrásokat (=egyetem) is be lehetne vonni.
De nekem persze mindegy, hogy a HP mivel foglalja el magát.

Ha a technikai hátterétől eltekintünk (mert az nagyjából hitvita, hogy a Linux vagy a HPUX fejlettebb) a jogi oldala akkor is problémásabb a HPUX-nak. Nem kevés licenszelt kódot tartalmaz, aminek a megnyitásához (még egyetemek felé NDA-zva is) nyilván a jogtulajdonosok hozzájárulása kellene, amit vagy adnak, vagy nem, vagy ingyen, vagy csak pénzért. Ha tömegeket akarnak bevonni, akkor jogilag a Linux mindenképpen tisztább és egyszerűbb választás.

Bocs, most nincs időm a cikkeket elolvasni. Azt tudom, mi az a memrisztor. De az erre alapuló hardverek annyira különbözni fognak a maiaktól, hogy ezért kell/érdemes új oprendszert fejleszteni? Vagy az új architektúra csak ürügy egy marketing/területszerző/kiszorítósdi akcióhoz?

Tehát mondjuk egy memrisztoros proci/memória esetén mások lesznek az assembly utasítások, más műveletek végezhető el könnyedén, így tényleg újra kell gondolni az egész ügyet a processz-ütemezéstől kezdve a swappelési stratégiáig?

Ha valakinek volt ideje a részletekre, az kérem írja meg 1 mondatban, gyökeresen más lesz-e ezeknek a "lelke", mint a maiaknak a programozó részéről.

Bocs, közben mégis elolvastam pár cikket és látszik, hogy tényleg az oprendszer alapdolgait is érintik a változások, tehát nemcsak marketingokokból kell az új OS.

http://elinux.org/Kernel_XIP


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Volt mar errol par cikk a hwsw-n. Erdekes, hogy ha jol emlekszem, akkoriban meg azt irtak, hogy nem csak az adatok tarolasaert (HDD/SSD, RAM, Cache) felelos reszeket tudja felvaltani, hanem magat a processzort is, tehat az adatok tarolasaert felelos resz muveleteket is vegre fog tudni hajtani ezeken az adatokon. Mondjuk ez eleg futurisztikusnak tunt. De errol azota nem nagyon hallani. Vagy en emlekszem rosszul es nem volt ilyenrol szo?

+1

Hat a `hagyomanyos`` technika meg minidig gyorsabbnak tunik logikara:
http://en.wikipedia.org/wiki/Multigate_device
"It has a gate delay of just 0.39 picosecond (ps) for the N-type transistor and 0.88 ps for the P-type."

memrisztor legjobb 100 ps amit eddig tallaltam.

Az nem tunik elegnek a jelenlegi CPU-n beluli SRAM -ok teljes levaltasara sem,
de eros DRAM, flash, Blu-ray, magnetic HDD .. killer lehet, ha jo arban tudjak szallitani.

Ha komolyan gondoljak a versenykepes CPU -kat, akkor az iparban szokatlan modon kene
az idozitesekkel jatszaniuk vagy van gyorsabb memristor 2011 ota,
vagy nagyon sok lassu magban gondolkoznak.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hosszútávon radikálisan eltérő architektúrát említenek, és nagyléptékű párhuzamosítást. Közvetlenül az operatív memória lehet a végrehajtó egység is, amiket támogat az, hogy a felületen állítólag kisebb helyet foglal egy ilyen, mint egy FET. Ha helyesen képzelem el ezt, akkor a 3D-s felépítés is könnyebben megvalósítható később, ami tovább gyarapítja az előnyöket. A kapcsolási sebesség biztos fejlödik majd, de ha nem is annyira, alacsonyabb frekvencián akkor is nagyobb potenciált mutat ez az újdonság.

Lazán kapcsolódik: a HP-nál titánium-oxidot használnak, de réz-szulfidból is lehet én is csináltam egyet pár éve. Érdekes.

Kötözködés: titán-oxid az.

Egy érdekes előadás a témában: http://aka.ms/hup-memristor

Üdv,
Marci

"human or other animal"

Nem értem, fejtsd ki légyszi.

Üdv,
Marci