A legtöbb informatikus már az egyetemen/főiskolán hall Babbage mechanikus számítógépéről. Ez gyakorlatilag egy nagyon egyszerű számítógép, ami teljesen mechanikusan működött volna, elektromosság nélkül. Az alapvető problémája a súrlódás, ezt a faktort nem sikerült kiejteni, emiatt a gép nem volt használható, de tulajdonképpen ez volt az első elméletileg működőképes számítógép.

(sidetracking: Most elgondolkoztam, milyen lenne, ha modern anyagokkal megcsinálnák újra ezt a konstrukciót.. vsz teflonnal működne, amíg az el nem kopna )

A sztori lényege, ami miatt előkaptam a sutból, a következő: Van egy megvalósítandó cél, amit a rendelkezésre álló technológiai eszközökkel megvalósítunk, és életképtelennek bizonyul. Mondok erre egy másik példát: A cél az űr meghódítása, amit a rakétameghajtással megpróbálunk megvalósítani, és marhára nem megy. Nagy nehezen eljutunk a legközelebbi égitestre, (a Hold), majd feladjuk a próbálkozást, mert nincs ott semmi.

Három lehetséges jövőt látok hosszú távon az emberiség előtt:

• Feléli a Föld tartalékait és elpusztítja magát
• Kifejleszt egy új technológiát, amivel meghódítja a világűrt
• Robotizál és virtuális valóságba merül

Az elsőhöz minden adott. Elég jól definiált a cél, megvan a szükséges technológia, hogy elérjük, és úgy tűnik, nincs meg az akarat, hogy elkerüljük. Na de tegyük fel, hogy a kétségbeesés előbb érkezik meg, minthogy a folyamat visszafordíthatatlanná válna, és valahogy sikerül megjavítani a helyzetet..

Kimegyünk-e az űrbe? Erre nem fogadnék. A rakéta alapú technológia rengeteg problémát felvet, többek között: specifikus üzemanyag kell, amit speciális módon kell elhelyezni a rakétában, a teljes mennyiséget kell szállítani oda és vissza (persze a nagy része közben elég), kb. ugyanannyi anyag kell a lefékezéshez, mint a felgyorsuláshoz, nem túl jó a manőverezhetősége. És akkor még arról nem is beszéltünk, hogy fénysebességgel mozogva is évekre van a legközelebbi naprendszer, de vannak olyanok is, amiknek az elérése több ezer évbe telne (most gondoljunk bele abba, hogy az elmúlt 100 év során mennyit változott a világ.. ) szóval ez a megoldás szimplán alkalmatlan. A következő három dolgot fel kellene találni ahhoz, hogy egyáltalán reményünk legyen az űrben bármit elérni: Fúziós/Ion meghajtás, amivel tetszőleges anyagot tudunk felhasználni arra, hogy mozgassuk az űrben a járművünket; antigravitáció, amivel lényegesen kevesebb energia révén el tudjuk hagyni egy bolygó felszínét (felhasználva pl. a ránk ható centrifugális erőt, azaz pontosabban a bolygó forgásából adódó érintő irányú sebességünket); teleportáció/fénysebesség feletti mozgás, amivel belátható időn belül el tudjuk érni a távolabb eső naprendszereket. Fénysebesség feletti kommunikáció sem ártana persze..

Ha egyáltalán lehetséges feltalálni ezeket a dolgokat (az elsőt igen, a többit vsz nem), akkor sem biztos, hogy sikerül ezt megtennünk abban a szűk időszakaszban, ami a Föld tartalékainak kimerüléséig bekövetkezik. Ebben az esetben arra vagyunk kárhoztatva, hogy a saját naprendszerünk kvázi elérhető bolygóit fedezzük fel, ami gyaníthatóan nem sokat fog jelenteni nekünk, azon túl, hogy nyersanyagot szerzünk róluk, persze itt is kérdés, hogy rakétameghajtással lehet-e ezt hatékonyan tenni..

A harmadik kimenetel már sokkal esélyesebb. Nagy sebességű kommunikáció, fúziós vagy annál is jobb energiaforrások, közvetlen idegrendszeri kommunikáció a számítógépek és az emberek között – ez mind adott, vagy elérhető közelségben van. Hogy nézne ki ez az egész? Az emberiség gyakorlatilag folyamatosan a neten lóg, virtuális világokban, játék formájában dolgozik, amit robotok váltanak valóra – pl. Farmville-t tol, de amit csinál, az a valóságban is végrehajtódik valahol, etc. A felfedezésre váró világok – pl. űr, de akármi is lehet – kéznél vannak. Persze, csak virtuálisak, na de akkor mi van? Pont emiatt sokkal izgalmasabbak, mint a valódi űrfelderítés. A userek generálnak contentet, az aggresszívebbek pvpznek, a békésebbek birkát számolnak a réten. Minden játékos formában persze..

Nem tudom, ez a vég valójában szomorú-e, vagy az egyetlen lehetséges jó végkimenet ebben az univerzumban a mi számunkra..

Nem jogi, sokkal inkább “common sense” oldalról megközelítve, elég sokat gondolkoztam mostanában az e-bookok beszerzésén.

Van pár teljesen egyértelmű eset: Megveszed valahol x pénzért az e-bookot, innentől jogszerűen a tiéd. Letöltöd valahonnan, ezzel kalózkodást követsz el.

Ám..

(Apró sidetracking: Mi a helyzet az árazással? Nyilván az e-book előállítása a jellemzően eleve elektronikus formában megírt regényből szinte semmibe nem kerül (legalábbis ha már mindent megtettek a papíralapú regény előállításához), szóval amit ki kell fizetni, az leginkább a hostolás és a letöltés ára, ami nyilván nevetségesen alacsony. Ugyanakkor, érthető, hogy valami hasznot is szeretne látni a szerző és a kiadó a könyvön, szóval raknak rá valamennyi pénzt. De mi indokolja, hogy az e-book ára ugyanannyi, mint a papír alapú könyvé? Semmi az égvilágon, ez csak szabadrablás. Szerintem ez elég rossz stratégia, manapság már van annyi ebook reader a nép kezében, hogy megérje olcsón adni és a volumenre gyúrni.. és persze van bittorrent is, hogy az emberek ne akarják megvenni, ha drága.)

Tegyük fel, hogy van egy könyved, amit a boltban megvettél tavaly. Karácsonyra kaptál egy ebook readert. Szeretnéd a fenti könyvet újraolvasni, mert jó, de idegesít, hogy papír, te a gyönyörű, könnyű, vékony ebook olvasódon szeretnéd olvasni. Szívesen megvennéd újra a könyvet azok után, hogy már egyszer megvetted? Ráadásul ugyanannyiért, mint az eredeti könyvet? Aligha. Szeretnéd ingyen megkapni, de azért azt ne várjuk el a kiadótól, hogy ezt megteszi neked. Vajon ha elmész egy torrent site-ra, és letorrentezed az adott könyv elektronikus formáját, az mekkora bűn? Hiszen egyszer már megvetted, a tiéd, csak a formátum változott, ráadásul a kiadónak egy fillért nem kell költenie, hogy meglegyen neked ebook formában. Ugyanez a kérdés, ha torrentet nem használsz, de kézzel bescanneled a könyvet, és ráeresztesz egy szövegfelismerőt… Jogilag nyilván bűnt követsz el, de voltaképpen mi ebben a bűn, ha ezt a példányt nem teszed más számára elérhetővé, csak te használod…?

Mi a helyzet fordított esetben? Van egy ebookod, amihez nincs meg a papír alapú könyv, de te valamilyen személyes perverzióból úgy döntesz, hogy kinyomtatod és bekötteted? Tegyük fel, hogy képes vagy erre, vajon ez most bűnözés, ha utána a kinyomtatott lapokat nem adod oda senkinek, csak te magad olvasod?

A következő témára lépve, tegyük fel, hogy van egy kiadó, aki minden papír alapú könyve mellé letölthetővé teszi számodra annak elektronikus változatát is, …

• ingyen, az ebook magában nem kapható: Persze, hogy vennék, mint a cukrot.
• 1 dollár alatti áron, ebook magában nem kapható: Továbbra is lenne egy csomó ember, aki vásárolna
• ingyen, de az ebook magában 1 dollár alatt van: Itt már erősen átalakulna szerintem a piac, vsz többen vennének pure ebook-ot
• 1 dollár alatti áron, az ebook magában mondjuk 3-5 dollár között van: Ez egy nagyon érdekes helyzet, nem tudom, mi történne itt.

Látatlanban azt mondom viszont, hogy a fentiek közül bármelyik megoldás több eladást/profitot eredményezne, mint az, hogy a papír alapú uannyi, mint az ebook, és együtt nem kapható a kettő.

A londoni káosz, és az az erő, amivel a médiából áradt, elkeseredésbe kergetett. Ilyenkor könnyű elhinni, hogy már a civilizáció vége felé közeledünk egy tölcsérben lefelé..

Ám ekkor jön a Riot Cleanup, a Waterstones humor és a Titkos Anti-Nácik, és máris sokkal szebb a világ. Talán mégis vannak még tartalékok ebben az emberi fajban..

A tüntetés az, amikor egy csoport ember – a csoport mérete egészen kevéstől egészen sokig terjedhet – összegyűlik, és hangot ad annak, hogy valamilyen probléma miatt aggódik/mérges. Az ok lehet politikai (ld. Mo-i helyzet néhány éve), gazdasági (Tel-Aviv ezekben a napokban), rendőri túlkapás elleni (múlt vasárnap Londonban). A tüntetést fel lehet oszlatni jogi alapokon, de a rendőrök nem járhatnak el erőszakosan, és nem is tartóztatnak le igazából senkit.

Abban a pillanatban, hogy elrepül valami a tüntetők irányából a karhatalom képviselőinek irányába, a tüntetés zavargássá alakul. Megjelenik az erőszak. Ez persze erősen sarkított dolog, de nagyjából ez a nyitány. Szóval megjelenik az erőszak a színtéren, és a karhatalom ettől a pillanattól jogszerűen tehet (valamivel kevésbé) erőszakos lépéseket, hogy elfojtsa azt. Ez bekövetkezett Budapesten, és bekövetkezett Londonban. Tel-Avivban, a tüntetők nagy száma ellenére nem.  Ebben a fázisban van a gyújtogatás is – legyen az autó, villamos, szófagyár vagy bolt.

Aztán valaki a tömeg közepén, a pillanattól felhevülve, és a tömegben magát védettnek érezve, betör egy kirakatot és felmarkol pár cuccot. Lehet, hogy csak egy pár fiatal, akik az élelmiszerboltot törik fel némi alkoholért, de az is lehet, hogy ékszereket vagy készpénzt akar az illető. Ez több helyen, egymástól függetlenül is megtörténhet. Innentől már a fosztogatás és a zavargás egymás mellett futnak. A lényeg az, hogy az opportunista lelkek megragadják a lehetőséget, hogy elvegyék más tulajdonát. Ez bekövetkezett és csúnyán elfajult Londonban, mostanra már gyakorlatilag a zavargások fő vonulatává válva.

Van itt egy érdekes összefüggés. Minél magasabb az életszínvonal, minél kevesebb a napi gond, annál nagyobb az esély, hogy a tüntetés fosztogatássá válik. Vagy talán a tüntetést kiváltó ok mondvacsináltsága szabályozza ezt, az, hogy mennyien azonosulnak valóban a problémával, és mennyien látják csak a lehetőséget a zavargásra, rendbontásra.

Végtelenül megvetem ezeket az embereket. Tudom, mi a gond Izraelben, és nagyon sajnálom azokat az embereket. Tudom, mi volt a gond pár éve Budapesten, és bár az okaikkal nem értettem egyet, el tudom fogadni, hogy tüntettek érte, és azt is megértem (bár elítélem) hogy miért lett belőle zavargás. Azonban azt, hogy egy állítólagos rendőri túlkapás gyújtogatássá és fosztogatássá fajul, nem tudom elfogadni. A legrosszabb az az egészben, hogy emiatt most már azok is, akik eredetileg szimpatizáltak az üggyel, kezdenek elfordulni tőle, így a (jogosan vagy jogtalanul) lelőtt 4 gyermekes családapa családjának egyre kevesebb esélye van arra, hogy valóban igazságot szolgáltassanak nekik.

ui: Bár többször eszembe jutottak a franciaországi zavargások, nem írtam róla. Nagyjából a budapestivel összevethető, bár az okok talán valamivel erősebbek/megindokoltabbak voltak, mint nálunk.

Minap a lányom egy megjegyzése kapcsán gondolkoztam el ezen:

“Láttam ma egy elefántot” illetve “Láttam ma az elefántot”. Az első mondat általános, míg a második specifikus, egy konkrét elefántra gondol, amiről a befogadó félnek tudni is kellene, hogy melyik.

Ezt pedig vessük össze ezzel:

“A kedvenc állatom az elefánt” illetve “A kedvenc állatom egy elefánt”. Bár látszólag ugyanolyan a két mondat szerkezete, pontosan fordított az értelme, a határozatlan névelő egy konkrét példányra utal, míg a határozott névelő az elefántokat, mint fajt fogja meg, és nem ereszkedik le példány szintre.

Vicces ez a nyelv.

Basic socket communication

Writing a client/server application communicating over sockets is pretty easy in Java. The server creates an instance of the aptly named ServerSocket class, which waits for incoming connections. The client creates a Socket instance, which then connects to the server (thus creating another Socket on the server side via the accept method of the ServerSocket), and that’s it. Although Sockets are normally blocking read operations, it is easy to emulate a single threaded non-blocking communication with simply checking the available bytes on the socket, and reading only that much.

Blocking secure socket communication, the problem

Switching to a secure socket connection is very easy: First, you need to create some keystores, then some initialization in the code and then you can use some factory classes to create the secure sockets instead of the original constructor calls. Everything else is almost the same.. except..

Getting the number of available bytes are not reliable any more. The reason is simple: As your security and application data arrives in the same stream, the security engine is not able to tell the amount of available application bytes without trying to decrypt everything, but that is a complex operation. Probably more complex and requires more effort than you would like to have in an infinite loop.

Because of this, our workaround for blocking communication is not usable anymore. For a simple application with just one or a handful of clients it is acceptable to have a separate thread for all of the connected clients on the server side, but we need another solution for high user counts.

SocketChannels

Java NIO has a nonblocking socket solution. SocketChannels are designed for this. Because of the fundamentally different usage and the additional classes, such as Selectors, most people never uses them, but they are not overly complex, and with a little practice can be used easily. For beginners, I’d recommend reading this article: Rox Java NIO Tutorial. It’s probably not the easiest to understand, but contains very useful tips and explains typical pitfalls.

Using this, we solve the issue with the blocking channels, but security is still lacking. The bad news is: It is pretty hard to make SocketChannels secure. This is your second chance to turn back, and use the blocking solution, they say a few thousand threads are not really a problem for a good server

Securing SocketChannels

Ok, you are desperate. You want ‘em non-blocking channels communicate securely. Here is what you need to add to the code:

1. You don’t need to do anything with the ServerSocketChannel, and the way it accepts connections.
2. I prefer doing the reading and writing in a separate class, which “owns” the connection and the SSLEngine. (See Below)
3. Initialize your security.
4. On the server side, for every new socketchannel, create a new SSLEngine.
5. On the client side, do the same for your one channel.
6. Initiate the handshake.
7. After the handshake, wrap everything you want to send and unwrap everything that you receive on both sides.

So far it is not too complex, right? Let’s dig deeper.

Initializing security:

private void setupSecurity() {
	SecureRandom secureRandom = new SecureRandom();
	secureRandom.nextInt();

	KeyStore clientKeyStore = KeyStore.getInstance("JKS");
	clientKeyStore.load(new FileInputStream("client.jks"), "KeyStorePassword".toCharArray()); 

	TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
	tmf.init(clientKeyStore);

	KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
	kmf.init(clientKeyStore, "KeyInKeystorePassword".toCharArray());

	sslContext = SSLContext.getInstance("TLS");
	sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), secureRandom);
}

Couldn’t be more straightforward. Creating an SSLEngine is just as easy:

SSLEngine engine = sslContext.createSSLEngine();

And now the handshake.. You can find a lot of explanations here (it’s a bit dry, but very useful). The scaffolding for the code can be found in the same article, but you are better off if you check the code here: [jdk home]\sample\nio\server\ChannelIOSecure.java

It is very complicated, and there is a hidden “flaw”: It’s meant to be used with blocking channels. (See below). Also, some structures are a bit more complex than I’d usually like it, for example the 3 levels deep switch constructs. Anyway, for now you should just try to copy it as closely as you can, and if you can make it work, then you can improve the code as much as you want.

The problems I faced

Obviously, it didn’t work for me the first time I tried. Here are some tips:

• Don’t give up. It’s complex and ugly, but it can be done.
• If the handshake doesn’t start, and/or the server complains about plaintext connection, insert the engine.beginHandshake() line before the handshake process. Sometimes the only issue that you see is that the clients sends the messages and the server simply absorbs them without any apparent effect.
• If you get repeated buffer underflow errors on the server side, and using non-blocking communication, it’s time to add a new check for zero length reads. Trying to unwrap zero length ByteBuffers can cause this issue.
• In case of unsupported record version problems or sequence violation (during the handshake) try to empty your buffers before you read/unwrap into them and after you have sent them to the other party. Leftover bytes can cause this issue. (Unsupported record version Unknown) (Handshake message sequence violation)
• If the server/client complains about invalid handshake mac, check your flushing code. You may loose some important bytes. (bad handshake record MAC)
• Google is your friend: There are a lot of people out there who solved the same issues and wrote an article about it.
• It’s a good idea to add some logging to the code to see what is happening. It helps you to see the sequence of events on both sides.
• There are some issues and solutions here I didn’t face. Still, you may see them.

I hope this will help some of you to develop some great, secure applications.

Bringing up a child is the process of how parents impose order over the fundamentally chaotic nature of their kid.

Ma tudtuk meg, h a gyerek fiú lesz, azaz a választott név (Félix) tökéletes lesz.
Ez a múlt heti fotó.

Néha eszembe jutnak olyan fizikai kérdések, amikhez nincs meg a megfelelő hátterem, hogy megválaszoljam őket. Íme egy pár:
- A fény (illetve bármely hullám) energiája a foton/részecskesűrűségtől függ, vagy van valami energiaszintje a részecskéknek, ami meghatározza a szállított energia mértékét? (pl. terjedési irányra merőleges rezgés, vagy forgó mozgás). Hogyan adja át az energiát a fény az anyagnak? Ha az energiaszint egy létező dolog, lehet-e ezt változtatni a fénysugáron/hullámon?
- Tételezzük fel, hogy az idő illetve a tér nem lebontható a végtelenségig, van egy minimális méret, aminél kisebb egység gyakorlatilag nem létezik (elméletileg igen). Megmagyarázhatja-e ez a Heisenberg féle bizonytalansági elvet illetve a kvantumfizika egyes jelenségeit.
- Megmagyarázható-e az elektron kettős (hullám és részecske) természete azzal, hogy a részecske alapvetően egy párhuzamos dimenzióban létezik, és a mód, ahogy megfigyeljük, materializálja a mi világunkban?

A válaszokat kommentben kérném indoklással egy egy nyilatkoztattal arról, hogy mennyire vagytok biztosak az adott dologban.

Tegnap két extrém példán keresztül tudatosult bennem, hogy mennyire az önbizalomról szól a szakma. Nem csak arról, természetesen, de talán egy kicsit nagyobb a jelentősége, mint pl. a kézműves vagy szolgáltató iparban.
Az első példa: Van egy ismerősöm (igen, N, rólad írok) akinek a CV-jét javítgattuk tegnap. 7 éve dolgozik az IT supporton, olyan technológiákkal dolgozik, amiről én még nem is hallottam, és a CV ennek megfelelően elég meggyőző. Az önbizalma azonban nem üti meg azt a szintet, amit én természetesnek gondolnék ennyi tapasztalattal, így megragadt egy olyan állásban, ami nem díjazza megfelelően a képességeit.
A második példa: Olvastam egy cikket a Daily WTF-on, ahol egy szörnyű kódrészlet mellett ott szerepel ez a szöveg: ” those who knew better (i.e. management) sang plenty of praise, of both the PHP God, and his clean, well-commented code.”, azaz nyers fordításban: A vezetőség viszont egyaránt dícsérte a PHP Istent (a fent emlegetett kód alkotója) és annak tiszta, szépen kommentezett kódját.
Tehát, van egy hozzáértő de nem túl sikeres, és egy béna, de nagyra tartott szakmai dolgozó. Na, ez miért van így?
Képzeld el, hogy kijön a burkoló, újraburkolja a fürdőszobádat. Bemész és körülnézel, a csempék ferdék, a színek rondán vannak összeválogatva, és elfelejtett lyukat hagyni a szellőzőnek. Viszont a vizet nem ereszti át, tehát ebből a szempontból tökéletesen megfelel a követelményeknek.
Nyilvánvaló, hogy ezt nem hagynád annyiban, és meglenne a véleményed az illetőről. Viszont, képzeljük el, hogy vak vagy, és ugyanígy megnézed a dolgozó munkáját.. valamilyen módon meg tudsz győződni róla, hogy nem szivárog a víz (például úgy, hogy az alsó szomszéd nem jön fel), de azt már nem tudod megmondani, hogy rondák a színek, szóval örülsz, h kész a fürdőszoba és azt tudja, amit kell.
Ez az utóbbi a helyzet a szakmánkban. A vezetőség a legtöbb helyen nem ex informatikia dolgozókból áll, így max annyit tudnak megmondani a kódról, hogy “de szép színes betűk vannak benne”. Ők csak annyit néznek, hogy a weblap megjelenik, az adatbázisszerver működik, az appszerver kiszolgálja a kéréseket, azt már nem tudják igazából felmérni, hogy a táblázattal formázott, nem valid html mennyire nem karbantartható, nem tudják, hogy az adatbázisszervert nem meri senki három éve kikapcsolni, mert nem bíznak benne, hogy újra bekapcsolódik, sít. Itt jön az, hogy a barátságos, mindenre bólogató, gyorsan szállító programozót mindenki kedveli, a rendszergazdát, aki csendben végzi a dolgát, senki észre sem veszi, amíg valami el nem romlik, akkor pedig lekiabálják a haját..
Az Önbizalom Vására – a személyiség legalább annyit számít, mint a tudás.

A konstruktivitás világnapjának a jegyében nézzünk rá arra, hogy mi adhat nekünk okot az önbizalomra. A vezetőség elismerése? Nem, az nem szakmai elismerés. Nekem a következő dolgok adnak önbizalmat:
- Sokféle helyzetben voltam már, és még soha nem kellett feltennem a kezem, hogy: “Ezt nem lehet megoldani, és fogalmam sincs, hogy mit kellene most csinálnom”. Volt, hogy sokat szenvedtem a megoldással, de mindent sikerült megoldani vagy megkerülni.
- Tudom, hogy a szakma olyan széleskörű, hogy senki nem tudhat mindent, de ha bármire szükségem van, meg tudom tanulni, mert megvan a szakmai alapom hozzá.
- Kapok pozitív visszajelzéseket a munkámról olyan emberektől, akiket magamnál okosabbnak, szakmailag tapasztaltabbnak tartok.

Minden kollégámnak ajánlom az IT bármely területén, hogy nézzen magába néha, és gondolkozzon el, hogy helyén van-e az önértékelése? Akár csak a fenti három pontot és gondolja végig őket őszintén. Sokat lendítene a szakma színvonalán egy kis tisztánlátás..