Probléma a Java SE 7 új biztonsági funkcióival

Java

A Security Explorations részéről Adam Gowdiak egy levelet küldött ma a FD levelezési listára, amelyben arról ír, hogy probléma van a Java SE 7 új biztonsági szolgáltatásaival. Az Oracle Java-ért felelős biztonsági vezetője szerint újabban jelentős fejlesztéseket eszközöltek a Java-ban, például azért, hogy megakadályozzák a csendes exploitálásokat. A vezető szerint a probléma az, hogy az emberek nem értik még ezeknek az új szolgáltatásoknak a működését.

A 2012. októberében kiadott Java SE 7 Update 10-től kezdve a felhasználó beállíthatja azt a biztonsági szintet, amely akkor kerül használatra, ha a böngészőben aláírás nélküli (unsigned) Java alkalmazásokat futtatnak. A Java teljes letiltásán kívül négy szint állítható be:

  • Low
    Most unsigned Java apps in the browser will run without
    prompting unless they request access to a specific old
    version of JRE or to protected resources on the system.
  • Medium
    Unsigned Java apps in the browser will run without
    prompting only if the Java version is considered secure.
    User will be prompted if an unsigned app requests to run
    on an old version of Java.
  • High
    User will be prompted before any unsigned Java app runs in
    the browser. If the JRE is below the security baseline,
    user will be given an option to update.
  • Very High
    Unsigned (sandboxed) apps will not run.

Gowdiak szerint az a baj, hogy a fentiek csak elméletben működnek. Arra jutottak, hogy bármi is van beállítva a Java Control Panel-en a fenti négy opció közül - akár a "Very High" is - lehetséges aláíratlan (és akár rosszindulatú) Java kódot futtatni. Az általuk készített PoC kód sikeresen végrehajtódott a legfrissebb Java SE 7 Update 11 környezetben Windows 7 alatt, "Very High" beállítások mellett.

Gowdiak szerint az Oracle által újabban implementált biztonsági funkciók nem védik meg egyáltalán a felhasználókat a csendes exploitálásoktól.

Részletek a levélben.

( szogi v | 2013. 01. 27., v – 16:56 )

@trey: "az emberek értik még" -> NEM értik még, nem?

( 4fonya | 2013. 01. 27., v – 17:01 )

Azért kíváncsi lennék arra hogy az Oracle felkent "szakértői" szokták-e tesztelni a munkájuk "gyümölcsét"? Esetleg arra kihegyezve a tesztet amiről úgy gondolják hogy éppen most javították ki. A biztonsági vezető a jelek szerint dióhéjban csak ennyit tud mondani: Hülye a felhasználó.

Segítek, megindokolni valószínűleg senki nem fogja tudni. Esetleg kikerekedik valami hatalmas flém, aminek a vége az lesz, hogy érvek nélküli fröcsögés születik. Ezzel szemben meg jön néhány menedzseltnyelv-hívő, beidézi a nagy O'Reilly, MS Press, Prentice Hall, Addison-Wesley klasszikusokat a témában, megspékelve néhány joelonsoftware, codinghorror, dailywtf, és persze Wikipedia hivatkozással, majd értetlenkedik, hogy az ellentábornak (általában egy, nagyobb szoftver kódját még életében nem látott szószóló) miért nincsenek hasonló hivatkozásai. Ezek híján aztán átmegy személyeskedésbe és értelmetlen trollkodásba az egész.

Vagy simán eloffolódik a téma, és elkezdjük kivesézni, hogy poliverzumnak mi baja az ipv4-gyel. Persze neki már nem lesz ideje válaszolni, hiszen épp UTF-1024-be konvertálja a regényeit, hogy tízcsilliárd év múlva is olvasni tudják az addig felhalmozódó karakterkészleteket kezelni tudó gépekkel. Merhát egyértelmű, hogy ahogy ő már 40 éve gondolt volna arra, hogy biza az ipv4 nem lesz elég, úgy az is egyértelmű neki, hogy az utf-8 sem elég már MA SEM!!!

Vagy csak simán ez lesz az utolsó hozzászólás itt.

Bocsánat, hogy beleszólok az egymás gyalázásába, de szerintem azért meg lehet indokolni. Nem kicsit, nagyon :)

A legkritikusabb exploitok általában az arbitrary code execution-on alapulnak. Az volt óriási hiba, hogy ezt lehetővé tették platform szinten. Ezzel elvész az a potenciális előny, amiben egy virtuális gép verhetetlen lett volna, hogy tényleg igazi törhetetlen sandboxként működjön.

Persze ez nem most kezdődött, már a JNLP-ben is benne volt azzal, hogy alternatív JVM-et tölthetsz le az internetről és futtathatod. Rémálom.

Hogy az Oracle miért szúrja el ennyire az 1.7-est, azt nem tudom. Mivel már tendencia, hogy egymást érik benne az ilyen lukak, lehet, hogy ez valami feature statisztikai folyománya. (Mint amikor mondjuk leszerelik a jelzőlámpát egy forgalmas kereszteződésben. Arisztotelészi értelemben nem törvényszerű, hogy ettől több baleset lesz, de mégis arra kell számítani.)

(Paranoidok szerint direkt akarják taccsra vágni a Javát. No comment.)

http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developers…

A hasznalando Java verziot, egy vendor URL-t, illetve JVM opciokat adhat meg a JNLP fileban a fejleszto.

Nincs semmilyen olyan lehetoseg, hogy a felhsaznalo beavatkozasa nelkul telepulne alternativ JVM.

Arra valoban van lehetoseg, hogy egy alternativ JRE-t toltsel le, de a usernek kell telepitenie es futtatnia.

Na jó, ezt a doksit én is láttam, de ez még nem _zárja_ ki, amit a kolléga állított. Azért titkon reméltem, hogy az állítása nem helyes. Mert amúgy mégis mit lehetne specifikálni a jnlp fájlban? Egy konkrét jvm bináris URL-jét? Vagy platformonként/processzoronkénti külön URL-t? Na szóval nem volt életszerű.

Maga a JVM semmi más, mint egy osztott könyvtár, a jvm.dll, jvm.so. De kell hozzá rengeteg támogató file (rt.jar és egyéb finomságok), így önmagában egy db file, mint olyan nem lehet JVM, JRE meg pláne nem (java nevű bináris is kell, az a JVM launcher).

Szóval NEM, nem lehet a JNLP-ben alternatív JVM-met megadni úgy, hogy az automatikusan, felhasználói beavatkozás nélkül használt legyen.

Szóval NEM, nem lehet a JNLP-ben alternatív JVM-met megadni úgy, hogy az automatikusan, felhasználói beavatkozás nélkül használt legyen.

Elvileg nem, mert védi valami policy, de gyakorlatilag ezt használták ki (kerülték meg) valamelyik ACE (arbitrary code exec) exploitban. Ott konkrétan egy demó keretében letöltötte a calc.exe-t és futtatta.

De ez csak egyik módja az ACE-nek, a jelek szerint a platform más módokon is lehetővé teszi ezt, az utóbbi 1.7-es hibák valóban nem JNLP-sek voltak.

A törésnek semmi köze nem volt a JNLP-hez. Egyszerű applet-ből sikerült kitörni úgy,
hogy meghackelték a javascript supportáló kód classloader-jét, és ezzel betöltöttek
egy olyan osztályt, amivel kikapcsolták a védelmet. Ennek a hibának a variációit
láthattuk az utóbbi x hónapban.

Nah, pont ettől áll ketté a fülem, és emiatt nem kezdtem el mondani sem, mert aztán jönnek a nagyfejű emberektől a nagy idézetek, és aki behúzta azt hiszi, hogy ezzel ő most érvelt. Pedig nem.
Amúgy nyílván ez egy költői túlzás volt a részéről, részemről, a Java nem kifejezetten tévedés, szükség van erre a fajta nyelvtípusra, csak nagyon el lett baszarintva. Valahol a C# és a Java jó tulajdonságai között kellett volna egy ilyen nyelvet felhúzni.
----
India delenda est.
Hülye pelikán

Na jó, csak akik majd érveket akarnak hallani, azok pont a "nagyon el lett baszarintva", MERT ... típusú szövegeknél a mert utáni részre kíváncsiak. Ahogy én is.

De általában ilyenek valahogy mégsem jönnek, emiatt viccesedik el minden topik. tzp kolléga lentebb legalább írt egy konkrét problémát, azon lehet beszélgetni, megdöbbenni, ellen- és mellette érvelni, de az üres mondatokon általában nem.

Na, pontosan erre számítottam. Én sem flémelni akarok, hanem hallani egy érvet. De mint írtam, általában a topikokban az a minta van, hogy nincs érv -> tehát flém/visszavonulás van. Mindig.

Ha egyszer 11 órakor mégsem éreznéd kora reggelinek az időpontot, azért légy szíves, tedd meg azt a fórumtársaid érdekében, hogy egy, azaz _egy_ érvet legalább mondasz. Előremozdulna a beszélgetés, én pedig megköszönném, utánaolvasnék, hogy tényleg úgy van-e, és felírnám a "milyen konkrét butaságok vannak a jávában"-listámra.

Mert amúgy vannak, én is tudok egy-két dologról, jó lenne bővíteni ezt a tudást.

Akkor megosztom a személyes élményeimet a Javaval, amiknél úgy éreztem, ezt bizony nem így kellett volna. Ott van az EE. Amivel az volt a legnagyobb bajom, hogy ahány vendor, annyiféle megvalósítás, mindegyik más annotációkat eszik meg (vagy legalábbis kicsit máshogy értelmezi őket). Most mondhatod, hogy de ez a vendorok és blablabla. Nem, ha idejében össze van szabályozva minden, akkor a vendorok sem tértek volna el. A vendor akkor tér el a nyelvtől, ha kell neki valami, ami nincs benne a nyelvben.
Valamint ott jött elő nekem az, hogy teljességgel kezelhetetlen a rendszer egy jó IDE nélkül, és ez a fejlesztés robosztusságát elveszi: amíg minden megy, addig jól haladsz, de ha valami nem, akkor nem fokozatosan ismerkedsz meg a rendszer működésével, hanem egyben szakad rád az egész.

Aztán itt van a nyelv tervezése. Ugye minden objektum, kivéve, ami nem. Ez a kettősség nem egyszerűsíti az életet, pedig simán meg lehetett volna oldani szépen is (lásd pl Python).

Amit még nem szeretek a nyelvben az az, hogy kicsit emlékeztet a PHP-ra. Iterációk egymásra pakolva, jött egy megoldás, rájöttek, hogy nem olyan jó ötlet, de addigra már millió sorok futottak vele, úgyhogy ráraktak még egy réteget. Lásd pl ablakkezelő könyvtárak, vagy Object konténerek vs generikusok.

De nem írok többet, így is elég szart fogok az arcomba kapni.
----
India delenda est.
Hülye pelikán

Nyelv és API nem ugyanaz. Másrészt ha valaki hivatalos JavaEE implementor, akkor annak át kell mennie a TCK-n, ami meg azt hozza magával, hogy nem lehet más értelme a megfelelő annotációknak. Az, hogy vannak a szabványon FELÜL annotációk, az meg senkit nem érdekel. Aki runtime-függő kódot csinál és nem szabványosat, az ígyjárt.

Köszönöm, így már lehet haladni.

> ahány vendor, annyiféle megvalósítás, mindegyik más annotációkat eszik meg
Ez nem teljesen így van, az elfogadott szabványt implementálóknak ellenőrzésen kell átesniük, hogy azt mondhassuk róluk, hogy javaEE... "kompatibilisek". Abban viszont igazad van, hogy a sok egyéb, vendor-only annotáció a tanulási görbét módosítja. Ugyanakkor emiatt a Javát elővenni nem fair; az MSVC compilere is enged nem szabványos #pragmá-kat: pl.: #pragma once. Mivel jónak találták a GCC fejlesztői is, így a GNU-s C compilerbe is belekerült idővel. De ez csak a "nyelv színezése", valóban félreértésre, inkompatibilitásra adhat okot a kezdőknél, dehát a szakemberré váláshoz a tapasztalat is szükséges.

> Ugye minden objektum, kivéve, ami nem
Ebben is van igazság. Viszont megintcsak sarkítás; ennél jóval pontosabban van rendszerbe foglalva a primitív típusok, és objektum típusok közti különbség. Bár erről nincs pontos infóm, a primitív típusok megtartása a kilencvenes évek közepén nekem is jó ötletnek tűnt volna, teljesítmény szempontból. Amúgy ugyanígy, C# ellen is felhozható ez hibának.

> Lásd pl ablakkezelő könyvtárak, vagy Object konténerek vs generikusok.
A GUI könyvtárakról: bár nincs velük fejlesztői tapasztalatom, nem tartom professzionálisnak a swing-awt féle saját widgetrajzolós bűvészkedést és a rendszer kinézetébe való nem illeszkedést (gtk look-and-feel-re nekem senki ne mondja, hogy az jó), ugyanígy a rendszer fonthinterét sem használják. Na aaaaz, szerintem is fos, bár való igaz, nem a nyelv hibája.
Az Object konténer vs. generikusok téma már más: A Generikusok támogatása később került a nyelvbe, a visszafelé kompatibilitás miatt pedig picit kuszának tűnhet a dolog, ugyanakkor amit lehetett, kihozták a dologból. A kérdés csak, hogy miért nem voltak előbb generikusok...? Itt viszont a Pythont rossz ötlet felhozni jó példának. A python v2-v3 váltás ugyanis forráskódszintű inkompatibilitást hozott. Az jobb? Nem.

Naszóval az érveid (merthogy akkor végre csak előbújtak ;-)) egy része érthető, én legalább számítottam az URL .equals() névfeloldására, mint ordas nagy bug.

Viszont a PHP-vel összevetni, na az elítélendő. Aki erről akar beszélni, az előbb olvassa át ezt, és majd rájön, hogy nemhogy a Java, de talán semely más nyelv nem egy akkora katyvasz, mint a PHP.

Szerk: na szóval látható, hogy vannak gyengeségei/hibái, de főként nem a nyelvnek, hanem az ökoszisztémának. És a threadből sem az jön le, hogy bebizonyosodtt volna, hogy a Java az "emberiség nagy tévedése"

"> Ugye minden objektum, kivéve, ami nem
... Amúgy ugyanígy, C# ellen is felhozható ez hibának."

Annyit felhoznék a védelmében, hogy nyelvi szinten sokkal inkább objektumként kezelhetőek a primitívek, mint java esetében, pl. konstanson metódus hívása, vagy leszármazás érték-típusból (valójában persze nem abból, hanem az ahhoz tartozó referencia-típusból). Lehet csinálni egy primitívre referenciát is ha épp arra van szükség.

Ablakkezelő könyvtárak: az AWT/Swing/SWT-re gondolsz, vagy a JavaFX-re?

Ha swing-ben fejlesztesz, sokat nem zavar az AWT, az SWT teljesen más rendszer,
mint az AWT, vagy a Swing, a JavaFX 2.0 meg az alapoktól újra van írva, hogy
szép/gyors/egyszerű legyen.

Iterációk egymásra pakolva: PHP-val nem összehasonlítható.

Kezelhetetlen a rendszer egy jó ide nélkül: IDE nélkül nem érdemes nagy projektbe kezdeni.

Objektum vs nem objektum: nyilvánvalóan teljesítménykényszerből csinálták, de autoboxing-gal
egészen szépen lehet dolgozni.

Generikusok: később jöttek, mint az object konténerek, és pont a típusnélküliségre (List List helyett) adtak nyelvi szintű megoldást.

Szóval a java nyelv fejlesztése nem az, hogy ész nélkül beleszórunk minden sz@rt ami eszünkbe jut, azt majd csak jó valamire, hanem nagyon konzervatív módon, lépésről lépésre kerülnek bele új feature-ök, ami számomra pl. nagyon szimpatikus.

Ja, ez a PHP-val valo osszevetes ott vicces, hogy a PHP-ban siman megcsinaljak neked azt, hogy egy micro verzio valtasban kompletten megvaltoztatjak az interpreter mukodeset. A Java azert ennel sokkal tervezhetobb valami.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"IDE nélkül nem érdemes nagy projektbe kezdeni."

Na, veled sem akarok dolgozni.

"Objektum vs nem objektum: nyilvánvalóan teljesítménykényszerből csinálták, de autoboxing-gal egészen szépen lehet dolgozni."

Szerinted a Python minden intet referencián keresztül használ? Inkább úgy fogalmaznék, hogy Javaék balfaszok voltak írni egy jó fordítót/JVM-et.

"Generikusok: később jöttek, mint az object konténerek,"

Igen, pontosan erről beszélek. Egy megoldás, aztán rárakunk mégegyet, amikor rájövünk, hogy az eredeti szar volt.
----
India delenda est.
Hülye pelikán

Mi lenne szerinted a jo megoldas autoboxing helyett?

Csak azert kerdem, mert a C++ eseteben is kulon vannak kezelve a primitivek... nem objektumok legalabbis.

Generikusok: jo kerdes, hogy eredetileg miert nem voltak generikusok. Viszont azt is vedd figyelembe, hogy amiota bevezettek, azota nagyon sok problema a generikusok hibas hasznalatara vezetheto vissza, pedig azok mar 1.5 ota benne vannak a nyelvben. Pedig az ember azt gondolna, hogy egy jo implementacio utan a rosszat nem hasznaljak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Már mondtam: Pythonban MINDEN objektum. És tényleg.
C++-ban olyan dolgokban térnek el a beépített típusok, hogy kapnak-e kezdőértéket automatikusan vagy sem. Meg nem lehet belőlük leszármazni. De kb ennyi, szemantikailag egységesebb a nyelv, nyílván az operátor túlterhelésnek is köszönhetően.
Paraméterátadás is ilyen téma, de ez C#-ban méginkább zavaró.
----
India delenda est.
Hülye pelikán

IDE nélkül mégis hogyan fogsz refactorálni, gyorsan keresni, gyorsan kódolni? Mi 100+ megás kódokkal dolgozunk, IDE nélkül nagyon nem szívesen dolgoznék...

"Igen, pontosan erről beszélek. Egy megoldás, aztán rárakunk mégegyet, amikor rájövünk, hogy az eredeti szar volt."

más elgondolás. Java-ban meghagyták az eredeti megoldást, hogy a régi kódokat ne kelljen kib@szni a kukába, és csináltak egy olyat, ami a végén az eredetire vezet vissza (type erasure). Mindezt úgy, hogy ne kelljen a fejlesztőknek újratanulni mindent. Ez nyilván egy nagyon rossz megoldás volt...

"IDE nélkül nem érdemes nagy projektbe kezdeni."

Na, veled sem akarok dolgozni.

Ezexerint te nagy projectbe belekezdesz notepaddel/vi-jal és parancssorból make? Nem az IDE az egyik válasz a szoftverkrízisre? Nem hatékonyabb egy IDE, mint a notepad?
--
unix -- több, mint kód. filozófia.
Life is feudal

Nézd, én azt láttam eddig mindenhol, hogy az IDE rárak sok réteget a munkafolyamatra. Annyira rátámaszkodnak, hogy anélkül már nem is megy semmi, és ha valami eltörik, akkor baj van. Ráadásul nagyobb projekt sok évig fog menni, és amikor 2013-ban sokéves eszközökkel fejlesztesz, mert mással nem megy (pedig én csináltam végig nagy projektben gcc3->gcc4 váltást, volt vele szopás, de megcsinálható volt), iszonyat effort váltani, akkor elgondolkodsz, hogy megérte-e.
Ha a következő hozzászólás az lesz, hogy de lehet jól is csinálni, akkor oké, sokmindent lehet, ha jól csinálod, eleve nincs szükség az IDE képességeire (már ha nem valami Java féle szutykot használsz). A valóságról beszéljünk, ne az ideákról.
----
India delenda est.
Hülye pelikán

A mostani projektünk kb. 8 éves, 150 mega forráskód, Netbeans az elejétől, utolsó 5 év eclipse. Release külön build scriptekkel történik. Soha semmi gond nem volt vele, és bizony volt, hogy 5 éves laptopokkal fejlesztettünk, viszont megcsináltunk néhány nagy refactor-t, és a fejlesztőeszköz nagyon sokat segített.

Értem én, hogy még nem láttál rendes IDE-t, de a valóságról beszéljünk, ne az ideákról.

Hagyd, ez olyan mint a GNOME vs KDE vagy a Samsung vs Apple.

Ha valaki jobban szeret notepadben dolgozni, hát tegye. De ha lenne egy százasom minden olyan eset után, amikor egy jó IDE megmentett a szopástól, megvenném a Microsoftot, és a saját arcképem lenne az alapértelmezett háttérkép a Windows 9-ben.

Értem én, hogy a világképed nem enged elszakadni, de azért próbáld meg. Jó IDE-t láttam már (és nem Eclipse-nek hívják, hanem Visual Studionak), és van, hogy hasznos, de komoly hátrányai is vannak.
Persze mint említettem, ha szart kell túrni, ahhoz jól jön, a Java pl tipikusan ilyen, igényli az ilyesfajta eszközöket.
----
India delenda est.
Hülye pelikán

Nem a VS szar, hanem egyszer érdemes meglesni, hogy milyen kényelmi
funkciókat ad az Eclipse teljesen ingyen (refactoring, stb.) amit
Visual Studio-ban csak fizetős pluginek segítségével lehet megoldani.
IDEA pedig - bár fizetős - még sokkal jobb, mint az Eclipse, kódolás
szempontjából.

Nekem van egy ilyen munkaelvem, hogy az IDE szolgáltatásait akkor jó használni, ha te kézzel is meg tudnád csinálni ugyanazt (vagy tudnál rá írni egy programot, perl scriptet, akármit, ami megcsinálja helyetted), csak éppen nem akarsz ezzel órákat vacakolni.

Magyarul ésszel használod és nem csak kattintgatva.

"kezelhetetlen a rendszer egy jó IDE nélkül"

Van egy exkollegam, nagyon csunya meretu Java forrasfat tartott karban egy egyszeru EditPlussal. Probalkozott o NetBeans-tol Eclipse-ig sokmindennel, de e mellett kotott ki.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Attól függ, mi a célod.

Láttam olyan nagy, C++-os szoftver forráskódját, amit lehetett mezei texteditorral is karban tartani, azon a szinten, ahogy használták: Minden header összeinclude-olva egy precompiled headerbe, majd azok szintén egymásba, így a fordítási egységekben, de még a hozzájuk tartozó .h fájlokban is _nagyon_ kevés include volt: ezáltal nem nagyon kellett IDE, minden mindent használhatott, nem volt szükség a modulok határait definiálni és az include-okkal jelezni.

2millió soros C++ projekt, szerintem itt jópáran napi szinten használjuk ezt a zárt forrású szoftvert.

Van, ahol meg az egységbezárás, az interfész-szegregáció, a láthatóságok minimalizálása fontos, a Java igyekszik erre kényszeríteni. Ott sok az import, azok tisztántartására pedig jók az IDE-k, kevés a texteditor funkcionalitása.

Nekem egyelőre úgy tűnt, hogy azok akik akár tényleg nagymesterei a nagyobb editoroknak (pl. vim/emacs), azok nem feltétlenül írnak szépen szervezett kódott, szépen szervezett forrásfában.

Azert ma mar Vim-hez/Emacs-hoz is van mar olyan plugin, ami kepes jelezni az import hianyokat, es akar javaslatokat is adni. Ilyen szempontbol a kezdok amugy talan konnyebb helyzetben vannak, mert a nagymesterek mar bevalt pluginokat hasznalnak csak, nagyon nehezen nyitnak az uj fele.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Akadnak azért a Jávánál nagyobb tévedések. Sokkal nagyobbak. Például:

- Microsoft
- Windows
- Dos
- A "felhő" erőltetése
- A semmire se használható érintőképernyős masinák, amikben ráadásul csak pár giga RAM van normális kapacitású HDD helyett
- IPv4
- CapsLock
- DocX
- Mindenféle szar codepage-ek bevezetése, ahelyett hogy rögtön valami normális unicode-szerű szabványt vezettek volna be. Ezzel kapcsolatban épp ma érdekes esetem történt: A minap valamiért írtam egy levelet a mindenhova szokásosan használt gmailos címemről az egyik indiai magyar nagykövetségre. Vagy egy nappal később azt a választ kaptam, hogy a levél az ékezetek hiánya miatt olvashatatlan. Érdekes, amit ők írtak ott olvasható volt az ékezet. Ellenben ami az ő levelük alatt volt az én levelem idézése, abban ilyesmik szerepeltek:
"Az lenne teh�t a k�r�sem �n�kh�z,"
Holott amit én küldtem, az "elküldött levelek" mappában, tökéletesen normálisan olvasható, ellenőriztem.
- szoftverszabadalmak

Szóval akadnak bőven a Jávánál nagyonn tévedések...

-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Én már így is, most is vagyok valaki. Nem is akárki.

"Nyugodt vagyok, tudom mit érek, s nekem elég ez öntudat!"

Én lennék a világ legnyomorúságosabb lénye, még Gollamnál (Szméagol) is szerencsétlenebb, ha attól függne az önbecsülésem, hogy TE miként vélekedel rólam.
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Ezt nem értem, mi közöm nekem az ő gépeihez?! Bár jobban járna ha rám bízná őket, az igaz. Egykettőre megszabadítanám a kedvenc windózaitól... Bár bevallom, annyira ellenszenves fickó számomra, hogy lehet e munkát (se) vállalnám neki még rengeteg pénzért se el...

Különben is más dolgom van. Új könyvön dolgozom, az a címe, hogy "Az utolsó szitárművész". Romantikus/szerelmes sci-fi lesz. Ez messze jobban érdekel, mint a trollok lelkivilága. Inkább erre szánom az időmet, mint a flame-ra.
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Arra reagáltam, hogy poli leszarja hogy mit gondolsz róla. Erre megint azzal jössz, hogy mit gondolsz RÓLAM. Már kezdem azt hinni hogy te vagy az aki önértékelési problémákkal küzd. :)

Megj: Gondolom te ilyet soha nem csinálnál, hogy belinkeled azt ahol te hibáztál. Ezért nem is tudod értelmezni, hogy miért tettem.

Miért lennének ezek tévedések?

Sorban: M$, Dos, Windows: egy cég, amelyik sikeresen tudott garázscégből nagy céggé avanzsálni, közvetlenül 100 ezer embernek, közvetve több milliónak ad munkát világszerte, elérhetővé, használhatóvá tette a hétköznapi ember számára a számítógépet. Nyilván ehhez párosult egy elég agresszív marketing vonal, de az érdem az övék.

Felhő: azért kényelmes volt, amikor az androidos telefonomnál beírtam a nevem/jelszóm, és a google felhőből leszedte a kapcsolataimat, telefonszámmal, elérhetőségekkel együtt. Igy ebben a formában tök jó. Vagy amikor egy doksit kell megosztani ismerősökkel, csak feldobom a google docs-ra, és tudjuk közösen szerkeszteni. Ugyanez file-oknál, videóknál, feldobom, és már tudják nézni, kommentálni.

Érintőképernyős masinák: a telefonnál ezt nem értem, mert ugye ha kóvájgok a városban, akkor egyszerűbb egy google maps-ban megnézni, hogy pontosan hogyan is jutok oda, ahova kell, mint térképpel a kezemben bénázni. Vagy tudom, hogy mikor jön a villamos, és időben abbahagyom az edzést, hogy még elérjem, és ne kelljen 20 percet várni. Vagy reggeli buszozás közben tudom tanulni a szókártyáimat. Vagy falun is meg tudom nézni az emailjeimet, sőt, válaszolni is tudok rájuk.
A másik a tablet. Anyósoméknak vittem egy olcsósított laptopot, mert most már van netjük. Nagyon nem meri használni, mert bonyolult. Ehhez képest egy tab pofonegyszerű. Pl. az ilyen felhasználóknak
tökéletes egy tab.

IPV4: lent leírták

CapsLock: lent leírták

DocX: azt én sem tudom értelmezni

Codepage: amikor a codepage-eket kitalálták, senki sem gondolta, hogy a számítógépek ilyen elterjedtek lesznek. Úgy gondolták, hogy majd megoldják, amikor szükség lesz rá. Akkor meg is lett oldva, habár azért az UTF8-ra való átmenet eltartott egy ideig...

Szoftverszabadalmak: megint, amikor kitalálták, akkor volt értelme, egy mp3 kódolási algoritmus kifejlesztése pl. simán eltarthatott évekig, más kérdés, hogy most már eljárt felettük az idő.

codepage-ek: szerintem te még nem is éltél, amikor az ASCII (1963) már szabvány volt. És hogy teljes legyen a kép, akkoriban volt egy másik nagyon elterjedt kódlap is: EBCDIC (1964). Az ASCII-t a telex gépekhez dolgozták ki USA-ban, az EBCDIC-et az IBM dolgozta ki a számítógépeihez. Gondolhatod, hogy 1963-ban nem az járt a fejükben, hogy a magyar, görög, kínai stb jeleket hogyan lehetne átvinni a telex gépeken (amelyeken mechanikailag is elég korlátozott volt a jelkészlet mérete). Szóval az ASCII történelmileg teljesen érthető, nem is volt annak idején cél 16 vagy 32 bites karakterkészletet használni (így is eleinte max másodpercenként néhány tíz karakteres sebességgel mentek a telexek).
A gond később volt, mindenki elindult a saját útján és itt volt egy tévedés, amiben én is egyetértek: minden nagy szoftvercég (IBM, Microsoft, ...), minden ország, minden régió elkezdte kidolgozni a saját megoldását...

Összekevered valamivel a Java-t! Kijelentésedből tisztán látszik, hogy még nem fejlesztettél Javaban. Szerintem ha tévedésről kell beszélni az informatikában akkor sok egyéb dolgot előbb felhozhatnánk (pl. x86-os processzor, windows, C#, http, php stb.) Na most ezekre kapják fel sokan a fejüket, mert szerintük meg ezek nem voltak tévedések (bár ettől szerintem még folyhatott volna egy picit más mederben az informatika elmúlt 35 éve)

Egy java fejlesztő...

( tr3w v | 2013. 01. 28., h – 08:46 )

Java környékéről minden értelmes fejlesztő lelépett a Sun felvásárlásakor?!

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( ak0sh | 2013. 01. 28., h – 09:49 )

A negatív reklám is reklám...
De valójában mire megy ki a játék?
Lehetséges, hogy a patentek miatt a Microsoft kivár, és föl akarja vásárolni a Zorákült?

Fantázia azért van :) Valószínűleg az a helyzet, hogy a nagy Sun felvásárlással az Oracle nyakába esett egy termék, amire nem volt
felkészülve, plusz valószínűleg egy csomó java-val (vm-mel, könyvtárakkal) foglalkozó ember is otthagyta a céget, meg azért a Sun-nál
is voltak mindig gondok a terméktámogatással (kb. fél évembe telt átverni rajtuk, hogy Magyarországon/Európában a hét első napja hétfővel
kezdődik)

( johans | 2013. 01. 28., h – 13:53 )

[J]ust
[A]nother
[V]ulnerability
[A]nnouncement

( tzp | 2013. 01. 28., h – 15:51 )

Unsigned Java apps in the browser will run without
prompting only if the Java version is considered secure.

No és ki állítja be, hogy melyik a secure java verzió ill. mi a security baseline ? Eleinte mindegyik 1.7 update-ről azt gondolják, aztán valahogy csak kiderül egy újabb arbitrary code execution exploit.