LibreSSL

OpenBSD

Nemrég volt szó arról, hogy az OpenBSD-sek nekiálltak kidobálni minden olyan dolgot az OpenSSL-ből, ami számukra szükségtelen, nekiálltak a kód megfelelő formára hozásának stb. Nem csak arról van szó, hogy némi takarítást végeznek. A The OpenBSD Foundation és az OpenBSD Project támogatásával létrejött a LibreSSL projekt.

A projekt kezdetleges weboldala szerint a LibreSSL az SSL/TLS protokoll egy szabad változata, amely az OpenSSL forkolásával jött létre. Egyelőre OpenBSD-hez reszelik. Multi-OS támogatás akkor érkezik majd, ha a kódot megfelelő mértékben gatyába rázták, ha feláll egy megfelelő csapat, aki a portabilitásért felel majd és sikerül megfelelően (támogatásokkal) alátámasztani a projektet anyagilag.

A LibreSSL fejlesztését elsődlegesen az OpenBSD Project végzi, debütálása operációs rendszerben az OpenBSD 5.6-ban fog megtörténni. A LibreSSL fejlesztését anyagilag a The OpenBSD Foundation és a The OpenBSD Project támogatja. Akinek tetszik a kezdeményezés, az fontolja meg annak támogatását.

( uid_4656 v | 2014. 04. 22., k – 09:32 )

Tudatlanságból kérdezem, nem ítéletet mondva: nem lett volna jobb a tisztításhoz hozzájáruló patcheket elküldeni az OpenSSL-nek? És esetleg a fejlesztésre szánt pénzt is? Így most nekem úgy tűnik, hogy szépen szétforgácsolódnak a fejlesztésre rendelkezésre álló erőforrások.

A "rossz" egy relatív fogalom. Kinek a szemszögéből és miért rossz? Kinek az érdekeit képviselik? Honnan nézzük? Az OpenBSD úgy döntött, hogy jobban járnak, ha kezükbe veszik a dolgot.

de Raadt véleménye az OpenSSL csapatról:

"OpenSSL is not developed by a responsible team."

Hogy ez azt jelenti-e egy, a biztonságot a zászlója csúcsára tűző projektnél, hogy "rossz"? Szerintem igen.

--
trey @ gépház

Parttalan viták gyakran több energiát fogyasztanak mint egy önálló ágon futó fejlesztés. Az OpenSSH fejlesztése kiválóan megy az OpenBSD-seknek. Valószínűleg egy önálló SSL-lel is boldogulni fognak.
A névválasztásnak annyi a pikantériája, hogy itt pont mások stipi-stopizták az Open- előtagot, és azt kell más néven forkoli.

"Parttalan viták gyakran több energiát fogyasztanak mint egy önálló ágon futó fejlesztés."

Ez az egyik dolog. A másik az, hogy hiába küldene az OpenBSD projekt egy rakás patchet az OpenSSL-nek, ha az utóbbinak vezetése

- felelőtlen (Seggelman megint be[b|g]ombázik és patchet küld, amit alapos átnézés nélkül commit-olnak)
- szakmailag kevés (a patchet hozzáértés nélkül commit-elik, nem megfelelő emberek a karbantartók stb.)
- korrupt (NSA / corporate shill-ek ülnek a vezetésben)

stb.

--
trey @ gépház

( tompos v | 2014. 04. 22., k – 09:48 )

A site-on az openssl link egy dalra mutat a youtube-on.

Nem ertem en amugy, hogy a sok nagyarcu beszolos el van borzadva, hogy hogy nez ki az openssl, beleertve az openbsd-t. Eddig is ilyen volt, hasznaltak.
Ha tudtak rola, miert nem tettek ellene (bunosok kozt cinkos, aki nema).
Ha nem tudtak rola, akkor meg mire van nagy arcuk, voltak olyan ostobak, hz ultrasecure OS-ukbe beraktak auditalas nelkul vmit, amire 10 evvel kesobb kiderul, hogy egy rakas szar. Csondben meghuznam magam:)

t

Azt valószínűleg látták, hogy rossz a kód minősége, de épp ezért nehéz benne észrevenni az ilyen hibákat, valószínűleg nem volt erőforrásuk ezt olyan szinten végig nézni, hogy ez kiderült volna. Amíg be nem bizonyult, hogy funkcionális hibák is vannak benne, addig nem az volt az elsődleges prioritás, hogy átirják a régi kódot szépre.
Sajnos nem lehet mindig mindent 100%-osan végig ellenőrizni, amit használsz, mert a világ összes ideje sem elég rá.

------------------
My Open-Source Android "Projects"

Az opensslrampage cikkei szerint meg nekem, amator nezelodonek is nyilvanvalo, hogy nem 100%-osan, hanem 1%-osan kellett volna csak belenezni es nyilvanvalo lett volna, hogy csak ido kerdese.
Egy core infrastrukturalis komponensnel ez lenyeges-e? Remelem, ez nem kerdes.

Ezek alapjan az openbsd fejlesztok sem sokkal kevesbe felelosek, h betettek az openssl-t az openbsd-be es ott tartottak hosszu eveken keresztul. Theo odarakhatja a nyelvet az openssl team segge lyukahoz, mert csak egy hangyafasznyival vannak elobbre.
Megvolt az ideje, tudasa es eroforrasa es elvileg a celja is.

tompo

Nem kell ahhoz nagy arc, h az ember belassa, h teljesen mindegy, h opensource vagy proprietary a kod, a donto tobbsegenek a minosege kritikan aluli, minel inkabb bazar, annak inkabb. Ezert tudott peldaul a Coverity is regebben mig szuksege volt hirverest kelteni azzal, h ingyen es bermentve kod auditalt open source projekteket. Vagy ezert nez ki ugy az OpenSSL ahogy, h ontopic maradjak. :)

---
pontscho / fresh!mindworkz

Igen, az, itt nem megy. De akkor csak itt. Ez tulajdonképpen jó hír.

Update: Most is elérhetetlen innen. Állítólag a Savvis a szolgáltatójuk, a számok meg magukért beszélnek.

http://www.internetpulse.net/

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Ezen open-source projektek mogott cegek allnak, akiknek erdeke, hogy normalisan hasznalhato, a fejlesztok szamara is jo minosegu szoftvert csinaljanak. Hiszen szamukra a fejlesztok a piac, es nem a vegfelhasznalok.
Amugy a Hibernate es a tobbi JBoss termek kb. kizarolag XML-alapu konfiguralasa agyfasz.

Az, hogy áll e mögötte cég vagy sem, az itt nem volt szempont (mellesleg az Apache commons-* mögött szerintem nem áll cég). Másrészről meg ezek a projektek (guava-t leszámítva) előbb léteztek, mint hogy cég és vállalkozás nőtt volna mögéjük. Azért nőtt mögéjük vállalkozás, mert sikeresek voltak. És lehet folytatni a sort: joda-time, ehcache, slf4j+logback, jetty, jboss, quartz.

Evek ota kenytelen vagyok figyelni az openssl koruli valtozasokat (mikor evekkel ezelott egyszer egy forumon elmeseltem, h a kodja meg a linux kernel 2.4.18-nal is ocsmanyabb akkor majdnem megkoveztek, h mind a ketto az OS csimborasszoja) es bizony ehhez sem kell nagy arc.

---
pontscho / fresh!mindworkz

Miert *kotelessege* pl. Pontschonak ujrairni az openssl kodjat?
Ujrairas nelkul nem lehet velemenyt formalni?

Miert *kotelessege* barkinek is ujrairni a kodot? Rengeteg *nagy ceg* is hasznalja az openssl-t, most vegre valaki nekiult *dolgozni*, miert is kellene pont ot szarral dobalni?

Miert nem mesz neki mondjuk a Google-nek a Facebooknak, vagy barmelyik nagy cegnek, akik szinten hasznaltak (es epitettek ra!) az openssl-t? Nekik tobb *eroforrasuk* lett volna aktivan reszt venni a fejlesztesben.

Azert ez az openbsd team nem olyan hude nagy....

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

> Miert *kotelessege* pl. Pontschonak ujrairni az openssl kodjat?

He?

> Ujrairas nelkul nem lehet velemenyt formalni?

Ejha. Mivan?!

> Miert *kotelessege* barkinek is ujrairni a kodot? Rengeteg *nagy ceg* is hasznalja az openssl-t, most vegre valaki nekiult *dolgozni*, miert is kellene pont ot szarral dobalni?

Olvasd vissza, amit irtam.

> Miert nem mesz neki mondjuk a Google-nek a Facebooknak, vagy barmelyik nagy cegnek, akik szinten hasznaltak (es epitettek ra!) az openssl-t? Nekik tobb *eroforrasuk* lett volna aktivan reszt venni a fejlesztesben.

Olvasd el ujra, amiket irtam. Vagy csak keress a google-ra..

t

Bocs, hogy nem vagyok eléggé hupceleb, de szerintem a kódminőséget nem a fost szarrá pofozó maintainer pofájára mérik.

Teljesen mindegy, hogy milyen kód. Arról van szó, hogy használnom kell (mert még mindig előrébb vagyok vele, mintha nekiállnék nulláról lefejleszteni), és látom, hogy szar, de nem lehet mindent helyrepofozni.

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

Eppenseggel nem arrol van szo.
Arrol, hogy az openbsd a biztonsagot tuzte a zaszlajara. Kozben epp csak egy core komponenst tartottak benn minden nemu vizsgalat nelkul. Mennyivel felelosebb az o viselkedesuk, mint aze, aki belefejlesztett egy bugot? A vegeredmeny ugyanaz.

De tovabbra is, fel lehet hozni ezer masik kozosseget vagy ceget. A google szertepofogi, h ok mar csak ssl-en szolgaltatnak, az biztonsagos, kozben annyira nem vettek a faradtsagot, h az egesz alapjank egy _picit_ utananezzenek.

Persze google john legalabb nem beszel a masik felelossegerol, nagyarccal.

t

Ha jol ertem, azt mondod, hogy az OpenBSD-nek mindent, egyszerre ujra kene irnia. Ez egy egesz jo modell lenne, ha a fejlesztoi kapacitas vegtelen lenne. Hja de kerem, egy 300k soros crypo libet nullarol ujrairni az trivialis... Azt amugy tudod, hogy a library, mint olyan, mire valo? Bar a fenti kommented alapjan nyilvan nem.

Egyebkent pedig:

OpenSSL is written by monkeys

/*!
* Load CA certs from a file into a ::STACK. Note that it is somewhat misnamed;
* it doesn't really have anything to do with clients (except that a common use
* for a stack of CAs is to send it to the client). Actually, it doesn't have
* much to do with CAs, either, since it will load any old cert.
* \param file the file containing one or more certs.
* \return a ::STACK containing the certs.
*/
STACK_OF(X509_NAME) *SSL_load_client_CA_file(const char *file)
...

Azzal az lehet a baj, hogy lehet, hogy vannak olyan dolgok amit mindig el kell végezni, akkor is ha hiba van, akkor is ha nincs, előbbi esetben a hibakezelés után. Ebben az esetben nem lehet visszatérni az if (0) előtt, vagy kódot kell duplikálni.

Meg sem árt, ha minél kevesebb exit point van egy függvényben.

de nekem nem tunik olyan ganynak: van 4 hiba hely ami utan fel kell szabaditani a ret-et + felszabaditani a lefoglalt mas memoriakat. rendes futas eseten csak a sima memoriat kell felszabaditani.

persze lehetne a goto helyett felszabaditani "helyben" a ret-et, de gondolom cel is volt hogy keruljek a kod duplikaciot.

biztos lehet szebben is megoldani, majd egy c guru leirja... :)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

És még te tartod magad mindenek felett álló szoftverfejlesztőnek? Annyira egyértelmű, hogy a procedúrán ennyire kívülálló goto flagnek (főleg ha hibáról szól) a return ret; után van a helye. De igazad van, a C hibája, hogy ehelyett beletaknyoltak a kód közepébe egy if(0)-t. Eddig azt hittem, hogy aki try, catch, finally-t látott már az is automatikusan odatenné, mert ott a logikus, hiba a végére, de nem, szerinted tök normális ez a közepén, hogy if(0) és belegotozunk egy feltételes szerkezetbe (ami mondjuk még mindig eggyel kevésbé csúnya, mint vezérlési szerkezet közepére gotozni, de ettől még ez is gusztustalan marad).

"És még te tartod magad mindenek felett álló szoftverfejlesztőnek?"

Hol írtam ilyet?

" Eddig azt hittem, hogy aki try, catch, finally-t látott már az is automatikusan odatenné"

Vegyél már vissza az arcodból. Mondtam én, hogy _ez_ normális?

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

Na, megnéztem közben az eredeti kódot is. Azért egy picit árnyalja a képet. Egyrészt van még kód bőven a } után is. Szóval nem igazán tudod hova rakni. Gyakorlatilag try-finally-ra lefordítva ez egy függvény közepén lévő finally blokk, aminél a try rész a függvény 12. sorában lenne. Igen, ocsmány, de ezt tudod megcsinálni C-ben. Perpill nem is nagyon van rá jobb ötletem. (Illetve van, de az még rondább lenne).

De halljuk, hogyan lenne szebb ez a függvény C-ben, segédváltozó bevezetése nélkül?

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

"De halljuk, hogyan lenne szebb ez a függvény C-ben, segédváltozó bevezetése nélkül?"

Hallod, pont egy segédváltozós megoldást akartam bekommentelni egy nem sokkal efölött lévő komment fölé (ami szebb is, jobb is, olvashatóbb is). Segédváltozó nélkül tényleg csak annyit tudsz, hogy az utolsó 4 sort fellabelezed finally:-nak, return után meg err: és a végén a finally-ra gotozol (szerintem ez is szebb eggyel, de tényleg nem sokkal)

Tömörebbet nem is állítottam csak szebbet. Mert a vezérlési szerkezetbe vagy feltételes szerkezetbe gotozni csúnya dolog, a goto a procedurális gondolkodás része, a feltétel az ugrás előtt kell hogy legyen.

(Csak sokan ezt nem fogják fel, meg zt sem, hogy a gotot lehet ésszel is használni, ezért inkább csak annyit mondanak: "a goto rossz és ne használd")

Na de ha nem akarunk bevezetni segédváltozót (és miért is tennénk, plusz memória és semmi szükség rá), valamint megegyezhetünk abban, hogy a kódok sorrendjét nemigazán lehet felcserélni (lévén, hogy az if (0) {} utáni felszabadításnak ugyanúgy meg kell történnie), nagyon más megoldást nem látok annál, hogy 


void bizbasz(...)
{
  // blabla, ha hiba van goto err

  if (0) {
  err:
    // tralala
  }

  // asdfasdf
}

helyett ezt írod: 


void bizbasz(...)
{
  // blabla, ha hiba van goto err

  goto hurra;

  err:
    // tralala
  
  hurra:

  // asdfasdf
}

Amivel effektíve ugyanott vagy, kétlem, hogy az if (0) helyett más fordulna be oda. Egyik ocsmány, mert vezérlési szerkezetbe ugrasz, másik ocsmány, mert goto halmok hegyeit tartalmazza. Ezen kívül már csak a kódduplikálás van.

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

Igen is meg nem is. Sokak szerint az a szep, mert nincs goto akkor, masok szerint felesleges ram, CPU utasítás (bár értelmes fordító kioptimalizalhatja. De a lényeg az, hogy mindket esetben hiányzó nyelvi elemért kiált a dolog.

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

És pl. egy ilyen konstrukció (ilyesmi a Linux kernelre a jellemző)?
Csak a visszatérési értékre van segédváltozó, azzal meg a legtöbb fordító tud mit kezdeni. Kb. a kivételkezelés-féle stack visszagörgetést-destruktor hívást játszod le. Persze nyilván nyelvi elemmel kulturáltabb lehetne. De az openssl-féle "megoldást" nem tartom elfogadottnak, ha ilyet is lehet: 


a=get_a();
if(!a){
   retval=-ENAGYABAJ;
   goto err_a;
}
b=get_b()
if(!b){
   retval=-ENAGYABAJ;
   goto err_b;
}
goto ret_success; /* egy bemenet – egy kimenet */
err_b: 
  free_a(a_ptr);

err_a: 
ret_success:
  return retval;

Egyébként nagyon akarsz, tudsz kivételkezelést megvalósítani C-ben, igaz, nem nyelvi elemként, inkább csak érdekességként írom (nem használnám): http://www.on-time.com/ddj0011.htm

Aki a segédváltozó vs. goto témakört általánosságban meg akarja válaszolni, az nem ért hozzá.

A segédváltozó általában szebb, jobban olvasható, könnyebben áttekinthető kódot eredményez. Cserébe több prociidőt és memóriát igényel. Ha egy fél óra futásidejű program végrehajtása során egyszer jut arra az ágra, ahol ezt végre kell hajtani, akkor ez a jobb megoldás.

A gogo általában átláthatatlanabb, error-prone-abb (hogy mondják ezt magyarul?) kódhoz vezet. Cserébe kevesebb prociidő és memória kell neki. Ha a fél óra futásidejű program az idő nagy részét abban a ciklusban tölti, ahol ezt kell végrehajtogatnia, akkor a goto a jobb megoldás, mert ha nem goto lenne, akkor lehet, hogy fél óra helyett 35 perc lenne a futásidő.

Általában viszont mindaddig, amíg be nem bizonyosodik, hogy a teljesítmény a szűk keresztmetszet, érdemesebb a segédváltozós megoldást alkalmazni. Ennek az oka, hogy ha a teljesítmény nem gond (és nem szokott az lenni, illetve nem ilyesmik miatt szokott az lenni), akkor mindenképpen érdemesebb a szebb, módosíthatóbb, refaktorálhatóbb stb. - jobb programozói élményt nyújtó módszert választani.

Én azt tanultam, hogy premature optimization is the root of all evil.

Szerintem egy olyan kódot, amit várhatóan 1-nél többen fognak olvasni / használni, olvashatóra és karbantarthatóra kell megírni.

Goto nélkül, strukturáltan, kommentekkel.

Ha kész, jól működik, és kiderül, hogy lassan fut a fordító által elkövetett optimalizációk ellenére is, akkor meg lehet nézni, hogy mi miatt.

Ha azt találnám, hogy egy szép és jól olvasható kód kézzel csúnyává szétfaragása jelentősen gyorsítana egy tényleg időkritikus részt, lehet, hogy széttúrnám. Nem biztos. Feladattól és követelményektől függ.
De biztos nem túrnám szét, ha bármiféle biztonsággal vagy titkosítással kapcsolatos feladata lenne a kódnak.

Ránézésre ez a lib (akármiSSL) nem végez olyan feladatokat, amik időkritikusak, szerintem semmiféle kézi csúnyává optimalizálásra nem lehet mentség.

Egyébként, amikor még programozóként dolgoztam, voltak olyan feladatok, amiket jelentősen gyorsítani kellett ezért sokat vizsgálgattuk profilerrel a futást. Nem emlékszem egy esetre sem, amikor egy segédváltozó létrehozása okozott volna akkora overhead-et, hogy azt kellett volna valahogy kioptimalizálni kézzel.
Vagy azért, mert a fordító már úgyis kioptimalizálta magától, vagy azért, mert az overhead pici volt a valóban lassító tervezési hibák mellett.

Vannak helyzetek amikor igenis szamit, pl. az ujabban elterjedt/terjedoben levo streaming szolgaltatasoknal nem mindegy, h 1 v. 0.1s alatt titkosit a koceraj, de meg a sima web kiszolgalasnal sem mindegy, nem egy statisztika es benchmark keszult az utobbi idoben pl. az ssh handshake lassusagarol es mikepp lehet tetemes (akar 30%) betoltesi idot nyerni egy kis ssl tuninggal.

---
pontscho / fresh!mindworkz

Ugye nem kevered az SSL accelerátort a HSM dobozokkal?
Ha nem: SSL-t hol használnak nagy tömegben? Ismereteim szerint VPN-hez és https protokollhoz. Előbbihez valószínűleg jól jöhet bizonyos esetekben egy ilyen gyorsító kártya, de az igazán nagy tömegben használt https esetében...
Nem tudom, igaz-e, de épp ma olvastam, hogy _állítólag_ a googlenél a https-re való áttérés kb. 1%-os CPU használat növekedést okozott. Ez persze akár UL is lehet, de weben nem okoz akkora plusz terhelést, hogy emiatt szükség legyen ilyen gyorsításra. (vagy tudsz ellenpéldát?)

Nem tudom, igaz-e, de épp ma olvastam, hogy _állítólag_ a googlenél a https-re való áttérés kb. 1%-os CPU használat növekedést okozott.

Egyreszt nem mindegy gepparkon, az 1% is mocskos sok tud lenni. Masreszt valozinuleg ez koszonheto vagy egy hw ciphernek es/vagy a mar elvegzett optimalizacionak. Nyilvan nem egy nyers koddal fognak dolgozni, foleg ha mar az utolso putter via c3-ban is ott figyel egy padlock.

---
pontscho / fresh!mindworkz

Ha egy kliens egy weblapot használ, a teljes időnek illetve a teljes számítási kapacitásnak vajon mekkora része esik az OpenSSL-re?

Nem mértem ki, mivel nem fejlesztettem ilyesmit, de feltételezem, hogy kevés.

Pl. arra számítanék, hogy a UI renderelés, illetve a másik oldalon az adatbázisból az adatok előkeresése illetve magának az adatnak a hálózaton áttolása több nagyságrenddel lassabb, mint a titkosítás szőröstül bőröstül.

De ettől függetlenül, ha most konkrétan az OpenSSL-t akarnánk gyorsabbá tenni, szerinted valaki kimérte azt, hogy az adott függvény a lassú, és éppen a segédváltozó miatt, vagy egyszerűen a programozó eldöntötte, hogy így írja meg, mert szerinte így gyorsabb?

Nem tudom a választ, de az a sejtésem, hogy a második.

Volt olyan kollégám, aki mindenféle trükkökkel írt C-ben kódot elsőre, merthogy úgy gyorsabb lesz. Aztán amikor megnéztük, kiderült, hogy a gcc pontosan ugyanarra az assembly programra fordította le, mint az agyontrükközetlen változatot.

Na ez az, ami szerintem nagyon rossz megközelítés.

Egyébként a kérdésedre válaszolva, hogy mi az, ahol szerintem szempont a sebesség:
az én múltamban ezek fordultak elő:
- játék - adott hw követelményből kihozni a legjobbat. Férjen bele még több pont, még több 3D effekt és számolás, de ne essen az FPS x alá adott procival és videokártyával; a video lehessen még nagyobb felbontású és hosszabb de a 4x sebességű CD-ről azért le lehessen játszani; az AI tudjon tovább előre gondolkodni, több esetet megvizsgálni, hosszabb utat keresni anélkül, hogy a neki engedélyezett időnél többet használna.
- real time rendszer, hálózat minőség mérése, adatfeldolgozás - minél több mérőeszköz adatáramát tudja feldolgozni egy számítógép
- adatok tárolása adatbázisban (fájl betöltés és eltárolás legyen meg 15s alatt, pl. amikor alapból 30 percnél indult az első változattal, másik esetben néhány fájl betöltése max. 2 óra alatt, miközben a régi rendszernek 24 óra nem volt elég).
- adatok visszakeresése adatbázisból (pár tíz millió adatrekord, egy időben 1000 kérés, 1 másodperc alatti válaszidő weblap rendeléssel együtt). Aztán folyamatosan jönnek az új kérések, bonyolítva a lekérdezést, de az NFR nem változik.

Ezekben az esetekben mindenhol jól azonosítható volt egy konkrét szűk keresztmetszet, amit javítani kellett.
Hiába javítottunk volna más rendszerkomponenst, vagy csak még több félig feldolgozott adat gyűlt volna fel az igazi problémás elem előtt, vagy amikor végre valami kijött, az gyorsabban ért volna el a cső végére - de az idő még nagyobb részében várt volna az a feldolgozó sor.

Ahogy azt korábban is írtam:

Amíg egyedül dolgozik, hobbi projekten, addig úgy írja meg, ahogy tetszik.

Ha többen dolgoznak, használják, karbantartják, akkor érdemes megbeszélni, hogy milyen stílust kövessen mindenki.

A fenti példában az az egy ember a közösen megbeszélt stílustól eltért, és erre az volt a magyarázata, hogy mert így majd gyorsabb lesz.

"segédváltozó"

Naja, csak az emberek nagy része akkor kezd el gotot használni, mikor a segédváltozó bevezetésére csillió helyen át kellene szerkeszteni az if-eket. Arról persze, megint el lehet vitatkozni, hogy mi a szebb: 1(+) segédváltozó bevezetése vagy egy jól definiált pontra ugrani. Véleményem szerint bizonyos esetekben sokkal szebb az utóbbi.

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

( tntwormz | 2014. 04. 22., k – 10:43 )

Már csak azt nem értem, hogy voltak képesek weboldalt készíteni ezzel a ronda betűtípussal.

( manfreed (nem ellenőrzött) | 2014. 04. 22., k – 14:49 )

szóval ezután ami open volt, az libre lesz. Már várom a következőket: librearena, librebsd, libregl, libredns, libressh, libreelec, librejdk, librettd, librevpn, librewrt, ...

és természetesen hívjuk ezeket libresource alkalmazásoknak :)

( ssikiss | 2014. 04. 23., sze – 15:46 )

Na akkor mikor fog kifingani az OpenSSL projekt?

( uid_7086 | 2014. 04. 24., cs – 11:10 )

Troll: most jöttem rá, hogy ez az egész egy L-es méretű intim betétről szól. :D
Update: lehet, hogy nem csak itthon divat a "tisztább, szárazabb, biztonságosabb érzés" szlogen? Még a végén kiderül, hogy én trollkodok, ők meg pont ezért választották ezt a nevet... :D

Hát, sajnos a Libre szót és származékait Magyarországon igencsak lejáratták.

Az emberek 99%-ának egy szakállas piros-zöld szemüveges okostojás jut eszébe, aki kiáll a TV-be és elmeséli, hogy minden embernek jogában áll az étteremben tele szájjal zabálni. Miért is ne csámcsoghatna, ha őt ez teszi boldoggá?

Namost a Liberofiszról, meg LibreSSL-ről nekem rögtön a félhülye liberális megmondóemberek jutnak eszembe és igencsak nehezemre esik a programra ezek után ráklikkelni. Szerencsésebb országokban talán nincs az embereknek efféle komplexusa a Libre szó hallatán.

Azt értem, hogy te mire asszociálsz a libre szóról, de azt nem tudom, hogy honnan jött az asszociáció.

Én a konkrét szóval csak portugál nyelvet tanulva találkoztam, hasonló szó lehetett esetleg a libress betét márka meg a libri könyvesbolt.

De szakállas piros-zöld szemüveges okostojásra nem emlékszem, aki ezt a szót használta volna.

Miről maradtam le?

Magyarországon a liberálisok valahogy fejjel lefelé látnak mindent. Az átlag ember tudja, hogy mi a jó, mi a rossz, de ezek mintha a Marsról jöttek volna és egyáltalán nincsenek képben a helyi viszonyokkal. Piros-zöld szemüveges idióták, akik ontják magukból a bölcsességeket.

Gondolj a jogvédőkre (pl. TASZ), akik felemelik a szavukat a gonosz férfi ellen, aki szegény ártatlan romát fagyállóval mérgezte meg, mert rászorultságában lopott a borából...

De veheted a szocialistákat is, akik Borsod megyében a demokrácia és sajtószabadság védelméről papoltak. Arra nincs pénz, hogy újságot vegyenek.

Nyilván nem kell csodálkozni a Jobbik eredményén, csak azon, hogy még volt, aki rájuk szavazott.

Ha már...
"Szerencsésebb országokban talán nincs..."

Nem tudom, szerinted Németország a szerencsésebb országok közé tartozik-e, de a liberálisokra (mint politikai mozgalomra) ott is úgy néz a többség, mint a véres takonyra, amit éppen a vasárnapi levesbe tüsszentettél. Elvtelenek, elitisták, haszonlesők, stb. A Libre szó mégsem vált ki ilyen görcsös reakciókat, még a nácizmus szülőföldjén, Münchenben sem.

Amúgy nagyjából nekem is az a véleményem, mint a németeké.

________________________________________
"The vision of Christ that thou dost see
Is my vision’s greatest enemy."