Chrome NPAPI Java helyett, mit?

Hálózatok általános

Ugyan, még működésre lehet bírni, de a 45-ös verziótól az NPAPI protokol tiltva lesz Chrome alatt.
Részletek

Talált már valaki, valami írást, vagy megoldást, a Chrome alatti Java futtatásról a továbbiakban?

  • 7172 megtekintés

( sz332 v | 2015. 06. 07., v – 10:28 )

Szia,

saját alkalmazásod van, vagy valaki másé?

( joco01 v | 2015. 06. 07., v – 10:49 )

Mellesleg annyira vicces ez a szöveg: "we strongly recommend Java users consider alternatives to Chrome as soon as possible."

Arról egy szó se esik, hogy van újabb, jobb, biztonságosabb technológia, csak hát az Oracle-nek ez már nem annyira fontos.

Azt olvastam (https://www.chromium.org/developers/npapi-deprecation), hogy a kódbázisból törlik az egészet.

--

Így marad az XP Mode-ban telepített Java 5, ha már úgyis kell a KIR-nek, meg majd csinálunk egy másikat a Java 6-al a KIRA-nak.
Egyik fórumtársam csomagját használtam jármű műszaki vizsga állomáson, java 6-al, aztán egy nap nem megy, hát úgy mindenféle értesítés nélkül frissítettek 8-asra.

Az Oracle? Ne röhögtess már. A teljes Java SE 9 kiadásra tervezett feature arzenál a desktop/applet oldalnak szól... kliens oldali weben a Java(FX) halott, de még ott ülnek a halott lovon és megpróbálnak kicsit még lovagolni.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ezekről tudok:
102: Process API Updates
110: HTTP 2 Client
143: Improve Contended Locking
158: Unified JVM Logging
165: Compiler Control
193: Variable Handles
197: Segmented Code Cache
199: Smart Java Compilation, Phase Two
201: Modular Source Code
211: Elide Deprecation Warnings on Import Statements
212: Resolve Lint and Doclint Warnings
213: Milling Project Coin
214: Remove GC Combinations Deprecated in JDK 8
215: Tiered Attribution for javac
216: Process Import Statements Correctly
217: Annotations Pipeline 2.0
219: Datagram Transport Layer Security (DTLS)
220: Modular Run-Time Images
221: Simplified Doclet API
222: jshell: The Java Shell (Read-Eval-Print Loop)
223: New Version-String Scheme
224: HTML5 Javadoc
226: UTF-8 Property Files
227: Unicode 7.0
228: Add More Diagnostic Commands
229: Create PKCS12 Keystores by Default
230: Microbenchmark Suite
231: Remove Launch-Time JRE Version Selection
232: Improve Secure Application Performance
233: Generate Run-Time Compiler Tests Automatically
235: Test Class-File Attributes Generated by javac
236: Parser API for Nashorn
237: Linux/AArch64 Port
240: Remove the JVM TI hprof Agent
241: Remove the jhat Tool
243: Java-Level JVM Compiler Interface
244: TLS Application-Layer Protocol Negotiation Extension
245: Validate JVM Command-Line Flag Arguments
246: Leverage CPU Instructions for GHASH and RSA
247: Compile for Older Platform Versions
248: Make G1 the Default Garbage Collector
249: OCSP Stapling for TLS
250: Store Interned Strings in CDS Archives
251: Multi-Resolution Images
252: Use CLDR Locale Data by Default
253: Prepare JavaFX UI Controls & CSS APIs for Modularization
254: Compact Strings
255: Merge Selected Xerces 2.11.0 Updates into JAXP
256: BeanInfo Annotations
257: Update JavaFX/Media to Newer Version of GStreamer
258: HarfBuzz Font-Layout Engine

Ezek nagy része desktop és/vagy JavaFX feature. A maradék nagyobb része komponensfrissítés, illetve kisebb JVM javítások és kozmetikai apróságok, aztán ott a HTML5 JavaDoc fajsúlyú semmiségek, aztán a szerver oldal a PKI dolgokon kívül kap nagyjából semmit. De végigmehetünk lépésről-lépésre.

Neked melyik JEP az, amire 'Aha!' érzésed van, vagyis azt mondanád, hogy már nagyon hiányzott a szerver oldalán, ahol érdemleges a Java előfordulása? :)

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"De végigmehetünk lépésről-lépésre." Akkor már inkább seddel.
[ a következő kódok kattinthatóak ]

Vannak a JEPek, ebből kellenek a 9-esek:
cat jepek | grep " 9 " | awk '{ print $7 " " $4 $5 $6}'

A 23 tools és a '-/-' kategóriájúak vegyesek, a listából kitöröljük:
| sed '/tools/d' | sed '/—\/—/d'

Van 12 HotSpot-related, azokat kiszedjük:
| sed '/hotspot/d' | sed '/performance/d'

6 security JEP, kitöröljük:
| sed '/security/d'

És az 5 tisztán kliensest is (AWT/JavaFX):
| sed '/client/d' | sed '/javafx/d'

A többit meg egyenként:

  • 102 Process API – kliens
  • 110 HTTP2 kliens – vegyes
  • 193 VarHandle – szerver, mert Unsafe replacement, ami meg performance-hoz kellett
  • 226 UTF8 .properties – inkább szerver, de ezen lehet vitatkozni
  • 227 Unicode 7 – vegyes
  • 236 Nashorn Parser API – inkább szerver (pl. ez)
  • 252 Unicode CLDR defaultban – vegyes
  • 254 Compact String – inkább szerver
  • 255 Újabb Xerces – inkább szerver
  • 259 StackWalker – vegyes

    Eredmény:
    - 15 + 8 + 4 vegyes
    - 23 szerver
    - 6 kliens

    "Neked melyik JEP az, amire 'Aha!' érzésed van, vagyis azt mondanád, hogy már nagyon hiányzott a szerver oldalán, ahol érdemleges a Java előfordulása? :)" Na azt nem nagyon tudom, nekem a legkomolyabb tapasztalatom szerver-témában az volt, amikor írtam egy HTTP szervert form upload fogadására, ami gyorsan indult, nem úgy mint a J2EE web containerek :) Viszont először inkább a Java EE-t kéne inkább nézni az SE helyett új szerver feature-ökért.

    • 102 Process API – kliens - pipa
    110 HTTP2 kliens – vegyes - HTTP/2 kliens a kliensen kell
    193 VarHandle – szerver, mert Unsafe replacement, ami meg performance-hoz kellett - pipa
    226 UTF8 .properties – inkább szerver, de ezen lehet vitatkozni - szerver oldalon nagyon rikán van már lang support, ha van, akkor az tervezési hiba, megítélésem szerint ez kliens
    227 Unicode 7 – vegyes - szerintem kliens
    236 Nashorn Parser API – inkább szerver (pl. ez) - kliens, marginális esetben akarnak JS motort szerveren futtatni, a többség kliens oldali
    252 Unicode CLDR defaultban – vegyes - lásd fentebb
    254 Compact String – inkább szerver - ez nagyon határeset, kicsit értelmetlen a jelenlegi memória méretekkel
    255 Újabb Xerces – inkább szerver - szerveren mindenki a saját XML buzeráló cuccát használja, kliensen van értelme az XML buzeráláshoz, illetve a WS kliens használja
    259 StackWalker – vegyes - ez meg kliens oldali VM vizualizáláshoz kell, szerveren nem elemzünk stacktrace-t.

    Eredmény:
    - 15 + 8 + 4 vegyes
    - 23 szerver
    - 6 kliens

    Ez hogy jött ki? Nem jöttem rá a matematikájára... :)

    "Na azt nem nagyon tudom, nekem a legkomolyabb tapasztalatom szerver-témában az volt, amikor írtam egy HTTP szervert form upload fogadására, ami gyorsan indult, nem úgy mint a J2EE web containerek :)"

    JavaEE konténereknek nem az a feladata, hogy gyorsan induljanak, hanem az, hogy gyorsan működjenek, például az undertow, mint Java EE konténer, azért ott van a Top10-ben általában:
    https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=q…

    --
    http://wiki.javaforum.hu/display/~auth.gabor/Home

    "HTTP/2 kliens a kliensen kell" Vagy szerveren, ha egy másik szerverről akarsz adatokat lekérdezni.

    "kliens, marginális esetben akarnak JS motort szerveren futtatni, a többség kliens oldali"
     Mondjuk én a mai napig nem jöttem rá, hogy mi értelme van a Nashorn-nak... Szerver oldali JS-t viszont használnak, ld. node.js.

    "Compact String – inkább szerver - ez nagyon határeset, kicsit értelmetlen a jelenlegi memória méretekkel" Néha heapdumpolok programozkat, elég kevés olyan volt, amikor nem a char[] állt a legfelső helyen, úgyhogy sztem megéri, ha lefelezik a stringek méretét.

    "StackWalker – vegyes - ez meg kliens oldali VM vizualizáláshoz kell, szerveren nem elemzünk stacktrace-t" https://searchcode.com/?q=Reflection.getCallerClass A többségük szerver oldali.

    "Ez hogy jött ki? Nem jöttem rá a matematikájára... :)"
    Szerver: 12 HotSpot + 6 security + 5 core librariesből.
    Vegyes: itt 15 a tools/* kategóriájú, és 8 a többi, mert 23 sor - 15 = 8. A 4 core librariesből jött össze.
    Kliens: 5 AWT/JavaFX + 1 core libből.

    "JavaEE konténereknek nem az a feladata, hogy gyorsan induljanak, hanem az, hogy gyorsan működjenek" Nincs is ezzel semmi gond.

    "Mondjuk én a mai napig nem jöttem rá, hogy mi értelme van a Nashorn-nak..."

    Nashorn-t a JavaFX miatt nyomják, ami böngészőben fut, így lehet JavaFX kódot vegyteni meglévő JS kóddal. A másik gyakori use case a desktop alkalmazásokban az embedded browser, illetve a meglévő JS logika futtatása.

    "Szerver oldali JS-t viszont használnak, ld. node.js."

    Szerver oldalon értelmetlen JS-t futtatni JVM-en... a node.js sem JVM alapú. :)

    "Vagy szerveren, ha egy másik szerverről akarsz adatokat lekérdezni."

    Nagyon ritka use-case, hogy egy szerver egy másikról úgy szerez adatokat, hogy ahhoz HTTP/2 kell, nagyon sok protokoll létezik M2M kommunikációra, a HTTP/2 tipikusan nem ilyen, ezt is a JavaFX miatt tolják ennyire.

    "Néha heapdumpolok programozkat, elég kevés olyan volt, amikor nem a char[] állt a legfelső helyen, úgyhogy sztem megéri, ha lefelezik a stringek méretét."

    Lefelezik egy részét... amiben van egyetlen egy nem ISO-8859-1 karakter, az UTF-16 marad... mobilon fájdalmasabb a memória, de ott ez a JEP nem játszik... de legyen, jelöljük szerver oritentálnak.

    "Szerver: 12 HotSpot + 6 security + 5 core librariesből."

    Ahja... tehát minden szerver, amiről nem tudjuk pontosan, hogy mi... úgy könnyű. A "165: Compiler Control" például miért szerver kategória, amikor tipikusan fejlesztési időben használható feature? :)

    --
    http://wiki.javaforum.hu/display/~auth.gabor/Home

    "desktop alkalmazásokban az embedded browser" A WebView tudtommal nem Nashornt használ, hanem WebKit sajátot.

    "Szerver oldalon értelmetlen JS-t futtatni JVM-en... a node.js sem JVM alapú. :)" Nem is állította senki, hogy JVM-en fut a JS szerveren. (Oké, lehet vitatkozni persze a nyelvtani mondatszerkezeteken. )

    "Lefelezik egy részét... amiben van egyetlen egy nem ISO-8859-1 karakter, az UTF-16 marad... mobilon fájdalmasabb a memória, de ott ez a JEP nem játszik... de legyen, jelöljük szerver oritentálnak." Az UTF-8 tényleg szerencsésebb lenne, de azt meg 1.0-kor kellett volna, nem most ... (és akkor lenne normális code point is, nem ez a mostani char-alapján indexelős) Nem ASCII viszont többnyire csak nem-angol nyelvekben van, bár egy nbsp vagy egy nyíl néhány helyen fájdalmas lehet. Szerintem azért ~75%-ot lehet kompaktan tárolni.

    "Ahja... tehát minden szerver, amiről nem tudjuk pontosan, hogy mi... úgy könnyű. " A HotSpoton kliens oldalon nem kell módosítani túlságosan semmit (csak a startup time-ot kéne, de azt nagyon). Ezért vettem szerver oldalinak.

    "A "165: Compiler Control" például miért szerver kategória, amikor tipikusan fejlesztési időben használható feature?" Valamelyikünk nagyon nem ért valamit... A 165-tel a HotSpot JIT compilert lehet szabályozni, nem a javac-t.

    Amúgy nem kell ennyire irtózni a JavaFX-től. Jó, oké, tényleg ül ott néhány inkompetens (pl. a sw renderinget sikerült gyorsabbra megcsinálni Linuxon, mégis az es2 a default), meg nagyon nincs is felhasználási területe, de legalább a lehetőség megvan, hogy valaki csinálhasson desktop appot Javában. Pl. JVM alapú GUI-s open source hobbiprojekteket mostanában nagyjából mindig JavaFX-ben készítik. (ld. fxexperience)

    "Nagyon ritka use-case, hogy egy szerver egy másikról úgy szerez adatokat, hogy ahhoz HTTP/2 kell"

    Egyelore, de ha a nagyobb adatszolgaltatok (Google, Amazon, Twitter, Facebook) ugy dontenek, hogy API oldalon jojjon a HTTP/2, es szerveren nem lenne elerheto a kliens, az osszes szerver oldali Java fejleszto szaja sirna, hogy miert nincs. A nagy rozsaszin almokkal ellentetben rengeteg M2M kommunikacio zajlik most is HTTP felett (SOAP, XMLRPC, JSON, JSON-RPC, ...), a klienseket meg pont nem erdekli, hogy milyen verzios HTTP-vel szolgaljak ki oket (vagy HTTP-e egyaltalan az a protokoll)

    " A "165: Compiler Control" például miért szerver kategória, amikor tipikusan fejlesztési időben használható feature?"

    Javits ki, ha tevedek, de - az erintett JEP elolvasasa nelkul - a compilert erinto cuccok azok inkabb a vegyesbe kellene essenek, leven kodgeneralas szerver oldalon is tortenik (JSP, ugyebar). Persze abban igazad van, h nem egyertelmuen szerver, de nagyon nem kizarolag kliens.
    --
    Blog | @hron84
    Üzemeltető macik

    Nagyon ritka use-case, hogy egy szerver egy másikról úgy szerez adatokat, hogy ahhoz HTTP/2 kell, nagyon sok protokoll létezik M2M kommunikációra, a HTTP/2 tipikusan nem ilyen, ezt is a JavaFX miatt tolják ennyire.

    Ja, valóban, ugyanis HTTP-t használnak, mert sok stack még nem támogatja a HTTP/2-t. És igen, M2M.

    Hogy a HTTP/2-t a JavaFX miatt tolnák, hát ezzel kapcsolatban erős kételyeim vannak, szerintem marhára tudják ők is, hogy nem csak JavaFX létezik a világon, mint kliens technológia, sőt. És mindegyikhez jól fog jönni. Meg az M2M-hez is.

    Ritka use-case. Bocs, de még mindig röhögök.

    Ööööö... mesélj, milyen újabb technológiát tudna támogatni, amivel a jelenlegi, appletként futó banki kliensek továbbra is változatlanul működnének? Mert ez itt a felhasználó problémája, nem az, hogy majd a 2018-ra kifejlesztendő valamik mit fognak használni - akinek mostanában az applet funkcionalitása kellene, az már egy jó ideje nem java appletben gondolkodik, tehát nincs miről beszélni.

    Ja, és a flash player (ami szintén sechole-októl hemzseg, olyannyira, hogy talán pont most januárban 3 release is volt 1 hónap alatt, mert egyszerre nem is sikerült megtalálniuk az adott hónap összes bugját...), na az vajon miért élvezi a támogatását gugli barátunknak? Ha ennyire a biztonság a fontos, azt miért is nem lehet kikukázni? Ja, hogy akkor mindjárt felhördülne mindenki?

    Technológia alatt a plugin interfészre gondoltam, nem magára a Javára. A Java elvileg platformfüggetlen. Másfajta plugin architektúrán is (PPAPI, NaCl, de még akár HTML5+JS is a vicc kedvéért) lehetne implementálni az applet interfészt, és akkor "a jelenlegi, appletként futó banki kliensek továbbra is változatlanul működnének".

    A Flash Player tudtommal PPAPI-n fut, ami egy sandboxban van. Biztosan abban a Flask verzióban is van bug, viszont a sandbox miatt sokkal kevésbé tud biztonsági hibává válni. Szerintem. Persze a sandboxot is emberek írják, de mondjuk ők jobban értenek a biztonsághoz. De bevallom, nem követem a sebezhetőségek statisztikáit.

    --

    Annyira nem egyszerű a történet. A flash-t lényegében átdolgozták, hogy menjen a PPAPI-val. Amit egyébként a mozilla nem is akar támogatni, és azt hiszem az IE sem. Tehát
    megint az alkalmazásfejlesztők szívnak amiatt, hogy a böngészők nem képesek egységes interface-t nyújtani. Ráadásul nem csak a java a probléma, hanem a játékiparban sokan
    a Unity-t használják fejlesztéshez, az eddig pluginként működött, na, az sem fog menni. A webgl meg kb fele teljesítmény nyújt, ahogy olvasgattam....

    Amit egyébként a mozilla nem is akar támogatni, és azt hiszem az IE sem.

    IE eddig is köszönte szépen elvolt a maga ActiveX-es Flash pluginjével.

    Tehát megint az alkalmazásfejlesztők szívnak amiatt, hogy a böngészők nem képesek egységes interface-t nyújtani.

    És erről megint nagyjából a Nagy Gonosz Cégek tehetnek (régebben: Microsoft, most: kugli), akik fogták az ipari standard szabványt, dobták a francba, és kinevezték a forrásfájuk mindenkori aktuális verzióját szabványnak. (ezt eljátszották az NPAPI-PPAPI-vel, a CSS3 standard-ra nagyjából elég lenne annyit írni, hogy "húzd le a webkit Blink repót").

    A Mozzillától és az MS-től szvsz. teljesen normális hozzáállás, hogy nem állnak be a kugli mögé. Az egyiknél az elvekkel ütközne, a másiknál a release schedule-el, különben ők is hozhatnák havonta az új IE Edget.

    --

    És igen, az NPAPI nagyon múlt évezred és megérett a cserére. Csak ezt lehetett volna azzal kezdeni, hogy összedobnak rá egy szabványt (még ha erre egy év rá is megy), ahol előre meg tudják vitatni, hogy melyik OS felett mi miért lesz lassú/bugos/nembiztonságos/tökömtudja. Vagy intézhet a kugli 1990-es éveket idéző microsoft-módszerekkel is dolgokat...

    BlackY
    --
    "en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

    "Mozzillától és az MS-től szvsz. teljesen normális hozzáállás, hogy nem állnak be a kugli mögé"

    En ertekelem a Mozilla meg a MS ceges erdekeit, meg hogy kiallnak az igazuk mellett, csak ettol en meg nem leszek se szebb, se boldogabb. Magyaran en, mint user pont leszarom, hogy ezt a Mozilla, az MS meg a Google hogyan sakkozzak ki egymas kozott, de az azert erosen turhetetlen kategoria, hogy mindig azok szopjak meg, akik nem tudnak semmit tenni a fennallo helyzet ellen.

    "És igen, az NPAPI nagyon múlt évezred és megérett a cserére. Csak ezt lehetett volna azzal kezdeni"

    ... hogy a harom bongeszogyarto meg a ket nagy plugingyarto osszeul, es kozosen kitalalnak valamit, ami mukodhet helyette. De ez persze csak vagyalom.

    --
    Blog | @hron84
    Üzemeltető macik

    "Másfajta plugin architektúrán is (PPAPI, NaCl, de még akár HTML5+JS is a vicc kedvéért) lehetne implementálni az applet interfészt, és akkor "a jelenlegi, appletként futó banki kliensek továbbra is változatlanul működnének"."

    Lehetne implementálni, de attól még nem működhetne változatlanul. Gyakorlatilag a használhattalanságig növelte a google a PPAPI biztonságát.

    "A Flash Player tudtommal PPAPI-n fut, ami egy sandboxban van."

    A Flash egy olyan sandboxban van, amelyben tud működni, mert ez nem az a sandbox amiben az összes többi PPAPI kiterjesztések futnak. Amennyiben a flash plugin "rendes" PPAPI-ként írták volna újra, akkor tulajdonképpen használhatatlan lenne. PPAPI alatt pl. nem lehet hálózati protokollokat támogatni, vagyis a flash-nek dobnia kellene pl. az rtmp-t.

    A java mellett a másik fájó pont szerintem, hogy chrome nem lesz használható web kamerákhoz, DVR-ekhez, mert ezek meg általában rtsp használják video lejátszáshoz.

    "Elvben arra mar van HTML5 szabvanyka is."

    Nekem az a bajom, hogy (mint írtam) rtsp támogatás kellene, mert a kamerák (pl.: Axis) vagy DVR-ek általában így stream-elik az élő képet. Eddig ezt valamilyen plugin-el (NPAPI) meg lehetett oldani.

    A google az NPAPI helyett behozta a PPAPI-t, amiből lehet 3 féle:
    1, plugin: ilyet tudtommal nem lehet a chrome-hoz telepíteni, mint a NPAPI-s plugin-eket, csak ami "gyárilag" van: pl.: flash
    2, extension: ezt lehet telepíteni, de nem használható benne raw TCP/UDP, vagyis nem lehet implementálni* egy rtsp protokolt
    3, app: itt használható a raw TCP/UDP, de ezt meg nem lehet web oldalba ágyazni, mint az NPAPI-s plugineket

    * Kell hozzá egy rtsp-websocket proxy, csak mint kiderült nagyon érzékeny a chrome lelke, mert ha túl nagyméretű (~2800 byte-osnál nagyobb) csomagokat kap, akkor összef***a magát és lezárja a websocket-et.

    Ő... szerintem a PPAPI az egy plugin architektúra, úgyhogy csak az első pontra érvényes.

    Az extension és az app kb ugyanaz formailag különbözik, és kérhetsz jogosultságot raw socketek használatára, lehet simán akármilyen tcp/udp kapcsolatot létrehozni, még listenerként is tud működni egy kiterjesztés...

    Lásd itt: https://developer.chrome.com/apps/app_network

    Láttam már működő ssh klienst chrome appként, ami nem használ semmi proxyt, úgyhogy gyakorlatban is működik a dolog elég régóta.

    "Én NaCl-es SSH appot használok a Chrome-ban. Szerintem eltérő célokra eltérő API-k vannak, de közelebbről én sem tudom, pontosan mi az architektúra."

    Igen az a 3. kategória, ott lehet. NPAPI kiváltására viszont viszont a 2. pont (vagy az 1.) kellene, mert épp az app-ok újdonságot jelentenek az NPAPI plugin-ekhet képest.

    "Ő... szerintem a PPAPI az egy plugin architektúra, úgyhogy csak az első pontra érvényes."

    Érvényes az mindegyikre. Ugyanabból a forrásból tudsz fordítani plugin-t: .so, .dll, illetve extension és app-okhoz nacl-t: .nexe illetve portolhatót: .pexe.

    Mindegyiket ugyan úgy kell használni: egy <embed> taggal hivatkozol rájuk a html/js oldalán illetve befolyásolod a működésüket.

    A nacl-t crx csomagba rakva fel lehet telepíteni, a portolhatóakat viszont weboldalról is meg lehet hívatkozni, nem kell, hogy telepítve legyen.

    "Az extension és az app kb ugyanaz formailag különbözik, és kérhetsz jogosultságot raw socketek használatára ..."

    Nem kérhetsz extension-hoz raw socket-hez jogosultságot, csak app-hoz.

    "Láttam már működő ssh klienst chrome appként, ami nem használ semmi proxyt, úgyhogy gyakorlatban is működik a dolog elég régóta."

    Igen, azt viszont nem lehet megoldani, hogy készített egy weboldalt, pl. a szervereid listájáról és amikor kiválasztod valamelyiket, akkor azon az oldalon nyílik egy ssh terminál.

    "Igen, azt viszont nem lehet megoldani, hogy készített egy weboldalt, pl. a szervereid listájáról és amikor kiválasztod valamelyiket, akkor azon az oldalon nyílik egy ssh terminál."

    Technikailag de, siman lehetseges ilyet websuket alapokon is csinalni, sot, csinaltak is mar ilyet. Kell egy kis weboldal oldali rasegites, de szol.
    --
    Blog | @hron84
    Üzemeltető macik

    "Technikailag de, siman lehetseges ilyet websuket alapokon is csinalni, sot, csinaltak is mar ilyet. Kell egy kis weboldal oldali rasegites, de szol."

    Igen én is ilyen megoldást csináltam rtsp stream-re.

    Szigorúan véve ez egy websocket alapú ssh kliens, ami valójában épp azt mutatja, hogy nem lehet ssh-t kezelni (csak ws-t).

    Ilyen alapon persze az is megoldás, hogy parancssori kapcsolóval engedélyezed a socket használatot akkor valódi ssh-t is tudsz csinálni. Csak azért ez nem az a kategória, hogy feltelepül egy NAPI plugin és használod a szolgáltatásait, mert ez házon belül működik, de felhasználóknak nem lehet kiadni (max csinálsz egy telepítőt ami lecseréli a pl.: chrome.exe egy sajátra, ami mindenféle kapcsolókkal elindítja a valódi chrome-ot, hogy terjeszthető legyen egy NPAPI-ról PPAPI-ra portolt plugin).

    Eleg a parancsikont megmokolni, csinalsz egy chrometuner.exe-t, amihez hozzacsapod hogy meg az orodat is tiszticcsa, es ezrevel fogjak tolteni a nepek :-) Mukodik? Mukodik. #troll

    Egyebkent persze, ertem en a problemat. Megmondom oszinten, baromira utalom az osszes bongeszot, valogatas nelkul, mert nincs olyan, ami ugy mukodne, mint a Sokol radio, hogy bekapcsolom, es szol, mindig beleszaladok valami olyanba, ami eppen akkor, eppen ott nem mukodik, es folyamatosan a gepen kell tartanom 2-3-5 bongeszot, hogy hatha az egyik a mukodes mellett szavaz.
    --
    Blog | @hron84
    Üzemeltető macik

    ( _Franko_ v | 2015. 06. 07., v – 15:10 )

    "Talált már valaki, valami írást, vagy megoldást, a Chrome alatti Java futtatásról a továbbiakban?"

    NaCl plugin kellene, de az Oracle úgy gondolja, hogy nem dolgozik a Google keze alá, inkább megpróbálja a statisztikai hibahatár alatti desktop felhasználókat más böngészőre átterelni... kicsit iszapbirkóznak a sárban, aztán lesz valahogy, szerintem lesz NaCl plugin... :)

    ...az eddigi Java plugin felhasználók meg majd gőzerővel migrálnak HTML5-re.

    --
    http://wiki.javaforum.hu/display/~auth.gabor/Home

    Pont akkor volt egy JDK -> OpenJDK váltás és sok dolgot újra kellett implementálni, illetve sok com.sun.* csomag és/vagy osztály eltűnt szerzői jogok miatt, amire korábban építettek (nem feltétlen helyesen, de működött).

    --
    http://wiki.javaforum.hu/display/~auth.gabor/Home

    Most, hogy JAVA-Flash miatt ismét "válaszút" van, újranéztem a legutolsó Chrome verziót, - egyébként soha nem használtam ezt az "adathalász" böngészőt!, - (Most 32 bites W10-en "játszottam" vele néhány napot..)

    Meg kellett állapítanom, helyesen tettem, hogy soha nem használtam. Bár tényleg gyors, de semmit nem támogatott, ami nekem valaha fontos volt a böngészéseknél. Normális, használható bookmarkot, rendesen használható reklám-blokkereket, video-zene letöltő plugineket. Pedig "végigbogarásztam" a GPlay-t ilyenek után, ki is próbáltam jónéhányat. (Nem is értem, hogyan tudott használni valaki ilyen fapadot?)

    Sok működésképtelen megoldás viszont van ezekre. Windows 10-en, volt olyan oldalam, - le kellett töltenem a PdfCreator-t, - szégyenszemre el kellett indítanom a IE11-et, hogy meg tudjam tenni vele, mert a Chrome semmiképpen nem volt rávehető. (Biztosan óriási biztonsági kockázatot vállaltam volna vele...!

    Ez van, amikor egy cég "lefekszik" a mozi-zene iparnak, a szerzői jogi démon-kergetőknek. Használhatatlanná válik.

    Ezek alapvetően felhasználó szempontok. De egyet nem kéne szem előll téveszteni, biztonság ide vagy oda, a felhasználók le*/**sa nem a legjobb felfogás a fejlesztők részéről. Igaza van az Oracle-nak, hogy nem ugrik a Google "bekeményítésére". Gondol azokra, akik nem kívánnak G birodalom egyedülálló kódjai közé "veszni". Mert az a biztonság amit a G annak tart, nem biztos, hogy a felhasználóknak is használható biztonság.

    A Sun később Oracle JRE mindig megtalálható volt a gépeimen, Windows-on, vagy Linuxon, soha nem volt ebből egy felhasználó számára is érezhető biztonsági probléma. (Amit viszont rendszeresen éreztem, az általában vett gördülékenyebb böngésző-rendszer használati lehetőség. (Ti. azok a bizonyos oldalak is működtek, amelyek esetleg igényeltek "JAVA-motort".)

    Ezzel szemben a Fox-nál soha nem ütköztem akadályokba ezeket illetően, ráadásul 3-4 platformon használhattam mindent ugyanúgy. Nagyszerűen menthető "offline", és vissza is tölthető, platformok között is. Nem kellett attól rettegni, hogy mikor teszi használhatatlanná egy "rátólt" frissítés. Némiképp lassabban mozog? Ezzel 20-30 plugin-nél együtt lehet élni.

    Baj akkor lesz, ha mégis a Mozilla hal ki először. Erre sajnos reális esély van. (Az Opera is - valószínüleg közvetve az is a G. miatt, - "kiszenvedett" már az életemben, azt is nagyon sajnáltam akkor. - Szerencsére a Netscape-nél még nem voltam érintett.)

    Egyszerűen nem értem, ha pl. az egész böngésző "jail"-ben futna az alátükrözött rendszerben, mit kell itt aggódni a plugin-architektúra biztonsági kockázataiért? Ha "rés" van, akkor azt be kell foltozni, akármilyen új szabvány szerint működő szoftvereknél is.

    Miért..., az, hogy a G hetente frissíti a böngészőjét, mindent összevetve és gyakorlati szempontból, kevesebb biztonsági kockázattal járt, mint az IE v. más böngészők hatványozottan ritkább változtatása?

    Ha jól visszagondolok, nekem többször okoztak gondot frissítések, mint a változatlanság miatti, azaz ez idő alatt feltárt, biztonságirések okozta "kiszolgáltatottság".

    Valahogy teljesen elkerült a Chrome-láz. Mindíg is Firefox-ot használtam, egy-két oldal kinyitására IE. Van Sandboxie is.

    Amiért az IE-t útálom az a memóriahasználata. Edge és Chrome nagyjából ugyanúgy néz ki ebből a szempontból.
    Lehet hogy valaha jó volt a Chrome de az utóbbi időben mikor felhasználó jön és panaszkodik hogy nézd, "low memory" és meglátom a Chrome-ot, rögtön tudom hol kell kezdeni a "hibakeresést".

    Ez már itt sokaknál biztosan kiveri a biztosítékot..., sok hozzámkerülő, (de biztosan nem fejlesztő v. szakember.!) felhasználó gépén, aki Windows alatt Chrome-ot (is) használ, sokkal nagyobb a valószínűsége a 1000 feletti malware találatnak, mint aki szépen nélkülözi ezt a hetente gyúrt "csodát", - (pl. Fox-ot használóknál vagy esetleg csak megrögzött IE felhasználóknál...)

    Tapasztalat, és nem önmagában a Chrome a ludas ebben, - hanem sztem. a "bátor", "innovatív" módon szörföző Chrome-felhasználók. (Szakértő kézben biztosan nem roszabb ebből a szempontból... :-) )

    https://www.flickr.com/photos/132370074@N08/20809910542/in/dateposted-p…

    Mindenkinek Fox-ot telepítek, (..ha valaki agresszívan követeli a Chrome-ot..., az majd magától, egy kattintásra úgyis feltelepül...)

    Ha valaki képes arra, hogy az általam mindig telepített 3 blokkert a Fox alatt használni tudja, (Ghostery, Noscript, Adblock (with hufilter!) - akkor azért ilyen "screen"-t nem tudok arról a gépről készíteni biztosan. (Még akkor sem ha a Fox 1 évig nem lesz frissítve...)

    Attol, mert a Chrome ala nem teszed fel a 3 blokkolot, csak Fox ala, meg nem a Chrome a hulye... Ja, de hat mindenkepp le kell jaratni a Chrome-t, akkor tegyuk minel hatekonyabban!

    En tobb alapszintu Chrome usert ismerek, es nincs tobb virus/malware a gepukon, mint Chrome elott.
    --
    Blog | @hron84
    Üzemeltető macik

    Ez egyéni véleményem, a tapasztalataim alapján. - Nem a Chrome-ot, mint böngészőt hibáztattam. A Chrome-ot előnyben részesítő felhasználókra utaltam. - "Avatott" kezekben nem kétlem, hogy ugyanolyan eséllyel lehet "hiba" nélkül böngészni Chrome-mal vagy Fox-al is, stb.

    Az egyszerű, zavaró elemktől mentes használhatóság, ami első ránézésre sajátossága a böngészőnek, sugalja azt, hogy a részletek nem fontossak. A türelmetlen, sebességmániás, egy eszköz használatának tanulásra időt nehezen szánó típusú felhasználóknak ez azonnal bejön.

    Ráadásul mivel kezdetektől nem volt jól használható bookmark-ja, (nem is volt fejlesztési cél, mert nem volt összegyeztethető a G. üzletpolitikájával,) ezért a "kereséssel találj meg mindent gyorsan" felfogás, "megteszett" a rendszerezésre nem hajló, saját memórizálást előnyben nem részesítő, végső soron nem gondolkodó, felhasználó tömegnek. (Magyarán, gyorsan "benyalták" a telepítést.)

    Na most, elsősorban ők hajlamosak malware-okat, toolbar-okat is tömegesen beszedni. Nem az óvatos, megfontolt, hozzáértő felhasználók. Megfigyelésem szerint ők nem is szeretik a Chrome-ot annyira feltenni, mert alapból nem fogadták el, már a telepítésének erőszakos módszereit sem. (De biztosan van, "kivétel erősíti a szabályt történés is.)

    "Normális, használható bookmarkot, rendesen használható reklám-blokkereket, video-zene letöltő plugineket. Pedig "végigbogarásztam" a GPlay-t ilyenek után, ki is próbáltam jónéhányat. (Nem is értem, hogyan tudott használni valaki ilyen fapadot?)"

    Meg is nézted a böngészőt, vagy két perc keresgélés után feladtad? Ugyanolyan adblock van chrome alá, mint firefoxra, abból is többféle, lehet válogatni. Gplay? Miről beszélsz? Videó és zeneletöltésre ne használj plugineket, esetleg kiterjesztéseket. Utóbbi meg van szépszámmal, bár bevallom nem értem minek, amikor van pwntube, nem kell hozzá semmi.

    "Ez van, amikor egy cég "lefekszik" a mozi-zene iparnak, a szerzői jogi démon-kergetőknek. "

    A chrome eleve úgy indult, hogy egy minimál böngésző, nem a testreszabhatóság volt a lényeg, hanem hogy egyszerű és gyors legyen. Ezzel szemben mindenki azért fikázza (az adathalászaton túl), hogy nem testreszabható. Mégis mi bajuk az embereknek? És hogy a fenébe jön ide emiatt a zeneipar? Mégis milyen lefekvésről beszélsz?

    Nem tudom, nézted-e már az Adblock kivétel-listáját? - Egyébként tényleg kettő használhatónak tűnőt találtam..., - be is tettem mindkettőt, :-) De még mindig közelébe nincs annak a hatékonyságnak mint a Fox említett "hármasa".
    (és alaposan végégnéztem, ha persze pár órai keresést annak lehet nevezni, de az átalagfelhasználó még ennyi időt sem szán rá.)

    A Windows-os Chrome-ban való youtube-os, stb. letöltés minek is? Mert szoktam pl. tutorialokat eltárolni. Persze megoldható, - körülményesen. A mentés alatt-után meg a Chrome megmorcol!?! - Átvált pl. iPad nézetű lejátszásra, megáll a lejátszás, stb. Fox-nál soha nem tapasztaltam pl. Save Nethelper mellett. (Kényelmesen kiválasztom a legnagyobb lehetséges felbontást, és már jöhet is.)

    A szerzői-jogi téma, meg úgy jön ide, hogy a publikus, (internetes anyagok) lejátszások olyan különféle korlátozásait soha nem tudtam elfogadni, amelye arra irányulnak, hogy ne tudjam tetszés szerint megtekinteni, az egyébként mindenkinek rendelkezésre álló, célzatosan, az alkotók által megtekintésre létrehozott tartalmakat.

    De a G ezt sokszor másként gondolja, pedig ő csak a közvetítő médiát biztosítja. A reklámözön elkerülésére kódolt pluginek működését meg gyakorlatilag más, sokféle módon korlátozza. (Többek között a gyors főverzió váltásokkal is, a plugin-architektúra váltás, azaz Flash-JAVA korlátozás, stb. A felhasználók szivatását meg "biztonsági" okokkal meg is indokolja.)

    PwnTube (felhős, - nem ismertem eddig, - gondolom, mint a Pocket, ezt ha lehet, használom én is, de az én "világomban" nincs mindig jó, vagy egyáltalán valamilyen internetkapcsolat.)

    "A chrome eleve úgy indult...," - fejlesztők úgy használják, ahogy jó nekik. Ezzel semmi bajom. A Chrome azonban átment az átlagfelhasználók kezébe, - többek között a "jellegzetes" terjesztési módszernek köszönhetően is, - egy véletlen kattintásra egy pillanat alatt települ, annak is, aki nem is akarta. És az alapértelmezett böngésző jogait is bekéri magának, kiszolgáltatva ezzel a hozzá nem értő felhasználó gépét.

    "PwnTube (felhős, - nem ismertem eddig, - gondolom, mint a Pocket, ezt ha lehet, használom én is, de az én "világomban" nincs mindig jó, vagy egyáltalán valamilyen internetkapcsolat.)"

    Na itt álljunk meg. Mi az, hogy "gondolom"? Ne gondold, nézd meg. Egy sima weboldal, aminek bedobsz egy youtube linket, és ad cserébe linkeket, amiről közvetlenül letöltheted az mp4 fájlokat. Nem felhős, nem olyan, mint a Pocket. Semmivel nem másabb, mint egy kiterjesztés, csak ez szerveroldalon oldja meg a munka nagyrészét, te csak egy videófájlt kapsz...

    A fenti megnyilvánulásodból nagyon az jön le nekem, hogy te nem nagyon nézed meg a dolgokat, csak véleményt alkotsz látatlanban.

    Na és akkor most válaszolok a többi pontodra, de nagyon sok helyen sántít amit írtál:

    "Nem tudom, nézted-e már az Adblock kivétel-listáját? "

    Ő, fogalmam sincs miről beszélsz, én egyszer letöltöttem EGY adblock kiegészítőt, ami azóta tökéletesen működik, reklámot ritka esetben látok, azt is el tudom tűntetni. Milyen listát kellett volna látnom?

    "A Windows-os Chrome-ban való youtube-os, stb. letöltés minek is?"

    Nem kérdőjeleztem meg a letöltés szükségességét, azt kérdőjeleztem meg, hogy ehhez minek neked külön plugin? (Kérlek ne pluginekről beszélj, amikor extensionre - böngészőkiegészítőre gondolsz). Ahogy a pwnyoutube-ról is kiderült egy sima weboldalról le tudod ezeket szedegetni, nincs szükség rájuk.

    "De a G ezt sokszor másként gondolja, pedig ő csak a közvetítő médiát biztosítja. A reklámözön elkerülésére kódolt pluginek működését meg gyakorlatilag más, sokféle módon korlátozza."

    Ő, mik ezek a módok? Kicsit elvesztettem a fonalat. Ahogy írtam fentebb, van tökéletesen működő adblock, évek óta használom, nem korlátoz semmit sem a google. A flash sem volt korlátozva soha sem, automatikusan része a chrome-nak.

    ""A chrome eleve úgy indult...," - fejlesztők úgy használják, ahogy jó nekik. Ezzel semmi bajom. A Chrome azonban átment az átlagfelhasználók kezébe, - többek között a "jellegzetes" terjesztési módszernek köszönhetően is, - egy véletlen kattintásra egy pillanat alatt települ, annak is, aki nem is akarta. És az alapértelmezett böngésző jogait is bekéri magának, kiszolgáltatva ezzel a hozzá nem értő felhasználó gépét."

    Hűbasszus... 1) Hol települ véletlen kattintásra annak a chrome, aki nem akarja?? Jesszusom, miről beszélsz? Az alapértelmezett böngésző jogait minden böngésző bekéri magának, ez nem tűnt még fel?

    > Hol települ véletlen kattintásra annak a chrome, aki nem akarja

    Letöltesz valami másodrangú freeware vackot (másodrangú != népszerűtlen), aminek a terjesztője némi plusz zseton reményében úgy csomagolta be a Chrome-ot az installerbe, hogy az default feltelepül, csak körülményesen lehet megakadályozni a telepítését.

    Nem a Chrome hibája, a felelősség a fejlesztő/disztibútor és a Google közt oszlik meg. A Chrome, mint szoftver, valóban nem tehető felelőssé.

    > Eleve nem töltök le másodrangú freeware vackokat, az oprendszeremnek van rendes csomagkezelője, ahol nem települnek felesleges extra szar egy programmal

    Linuxon talán nem lehetne megoldani, hogy teleszemeteljenek egy rpm-et? Azt hittem, az egy fejlett oprendszer, amiben sok dolgot meg lehet csinálni. Miért az OS hibája, ha egy telepítőcsomagban crapware van?

    "Linuxon talán nem lehetne megoldani, hogy teleszemeteljenek egy rpm-et? Azt hittem, az egy fejlett oprendszer, amiben sok dolgot meg lehet csinálni. Miért az OS hibája, ha egy telepítőcsomagban crapware van?"

    Nem minden történik meg, amit meg lehet csinálni. Szeritem az egyik faktor, hogy még nem találkoztam ilyennel a mentalitás: Nem igazán teszik meg ezt a disztribútorok. Másrészt a csomagok terjesztésének a módja. Alig van valami, amit kézzel letöltött csomagból telepítek fel. Ott vannak az Ubuntu hivatalos tárolói, miért akarnék én azzal szórakozni, hogy rpm-eket (debeket) töltögetek le? :)

    Persze így is van amit kénytelen az ember letölteni. Ezektől jellemzően ódzkodok is. Az a néhány alkalamzás, amit külső forrásból telepítek az pedig megbízhatónak bizonyult a tapasztalatok alapján ezen a téren. Az igazság az, hogy ezen alkalmazások windows-os verziója sem igazán szemetel...

    Szóval látod, meg lehetne tenni, mégsem történik. A gyakorlat az, hogy itt van előttem egy Ubuntu, fel van telepítve egy csomó alkalmazás, Ubuntu tárolóból is, külső tárolóból is, 1-2 deb-ből is, és mégsincs semmi olyan felrakva, amit nem én akartam.

    > Szeritem az egyik faktor, hogy még nem találkoztam ilyennel a mentalitás

    Pontosan ezt mondom én is: nem az OS hibája, hanem a freeware vendoré.

    > A gyakorlat az, hogy itt van előttem egy Ubuntu, fel van telepítve egy csomó alkalmazás, Ubuntu tárolóból is, külső tárolóból is, 1-2 deb-ből is, és mégsincs semmi olyan felrakva, amit nem én akartam.

    Nekem Windows-om van, fel van telepítve egy csomó alkalmazás, a Windows Store-ból is, és külső forrásból is, és mégsincs semmi olyan felrakva, amit nem én akartam. A vendorok próbálkoznak, legfeljebb nem használom a vackaikat.

    Hát van néhány. A "minél több vírusirtó van a gépen annál jobb"-gondolkodású userek kedvence, az Avast, pl. hozza magával a Chrome-ot. A Piriform összes szoftvere (Defraggler, CCleaner, stb.) hozza magával a Chrome-ot. Rengeteg más szoftver telepítője hozza magával a Chrome-ot, néha nyíltabban, néha kicsit sunyin.

    szerk: És a legszebb, hogy a "szakmai" újságírók szerint ez pozitívum

    En vettem valami masodrangu oprendszert, Windows a neve, es a terjesztoje ugy csomagolta be az Internet Explorert a telepitobe, hogy default feltelepul, es csak korulmenyesen lehet megakadalyozni a feltelepuleset.

    A kovetkezoket gondolom:
    1) ezert nem lehet egyik felet sem hibaztatni. Hibas a freeware terjesztoje, mert penzt akar a munkajaert? Hibas a Google mert terjesztene a bongeszojet? Jo, nyilvan a modszer hagy kivannivalot maga utan, de akkor ez szoljon a modszerrol, ne a cegekrol.
    2) a bongeszoterjesztes nem a freeware-k privilegiuma
    --
    Blog | @hron84
    Üzemeltető macik

    Egy átlagos desktop Linuxban is van OOTB böngésző, hol itt a gond? Az oprendszerben legyen böngésző. Pont. Az egységsugarú user name akar wget-tel netezni, sőt, senki sem, aki nem teljesen autista.

    My two cents:

    > ezert nem lehet egyik felet sem hibaztatni
    De, lehet.

    > Hibas a freeware terjesztoje, mert penzt akar a munkajaert?
    Ügyes kiforgatása a szavaimnak, természetesen nem. Azért viszont hibás, hogy ezt mi módon teszi. Csomagolhatna mellé ransomware-t is, hiszen az még több pénzt hozna. Vagy kiadhatná a vackait freemium modellben. Vagy elkezdhetne pénzt kérni az alkalmazásért. Vagy akármi.

    > Hibas a Google mert terjesztene a bongeszojet?
    Ügyes kiforgatása a szavaimnak, csapó kettő. Nem. Nem ezért hibás.

    > de akkor ez szoljon a modszerrol, ne a cegekrol.
    A mondandóm a módszerről szólt egész eddig.

    > a bongeszoterjesztes nem a freeware-k privilegiuma
    Így ne terjesszünk semmit. Akkor inkább tegyük kötelezővé minden oprendszeren a böngészőválasztó képernyőt.

    "Egy átlagos desktop Linuxban is van OOTB böngésző, hol itt a gond?"

    Tbh a Linux nem feltetlen telepit alapertelmezesben bongeszot, a DE-knek nem default fuggosege egy bongeszo (nem valnak uzemkeptelenne csak, mert nincs bongeszo a gepen). Even more, a Linuxrol nyomtalanul eltavolithato barmilyen random bongeszo, ami a Windowsrol nem mondhato el (probaltal mar nyomtalanul eltavolitani IE-t?). Szoval itt azert van csusztatas rendesen.

    "Így ne terjesszünk semmit. Akkor inkább tegyük kötelezővé minden oprendszeren a böngészőválasztó képernyőt."

    Ugyes kiforgatasa a szavaimnak. En nem feltetlen vagyok a terjesztes ellen, lsd bizonyos ertelemben megvedtem a freeware gyartot is. Amit en szeretnek, az az, hogy egy bongeszo ne legyen integrans resze egy oprendszernek (vagy egy random barmilyen szoftvernek), lehessen eltavolitani ugy, hogy nem maradnak vissza itt-ott meg maradvanyai.
    --
    Blog | @hron84
    Üzemeltető macik

    > Tbh a Linux nem feltetlen telepit alapertelmezesben bongeszot
    Igen, direkt ezért emeltem ki, hogy alapvetően desktopról van szó.

    > nem valnak uzemkeptelenne csak, mert nincs bongeszo a gepen
    Ez technikailag igaz, üzemképtelenné tényleg nem válik, csak mindennapi használatra alkalmatlanná.

    > probaltal mar nyomtalanul eltavolitani IE-t?
    Nem. Annak mi értelme van? Egyébként el lehet.

    Nem. Annak mi értelme van? Egyébként el lehet.

    vs

    Because the Internet Explorer browser is implemented in Shdocvw.dll, the version of this DLL can be used to determine which version of Internet Explorer is installed.

    Forrás

    Explorer.exe has failed to start because SHDOCVW.dll was not found.

    Forrás

    "Te nem nagyon nézed meg a dolgokat, csak véleményt alkotsz látatlanban" - Azzal kezdtem, nem ismerem!

    Igen, vannak dolgok, ahol valóban így működik a gondolkodás, mert már megelőzően annyi hasonló információt gyűjtöttem, annyi tapasztalat felhalmozódott, hogy az ember következtet azokból, egy még nem ismert esetre. De, azért, ha nem is "felhős" szolgáltatás a PwnTube, a lényegét így is megsejtettem, számomra nem "bejövős". Miért is szánnék rá időt? (Vannak árnyoldalai is az ilyen következtetéseknek. Ez a módszer valóban, csak ritkán és megfontoltan alakalmazható. Általában én is szeretek utánna olvasni a dolgoknak.

    Tehát ismét nekifutok: PwnTube-ot nem néztem, mert minek közvetítő plusz weboldal, ha már egyszer a gépemen a cache-ben a video, - (v. esetleg megjelenik stream formájában.) Ott van, akkor én már elvárom a böngészőtől (v. kiegtől), más szoftvertől, hogy határozottan, gyorsan leszedje. Nem "csípem" a "mi külön szedjük csoportosítás és adatgyűjtés szempontjából a felhasználókat" elvet.

    Kétségtelen a Pocket is így működik. De, ha a használhatóság szempontjait tekintem, nincs jobb alternatíva. - (Ti. egy bizonyos feladatra felkészülök, és előtte olvasott anyagokat, képes vagyok,- adott esetben demonstratív célból, - egyszerűen, gyorsan félretenni, erre tényleg jó, természetesen így is tudatában vagyok, kiszolgáltatom magam "valamiféle" adatgyűjtésnek. De konkrét, időben, korlátozott célból, - ez még talán elfogadható.)

    Az Adblock "kivétel listája" tartalmazza azon cégek sorát, - olvasható a beállításokban, (egy tetemes lista), - amelyek fizettek azért, hogy a reklámjaikat az Adblock ne korlátozza.

    ( Som-Som | 2015. 08. 24., h – 10:11 )

    A Java appletekről 10+ éve tudjuk, hogy halottak. A Flash halálát kb. 5 éve maga az Adobe jelentette be és a HTML5-re való áttérést javasolta (a saját tooljai segítségével). Amelyik cég vagy intézmény mégsem volt hajlandó váltani, az nehezen értelmezhető másként, mint szándékos cselekedet és a technikai vezetőjük megítélése is eszerint történhet.

    De azért az tény, hogy 3 milliárdnál is több JAVA-t futatni képes eszköz van a világon, és a Flash szintén elterjedt formátum. Ez kevés ahhoz, hogy ne zárjuk ki a felhasználóikat? (feltehetően és alapvetően IT-s "gigászok" konkurenciaharcai miatt...) a mindennapi feladataik végzéséből vagy a szórakozásaikból.

    Tudom az ActionScript zárt, előszerettetel hivatkoznak a javítatlan biztonsági réseire, de esélyesnek tűnik, hogy egy HTML-5-ös böngésző videólejátszó képessége, legalább annyi biztonsági problémát jelenthet a jövőben, mint akár egyik, akár másik "kínpadra feszített" jelenleg elterjedtebb megoldás. (De akár így lehet ez az esetleg az Oracle JAVA-t kiváltó, openJDK-s, vagy más programozással is.)

    Etéren inkább Linus gondolkodásával értenék egyet, aki amikor egy kernel-összetevő kiírásáról döntött volna, de hírét vette, hogy valaki még használ a támogatást igénylő eszközt, végül a benthagyásról döntött.

    > 3 milliárdnál is több JAVA-t futatni képes eszköz van a világon

    Ennyi erővel az x86 kódot futtatni képes eszközök miatt meg azt mondhatjuk, hogy legyen NaCl mindenhol.

    > Flash szintén elterjedt formátum.

    Mondjuk inkább úgy, hogy annak ellenére nyomnak benne tartalmakat, hogy mindenki tudja, hogy halott. Ez olyan, mintha valaki magnó kazettákat nyomna ma is ezerrel, mert elterjedt. Ettől még marhaság marad.

    > HTML-5-ös böngésző videólejátszó képessége, legalább annyi biztonsági problémát jelenthet a jövőben, mint akár egyik, akár másik "kínpadra feszített" jelenleg elterjedtebb megoldás.

    A videó nem attól lesz biztonságos, hogy Flash vagy HTML5. Egyrészt a biztonságot segítő architektúra, pl. sandbox/konténer, jogosultságkezelés, másrészt a felfedezett biztonsági rések gyors kijavítása segíthet.

    > hírét vette, hogy valaki még használ a támogatást igénylő eszközt, végül a benthagyásról döntött

    Csak nem mindegy, hogy mekkora árat kell fizetni érte. Van, amit nem fáj megtartani, van, ami hazavágja az egészet: http://news.softpedia.com/news/Linus-Tolvalds-Keeps-Code-in-the-Kernel-…

    Ez örök probléma lesz. Pl. visszamehetünk az "őrizzük meg az X86 kompatibilitást a PC-s prociknál vagy sem" dilemáig. Az Intel sem merte meglépni és jó oka volt rá. Én inkább a kompatibilitást megőrző fejlesztőmunkára szavaznék. (A kiöntött fürdővizzel rendszeresen kifolyik a gyerek is.) A munkát végzőknek sokszor kegyetlenebb, munkaigényesebb, a szoftvert használóknak könnyebb lesz. (Tudom, ez az a bizonyos "csalányos" történet...)

    > Az Intel sem merte meglépni és jó oka volt rá.

    Akkor az iAPX 432, i860, i960, StrongARM és XScale vajon mik?

    > Én inkább a kompatibilitást megőrző fejlesztőmunkára szavaznék.

    A kompatibilitás rendkívül fontos, valószínűleg ezért maradtak sikertelenek az Android készülékek és mindenki x86 alapú MS-DOS telefonnal szaladgál. És a kompatibilitás megtartása miatt fut a Macintosh még mindig Motorola CPU-kon.

    A kompatibilitás valóban nagyon fontos, de megfelelő módon simán lehet szakítani vele. Web alkalmazások esetén a kliens részt esetleg újra kell írni, a lényeg viszont külön életet él, aminek szintén megvannak a maga technológiai váltásai, de rejtve a felhasználók elől.

    "kompatibilitást megőrző fejlesztőmunkára szavaznék"

    Ezzel csak egy gond van, napi szinten szunnek meg fejlesztoi csoportok, szoftverek maradnak tamogatas nelkul, es nem minden szoftvert trivialis kivaltani egy masikkal - emiatt fontos az, hogy a platformok addig maradjanak kompatibilisek, ameddig ez technikailag lehetseges.

    Ugyanez a problema buborekol fel a Java Appletek kapcsan, a tobbseg kivagna a francba, de nagyon sok olyan banki sw van, ami appletet hasznal, es nincs lehetoseg mast hasznalni helyette.
    --
    Blog | @hron84
    Üzemeltető macik

    Ez nem az a kategoria, hogy egy bank ugy dont, hogy hat akkor veszunk/fejlesztetunk egy masik szoftvert. Eleve, egy banki szoftver megalkotasa 1-2 eves munka, alaphangon. Azutan a ket rendszer hosszu evekig kell egymas mellett uzemeltetni, a jelenlegi rendszert ugy atalakitani, hogy mindket rendszerben leusse a valtozasokat, majd fokozatosan kivezetni a regi szoftvert. Ezen felul kepezni kell az embereket, hogy mit lehet az uj rendszerben megtenni, mit kell meg a regiben, mit kell adott esetben mindkettoben rogziteni.

    Egy banknal a legtobb esetben nem szoktak "ugy donteni", hogy lecserelik a meglevo szoftverparkot.
    --
    Blog | @hron84
    Üzemeltető macik

    Szerintem ez a bankok tipikus belemagyarázása, ami inkább bullshit. Megfelelő szakértelemmel meg lehet csinálni egy átállást zökkenőmentesen. Vannak a bankoknál nagyobb cégek, és bonyolultabb rendszerek, nem kell ezt túlmisztifikálni. Évekig nyújtani, mint a rétestésztát, meg egyszerre két rendszert üzemeltetni, az a bénázás tetőfoka. Amúgy valamennyire ráláttam, hogy ez a bénázás sajnos a valóság egyes helyeken, és félelmetes szinteket képes ölteni. De csak azt mondom, hogy ezt mégse kellene normálisnak elfogadni.

    --

    "meg egyszerre két rendszert üzemeltetni, az a bénázás tetőfoka."

    Bar nehez rolam elkepzelni, de dolgoztam banknal uzemeltetokent, es pont nem sokkal mielott eljottem, vagtak bele egy cserebe, egyszeruen mert mar nagyon kioregedett az infra alatta (akkoriban jott ki az Oracle RDBMS 11g asszem, mi 9-essel toltuk ugy, hogy az mar egyszer upgradelve lett talan 7-esrol(ha volt ilyen), es mar akkor sem volt tamogatva).

    Ezek az intezkedesek nem azert vannak, mert toketlen uzemeltetok dolgoznanak a bankoknal, hanem a tevhitekkel ellentetben a bankok eleg komoly felelossegvallalasokkal rendelkeznek, es a legtobb intezkedes rajuk van kenyszeritve, nem az o sajat hataskoruk, hogy mit hogy inteznek. Csak ahhoz, hogy a MasterCard egyaltalan szoba alljon veled, kell egy Haboru es Beke volumenu szabalyozast atolvasni, es legalabb alapszinten foganatositani. Ezen felul van meg kettucatnyi ellenorzo szerv, mas kartyatarsasagok igenyei/szabalyai, stb.

    Az, hogy szerinted ez fassag, az rendben van, jogod van ehhez a velemenyhez, de engedd meg, hogy esetleg a valosag cizellaltabb legyen annal, mint amit a te egyszeru kis vilagodban mogekepzelsz. A bankok nem cilinderes nyulakat adnak-vesznek, hanem egeszen komoly penzmennyisegekert felelnek, ott nem lehet azt mondani, hogy na, akkor most nyomok egy uninstallt az AwesomeBankingSystem-en, es telepitem a SuperPowerfulBankingSystem-et, mert akkor a hozzad hasonlok lesznek a legjobban felhaborodva, ha valamiert all az egesz es nem jutnak hozza a penzukhoz, vagy valami meg rosszabb tortenik. Igen komoly rendelkezesre allasnak kell megfelelni egy banki rendszernek, plusz igen stabil mukodesunek kell lennie, raadasul minden banki rendszert integralni kell a meglevo megoldasokba, es igazabol ez a leghosszabb resze a folyamatnak.

    Boldogok a tudatlanok, mert ovek a tudatlansag nyugalma.
    --
    Blog | @hron84
    Üzemeltető macik

    Én nem üzemeltetőként, hanem fejlesztőként láttam banki rendszereket, és azok nem a szabályozói adottságok, hanem belülről fakadó bénázások miatt voltak túlbonyolítva. (Ez saját tapasztalat, amiből bizonyos hibahatárral, és a banki leállásokról szóló híreket olvasva merek extrapolálni.) Meg láttam banknál bonyolultabb, nagyobb, és nagyobb rendelkezésre állású rendszereket, amik mögött nem volt bénázás és túlbonyolítás, és tök jól működtek, szépen lehetett őket továbbfejleszteni, frissítgetni, telepítgetni.

    És egyáltalán nem azt mondtam, hogy a bankoknak egyszerű az élete. Természetesen van benne bonyolultság, de mégis túl van misztifikálva, hogy mennyi az annyi. Nagy divat azt mondani, hogy a banki rendszer az hű de kemény, de alapvetően nem kellene annak lennie, ez csak kifogás. És mégis lehet nagyon szarul csinálni, pont az a durva, hogy az általad is említett komoly felelősségek mellett milyen doigokat engednek meg maguknak.

    Csak egy példát mondok, mert ezt userként láttam, így nem köt a titoktartás: tranzakció történetet kerestem a netbankban, és egy véletlen üresen hagyott szűrő mező miatt a bank összes ügyfelének a tranzakciója megjelent. Na ez nem a 17-szeresen túlbiztosított rendszer példája, hanem a 17 rétegben egyszerre lyukas rendszer példája, hogy azok az adatok odakerülhettek a képernyőmre. Amúgy láttam ettől szomorúbb dolgokat is belülről.

    Ha van egy stabil, jól működő, dokumentált, letisztult API-jú backend rendszer, akkor arra egy új netbankot kifejleszteni (pl. Java helyett HTML5) nem olyan iszonyatosan nehéz, hogy hanyatt kell esni tőle. Természetesen nem szabad hülyegyerekekre bízni, akik azt se tudják, mi az az elosztott tranzakció vagy az XSS. De egy frontend rendszernek nem kell olyan sok mindent csinálnia, hogy jól tudjon működni. Ha meg a backend szar, instabil, el van bonyolítva, nincs dokumentálva, tucatnyi inkompatibilis és következetlen API-ból van összerakva, stb., akkor meg rohadt félelmetes még triviális bugfix miatt is hozzányúlni, és akkor jöhetnek a kifogások, hogy ez ezért meg azért nem egyszerű. Egy fölöslegesen túlbonyolított rendszert auditálni is nehezebb, nyilván.

    Én csupán annyit állítok továbbra is, az eredeti témához visszatérve, hogy valóban nem egyszerű, de nem _kellene_ _annyira_ bonyolultnak lennie egy új netbankot csinálni, mint amennyire beállítják.

    --

    Igen,de a banki szoftverek jo reszet nem mindig a bank sajat alkalmazottai irjak, gyakran kesz cuccokat vesznek, amik olyanok, amilyenek. Ez a regi vacak is, amirol en beszelek a maga koraban uttoro lehetett - tizenegynehany evvel ezelott. Most a tamogatottsag elmultaval csak a szopas volt vele minden teren....
    --
    Blog | @hron84
    Üzemeltető macik

    Valahonnan ismerős a dolog... "A régi ls binárist másoljátok fel a gépre, mert csak azzal működik az xyz funkció". Nem, egy wrapper, ami az idióta dátumformátumot (amit a régi ls "megfelelően" paraméterezve produkált) adja vissza RHEL5/6/7 alatti "gyári" ls parancsot használva, az nem jó, mert csak...

    "mindenki tudja, hogy halott"

    #define halott

    A mai napig jonnek ki frissitesek hozza, az Adobe lathatoan tamogatja a platformot, ez nekem nem tunik halottnak. Peldaul a Silverlight sokkal inkabb az, mert a Microsoft bejelentette, hogy ennyi, nincs tobb frissites.
    --
    Blog | @hron84
    Üzemeltető macik

    2000 óta? 5 évvel a YouTube alapítása előtt? 10 évvel a HTML5 és WebGL elterjedése előtt?

    2000-ben a WAP képes Nokia S40 mobil nagy felbontású Kígyóval volt maga a kézzel fogható csoda, még akkor is, ha tudtuk, hogy egyszer majd eljön a Linux telefonok kora. De az Android igazi térhódítására még kb. 10 évet kellett várni. Most viszont itt van és nem hozza lázba a fejlesztőket az S40 Java ME képessége.

    Így van ezzel a Flash is. Amíg nem volt valódi, élő alternatívája, addig jó volt. De annak már 5 éve! A böngészésre használt kütyük jelentős részén nincs is Flash Player már évek óta.

    Hát, szigorúan felhasználói szemléletű "körképet" kaptál, :) "minden jó valamire, ha másra nem, elrettentő példának" - szól a mottó...

    Apropó: a Fox / "browser.tabs.closeWindowWithLastTab"-hoz hasonló beállítási lehetőségről nem tudtok Chrome-nál? - Még ezt sem tudja?
    :-)

    Sejtésem szerint arra, hogy ez itt nem állítható. Mindenképp bezárja az utolsó tabbal a programot. Anno keresgéltem én is sokat a megoldást, találtam is szőrén-szálán nagyjából működőképest külön kiegészítővel, aztán inkább megszoktam, hogy nem kapcsolom ki az utolsó tabot :)