A Linux uralja a világ legnagyobb teljesítményű számítógépeit összesítő TOP500 listát

Linux

Megjelent a világ legnagyobb teljesítményű szuperszámítógépeit összesítő TOP500-as lista legfrissebb, 2013. novemberi kiadása. A listát a TOP500.org állítja össze 1993. júniusa óta. Évente két alkalommal, júniusban és novemberben érkezik a legfrissebb összesítés. A lista 42. kiadása szerint a Linux szinte teljes egészében, 96,4%-ban uralja a listát. Vagyis, az 500 szuperszámítógép közül 482 operációs rendszere valamilyen Linux.

TOP500.org - 2013. november #2

Az ötszázból mindössze kettőn fut Windows, tizenegyen AIX, négyen egy vegyes, CNK/SLES 9 rendszer és egy rendszert - SUPER-UX - jelöl BSD-alapúnak a TOP500 webes összesítője.

Az első helyen ismét kínai gép tanyázik:

TOP500.org - 2013. november #1

A kínai szuperszámítógép operációs rendszere Kylin Linux. Részletek a bejelentésben.

( anr | 2013. 11. 19., k – 11:40 )

Az IBM-esek morogtak, hogy a Tianhe-2-nel az egymastol fizikailag tavol levo nodok kozott az adattovabbitas ideje joval nagyobb, mint az IBM-es gepeknel, szerintuk ezt a mert szamitasi teljesitmenyt a Tianhe-2 valdi (nem teszt) korulmenyek kozott meg sem fogja kozeliteni.

----
Egyebkent mind az osszesitett szamitasi teljesitmeny, mind az #500. teljesitmenye (ami relative olcson megveheto) nagyon stabilan exponencialisan novekszik (4 evente no 10x-esen)

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

Ilyen gepeknel ez mar implementacio kerdese. Nyilvan arrol se szol a fama, hogy mennyi/milyen gyors storage jar ezekhez, vagy mekkora a kimeno savszel/latency.

A kerdes itt az, hogy ha van egy adott feladat, ami 99.9%-ban cpu-igenyes, akkor mennyi ido alatt futtatja le. IBM-esek moroghatnak, a kriteriumot teljesiti, megpedig valszeg olcsobban :), mint az IBM gepe.

( traktor | 2013. 11. 19., k – 12:50 )

Ez kicsit "Tegnapi ujsag"-nak hangzik, mert a cim akar ez is lehetne:

"A Linux uralja a világ legnagyobb teljesítményű számítógépeit összesítő TOP500 listát már vagy 10 éve"

Már csak a hardver gyártóknak kell szólni, hogy "mukodj" és akkor 64 biten is lesz nyomtatóm, és nem kell gugliznom, ha a csomagkezelőből telepített program nem indul el. Remélem 2014-ben tényleg a Linux desktop éve lesz. :-)

-------------------------------------
Mindenki magától szenved a legtöbbet.

10+ eve van csomagkezelo Windowson:) Igaz, kozponti repo nincs mogotte, de tartomanyi kornyezetben tudsz csinalni azt is, azota meg mar ott a Windows Store is, vagy mi a tokom. Kicsit komolyabb dolgokhoz SCCM es/vagy App-V (App-V-vel pl. meg tudod csinalni azt, hogy egy programot nem gephez kotsz (feltelepited az adott gepre), hanem felhasznalohoz: a juzer barmelyik gepre lep be ott lesz a programja, kulon telepites nelkul (kicsit leegyszerusitettem a dolgot:)).

Erdemes neha kicsit utananezni a dolgoknak, mert teljes bizonyossaggal egetvero faszsagot allitani eleg kellemetlen tud lenni...

Noha igazad van, bennem mégis kérdéseket vet fel, mit ér az az eszköz, amit alig használnak. Többnyire Windows-hoz fellelhető programok esetében még mindig setup.exe-vel találkozom, nem pedig csomagkezelőben kiválasztható alkalmazásokkal, függőség-kezeléssel, digitálisan aláírt csomagokkal. (A pápának is van, csak minek...)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ertem en, hogy a Microsoftnak mindenkepp a kurvaanyjat(tm), de amugy a legtobb setup.exe-ben (vagy valahol a kornyeken) ott az .msi file is, es a setup.exe csak a szines-szagos feluletet adja. Amit msiexec-kel le lehet szedni (egy atlag gepen 95% folotti az arany), az biza hasznalja a csomagkezelot.

> csomagkezelőben kiválasztható alkalmazások

A legtobb program ezen a platformon 3rd party, ugyhogy soha nem lesz ilyen (illetve Windows Store), mert ki a tokom fogja karbantartani ezt az egeszet...?
Elozo kerdesre a valasz: tartomanyban a tartomany rendszergazdai (add or remove programs --> install a program from the network, ez pont ugy mukodik, ahogy szeretned:)

A fuggosegkezeles jogos, de talan kisebb a problema, mert nem valtozik hetente az API (meg ugy barmi), ez nem bazar. A win16 tamogatas is csak par eve unsupported, es kb. a kutya sem hianyolta. Ennek persze folyomanya, hogy bloatware az egesz, de valamit valamiert. Amugy sok helyen talalkoztam mar valamilyen szintu fuggosegkezelessel, kapsz minimum egy linket, hogy innentoltsleteddfel, jobb esetben (a beleegyezeseddel) ez meg is tortenik automatikusan.

Ha gondolod folytathatjuk, de inkabb mashol, mert ez itt kisse off.

a) Fuggosegkezeles: mestersegesen generalt igeny(tm). Erdekes modon, ha letoltok egy Firefoxot Windowsra, akkor nem azzal kell folytatnom a telepitest, hogy a kulonfele liblofaszokat osszeszedegessem, hanem az alkalmazasfejlesztok 99%-a olyan csomagot ad ki, amiben van minen VAGY letolt mindent, ami a programnak kell.
b) digitalis alairas ezer eve megoldott MSI eseten. Gondolom, te is csak mindig nyomtal a tovabbra, mikor a rendszer visitott, hogy valami nincs alairva (mert sokszor a fejleszto nem irja ala).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Akkor mesterségesen támasztott igény, ha nem zavar, hogy akár a C library is minden egyes alkalmazásod részeként telepítésre kerül néhány száz példányban. Persze, aki azzal kezdi, hogy telepítsünk oprendszert alkalmazásokkal egy 2 TB-os HDD-re, azzal nem kezdek erről vitatkozni. (Most raktam össze egy 1.1 GB-os image-be live Linuxot, benne 2 böngészővel, képnézegetővel, képszerkesztővel, video és audio lejátszóval, LibreOffice-szal, Wiresharkkal, kalkulátorral, s így tovább. De azért nyilván mesterségesen generált igény.)

Mindig ellenőrzöm a fingerprintet, amikor a yum importálja a publikus kulcsot. Utána a dolog automatikus. Windows-on a setup.exe-k valahogy nem maceráltak holmi digitális aláírással. Ha a csomag nincs aláírva, az baj. Éppen erről beszélek.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Erre egy picit modernebb alkalmazásfejlesztésre szánt nyelvek (FYI: C nem az) mögött lévő keretrendszerekben egész jól megoldották, pl. Java Class Library, .NET FW, stb., hogy ne kelljen már minden szart újra és újra feltelepíteni.

Másrészt az a potencionális párszáz mega dll, amiből közel sem biztos, hogy azonos verzió van fenn vagy hogy egyáltalán mind ugyanaz, köszöni elfér nekem bőven egy 120G-s SSD-n. Ennyit nekem megér az, hogy biztosan működjön.

"valahogy nem maceráltak holmi digitális aláírással."

O RLY? Ha van és jó az aláírás, mégis minek macerálna? Akkor kell nyafogni, ha nincs, nem akkor, ha van és jó.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Jó dolog is ám a setup->next->next->finish nyomkodása, amíg bele nem botlik az ember abba, hogy nem mindegy, hogy 2 programot milyen sorrendben telepít az ember. Mert pl. mindekttő hoz magával Python-t, de azok fölülvágják egymást, és ha a régebbi vágta fölül az újabbat, akkor nem működik tovább a Mercurial kliens (hogy valós példát említsek). Persze el lehet intézni a dolgot azzal, hogy az alkalmazásírók a hibásak, meg hülye mindenki a HUP-on, aki azt állítja, hogy a Windows-on nincs csomagkezelő.

Bocsánat, félreérthető voltam.

Én használok Windowst is, de mivel havi átlagban kevesebb, mint egyszer futtatok bármilyen telepítőt, így pont hidegen hagy [engem], hogy apt-get vagy setup.exe

A lényeg, hogy mindig lesznek edge case-ek, amik pont nem úgy működnek, ahogy kellene. Windowson is, és Linuxon is. Illetve ha már témánál vagyunk, akkor a Linuxnak is van bőven fejlődni a python, python2, python3 csomagokkal, hiába van csomagkezelő. :)

Hát azt ugye tudja itt mindenki rólam hogy expert Windows-hater vagyok és elvakult Linux-fanboy. De azért azt még én is bevallom, szívenütött, amikor a Goborendszeremet csinálgattam vagy pár hete, from scratch, nagy nehezen fel is izzasztottam rá a Python 3-at, aztán később rájöttem (jó 2 óra Google meg kurvaanyátok-ozás meg más szopások után) hogy szedhetem le a francba, mert maximum a 2.7.5-ös pythont rakhatom fel, ugyanis mással nem megy egy rakás speciális - de gobo alatt létfontosságú - rendszerszkript!

Na most ezt persze el lehet intézni azzal, hogy a Gobo oridzsinál developerjei hülyék voltak, mert hogy a fészkes fenébe lehet épp a legislegfontosabb rendszerszkripteket pythonban megírni! Ha már bash vagy zsh shellben túl nagy szopás, írták volna meg C-ben, hogy max a binutils legyen a függőségük oszt' csókolom. Ha nagyon kell még mellé valami, statikus linkelés, még akkor is azt hiszem kisebb lett volna a szkriptek mérete, mint a komplett python. (Tudom, ha bináris, akkor már nem szkript. Most ebbe ne tessék belekötni). A magam részéről már sok+ éve legelső gobo-találkozásomkor szívemhez kaptam hogy jajistenkémakárholvagyis, ezeknek PYTHON függőség?! Teljesen elfogadhatatlannak tartottam.

Na most azonban hogy a python már a 3-as sorozatnál tart és egy rakás dolog másképp van benne mint a 2-akármicsoda verzióban, méginkább így vagyok ezzel. Igazából attól tartok, ha meggyün majd a 64 bites gépem s arra építek gobót, apránként kidobom a francba a pythonos goboszkripteket, s ami nagyon muszájtatik, azt szívemnek szottya, idesanyám egyetlen de legkedvesebb gyermöke, megírjandjákolja majd a jóöreg fapados C-ben...

Na most mindezzel nem a Linuxot akartam fikázni, istenmencs de még a sátánkaismencsenettű! Ebben nem maga a Linux nevű oprendszer a hibás, hanem az egész ökoszisztéma, a bazár-modell, hogy minden fejlesztő megy a saját feje után, a pythonosok is, akik olyan 3-as sorozatot csinálnak ami nem kompatibilis visszafelé, meg a gobo fejlesztők is akik a létfontosságú rendszerkomponensekhez egy efféle bloatware szart használnak mint a python, s a bloatware cuccok közül is épp egy olyat ami még nem állapodott meg valami normális szintaxisban/interfészben, a fene se tudja mi ennek a neve ebben az esetben.

Persze tudom, hasonló sztorikat el lehetne anekdotázni sok más dologgal kapcsolatban is, de épp ez a dolog veleje: igazából nincsenek szabványok, előírások, szinte csak szóbeszéden alapuló tradíciók léteznek, de még azok is csak alig.

Mindezt figyelembe véve, talán érthető, miért a sima C nyelvet kedvelem a legjobban. Az nem igazán változik olyan nagyon szörnyen. (Sajnos arra se igaz hogy egyáltalán nem. Most ne a K&R-re tessék gondolni e szavaknál, hanem a mindenféle include könyvtárakra...) Változik, de azért az még elviselhető. (tudom, ez szubjektív...) Akárhogyis, de a függőségek a Linux ökoszisztéma legnagyobb rákfenéje, ezzel többet szopik szerencsétlen énmagam de szerintem bármely más ÁtlagJános fejlesztő vagy user is, mint az összes létező akármiféle gonddal együttvéve!

-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről
=== Sabayon disztró, DWM ablakkezelő ===

Erdekes, hogy mashol nem problema, hogy fennlegyen 3 fele .NET, 4 fele java, 5 fele Visual Studio, 6 fele Office, stb.

Na nem mintha, Linuxon megoldhatatlan problema ez. Nagyobbik problema, amikor valami nincs csomagban vagy kokrszaki. Ld. Debian oldstable: postgresql-8.4, slony-i 2.0, Debian stable? Postgresql-9.1 (remek, 9.3-nal tart), slony? ja bocs, azt meg kiszedtek, mert valami faszkalap szerint nem olyan szukseges az. Arrol nem is beszelve, hogy lehet, hogy belefutottunk egy bugba, ami miatt legalabb 2.1-re kellene valtanunk. (2.2-nel jar).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mond ezt annak, aki telepítette a rendszert. Másrészt nem látok se slony-t, se pgagentet. Magyarul még annyira sem lennék előre, mint a mostani debillány stable-vel.

(És köszi, ennél még az is jobb, mint amikro letöltöm az .msi-t és az legalább biztos van és megy.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™