Kedvenc hímringyó-kinézetű politikusunk megint adott a szarnak (gyk: az ő imázsa) egy pofont.
Az egész az index "A kormány rosszindulatú torzításnak tartja az amerikai bírálatot" című cikkével kezdődött, amelyre @dajcstomi muszáját érezte kiböfögni magából ezt az újabb gyöngyszemet, hogyaszongya:
Ki a fasz az a Thomas Melia? Minek kell naponta adnunk a szarnak egy pofont?
erre született az index válasz-cikke "Deustch (sic!): Ki a fasz az a Thomas Melia?" címmel.
Megmondom őszintén nekem fingom sincs sem Thomas Meliáról, sem @dajcstomiról, így utóbbinak utánanéztem a twitter lapján látható profilképre kattintva:
Nézzük csak meg kicsit közelebbről!
Igen, úgy tűnik @dajcstomi saját maga szerint is egy névtelen senki, akit azok tartanak el (de minek), akiknek a szolgálatára felesküdött.
Aki már találkozott az imapsync nevű (IMAP szerver közti adatmásolást végző, perlben írt takonygombóc) programmal, jobb, ha idefigyel.
A szerzője -akiről már párszor kiderült, hogy egy arrogáns, beképzelt seggfej, különösebb szaktudás nélkül- különös mód értelmezi a nyílt forrást. A program ezután is szabad, viszont nem lehet a szerzőtől letölteni, ő csak pénzért adja:
> For those of us who might want the last free version, is there any place to
> get it?
Anywhere else from the imapsync homepage.
The license has not changed.
imapsync is still free, open and maybe gratis software.
The maybe nuance is that *I* do not distribute imapsync gratis anymore.
Jó fej, nyílt forrású, szabad szoftver, csak épp ő nem adja ki a kódot ingyen. Tőle csak pénzért vehető.
Ki is tett egy listát, hogy milyen feature-t mennyiért kódolna/gányolna le:
DONE | Feature | Time guessed | Time spent | Money received | Money needed |
---|
No | Backup to files | 20 hours | 60 min | 0 $ | 800 $ |
No | Efficient Gmail backup | 20 hours | 80 min | 0 $ | 800 $ |
No | Better error reporting | 5 hours | 0 min | 0 $ | 200 $ |
Yes | Add cache | 10 hours | 1310 min | 400 $ | 400 $ |
Yes | Speedup 50% | 10 hours | 80 min | 10 $ | 400 $ |
Yes | --delete2folders | 3 hours | 270 min | 90 $ | 0 $ |
Yes | NTLM auth | 3 hours | 300 min | 15 $ | 150 $ |
Yes | Win32 imapsync.exe | 8 hours | 520 min | 45 $ | 240 $ |
Yes | Win32 bug fixes | various | 370 min | 100 $ | 85 $ |
Yes | Fix capability changes | 1 hour | 80 min | 0 $ | 40 $ |
Yes | Large mailbox --maxage | 4 hours | 270 min | 0 $ | 160 $ |
Yes | dkimap support | 3 hours | 120 min | 0 $ | 120 $ |
No | gratis from here | 4 hours | 0 min | 0 $ | 60000 $ |
Az tehát, hogy újból ingyenes legyen ez a nyílt forrású, szabad program 11 millió forintba (60k USD), és négy órányi munkába kerül.
Kemény szakma a perl gányerek élete...
Mióta létezik a Google, tudjuk, hogy a googol 10100-ont, azaz -bitagyúaknak- 2332-nél egy "kicsivel" nagyobb számot jelent. Ha a Google ennyi információt akar összegyűjteni, 7410693711188236507108543040556026102609279018600996098525285376506440296955904 Zettabájtnyi tárolókapacitásra lesz szüksége. Nesze neked ZFS.
De ez a vállalat, amely minden bizonnyal ott van a top 10-ben a tárolt, és a feldolgozott adatmennyiség tekintetében is, valóban mindent géppel csinál?
Ismeretes, hogy a Maps a személyiségi jogok megőrzése végett elhomályosítja az arcokat, és a rendszámokat. A Picasaban is működő arcfelismerés kiterjesztése az egész világra félelmetes gondolatokat szülhet sokakban, viszont a technológia jól mutatja, hogy az emberi arcok megtalálása egy fényképen ma már nem okoz különösebb nehézséget. Logikus tehát a következtetés, hogy a Google gépi úton homályosítgatja nyugati embertársaink arcát.
De nézzük csak meg ezt a képet:
Az oldalról látható nő arca homályos, a plakáton lévő diák arca viszont felismerhető. Ennyire fejlett lenne a technika, vagy a Google googolja nem a szükséges tárolókapacitásra, hanem a náluk dolgozó "majmok" számára utal?
Ha valaki találkozott már ezzel a "nagyszerű" szervezettel, amelyik egész AS-eket rak fekete listára -az idióta pattanásos képű rendszergizdák meg használják, mert azt hiszik, hogy ezzel mekkora májerek-, biztos mondta már magában, hogy ezek buzik.
Nos, úgy tűnik tényleg azok:
Have you been blacklisted by APEWS?
Here is the info you need: There is no-one here who can remove
your IP addresses from *any* block list. APEWS is a blacklist
set up in January 2007 by a group of German/Austrian gay-porn gang
(see below). The same people also operate the uceprotect email
block list at http://www.uceprotect.net. One of the managers is
named: Johann Steigenberger. You can email him at:
j.steigenber...@uceprotect.net .
99.99% of IP addresses blacklisted in APEWS have never
spammed. APEWS has already been labeled as a spite list. This
means the agenda and purpose of APEWS is to blacklist, defame and
libel internet service providers and individuals with whom the
APEWS operator has a personal disagreement or grudge.
[...]
apews/uceprotect/admins.ws operates 2 GAY SITES at smartboys.de
and allgaychat.net/allgaychat.de (view the source to see the
hidden @admins.ws emails at the bottom of their home pages).
So, if you are gay or if you tell them that you are gay even if
you are not(!), you may find apews more helpful to your cause.
LOL.
CouchDB levelezőlista:
There's been a number of people complaining about emails being
rejected as spam when discussing replication. The current theory is
that due to some spam assassin rules that look for the occurrence of
"replica" (as in, fake watches) in subjects and bodies coupled with
sending emails as HTML would be enough to flag a message as spam.
Wunderbar.
Lassan vége az életre szóló választási lehetőségnek, január 31-én lejár a határidő, amit szeretett 0,666-os (gyk: 2/3), matolcsyszta kormányunk ultimátumként odatolt a népének. Kismillió kalkulátorral számolhatjuk ki, hogy mennyire megéri, vagy mennyire nem éri meg MNYP-tag maradni. A magasabb jövedelműek, és egyben a pénzügyileg átlagnál felvilágosultabbak -akik halálig bíznak a kapitalizmus egyik múltbéli alaptételében, mely szerint a részvényárfolyamok rövid távon bár hullámozhatnak, hosszú távon feltétlenül emelkedni fognak- pedig már nyilatkoztak maradásukról, vagy az előbbi tételben, esetleg az AB döntésében bízva, vagy csak egyszerűen dacból.
A MNYP-kérdés szinte teljes vertikumát elemezték már mindenféle írások, demográfiával, részvényárfolyamokkal, befizetésekkel, inflációval és reálhozamokkal kalkulálva, viszont senkitől sem láttam még olyat, ami a következő témákkal foglalkozna:
- az egyik, hogy a mostani 4-5%-os kezelési költség helyetti kétszázvalahány forint mennyire fogja majd ösztönözni a bent maradt kevéske(?) vagyon megfelelő kezelését, és mennyire fogja a törvényi háttér támogatni, hogy valóban reálhozam keletkezhessen az elkövetkezendő pár évtizedben
- a másik pedig az, hogy a mostani törvény szerinti 2000-es taglétszám-minimum miatt az utolsó 2000 bent maradt (és még valószínűleg pár) emberrel mi lesz?
Utóbbi pontra vonatkozóan ugyebár az a jelenlegi állás, hogy a megmaradt tizen-huszonezer tag nem túl egyenletesen szét van szóródva a meglévő MNYP-k között. Ezekből pár ki fog hullani, hiszen nem marad 2000 tagjuk, ők nyilatkozat híján visszakerülnek az állami rendszerbe, nyilatkozatukkal pedig választhatnak, hogy melyik megmaradt MNYP-be kerüljenek.
Új tag ugyebár nem lesz, így az évek során a természetes szelekció (emberek halnak, betegségben, utakon, szórakozóhelyek korlátai által, vagy a megmaradtak migrálnak pénztárak között) folyamatosan amortizálja majd a taglétszámot, egyre több pénztár taglétszáma csökken 2000 alá, ezáltal szűnik meg. Olyan ez, mint a Hegylakó, a végén csak egy maradhat.
De a végén annak is 2000 alá csökken a taglétszáma (persze feltételezve a mai helyzet változatlanságát, azaz hogy nem revideálják a MNYP-ket), így nem lesz már hová menni, az utolsó 2000 ember visszakerül az állami rendszerbe.
Az viszont nem világos számomra, hogy ők mit fognak kapni, hiszen 2011 elején már kiírták magukat az állami szolidaritási rendszerből, így 2011 novembere után (amíg elvileg nem kapnak semmit a MNYP számlájukra) már nem gyűjtöttek szolgálati időt.
Lesz tehát 2000+ (akik elfelejtenek majd nyilatkozni a kihulló pénztárak megszűnésekor) emberünk, aki kb. 40 évig gyűjtögette a pénzét a számláján, jól-rosszul kezelve a megmaradt MNYP-k által, egyre inkább szűkülő választási lehetőségekkel (csökkenő pénztárak száma), akik 30?, 40? év múlva ott lesznek <15 év szolgálati idővel, és átsorolásra kerülnek az állami nyugdíjrendszerbe, így a vagyonuk is elveszik, és nyugdíjat sem fognak kapni (vagy csak nagyon-nagyon keveset).
Persze addig sok minden változhat, és -nem olvastam el a törvényt, lehet, hogy abból egyértelműen kiderülne- az is lehet, hogy tévedek, és azoknak is elismeri az állam a nyugdíj-jogosultságát, és szolgálati éveit, akik ilyen formán kerülnek be majd sok-sok év múlva az állami nyugdíjba.
Hősök vajon a maradók, akiket a ködös jövő kisemmiz majd, vagy átlagpolgárok, akik átlagos (feletti, vagy alatt) nyugdíjat kapnak majd?
ZFS pool-verziók, és azok új funkciói. Hasznos lehet az eligazodáskor a ZFS-káoszban:
Két commitban megérkezett a TRIM support UFS-hez a FreeBSD-be. tunefs-sel (-t enable), vagy newfs-sel (-t) kapcsolható be, értelemszerűen olyan eszközök kellenek hozzá, amelyek támogatják is.
Erősen SSD (flash és firmware) függő szerintem a haszna, vastagon elképzelhető, hogy van, ahol árt...
Kivonat a libev (4.00) changelogjából:
- do not use poll by default on freebsd, it's broken (what isn't on freebsd...).
:(
My NDA with the FBI has recently expired, and I wanted to make you
aware of the fact that the FBI implemented a number of backdoors and
side channel key leaking mechanisms into the OCF, for the express
purpose of monitoring the site to site VPN encryption system
implemented by EOUSA, the parent organization to the FBI. Jason
Wright and several other developers were responsible for those
backdoors, and you would be well advised to review any and all code
commits by Wright as well as the other developers he worked with
originating from NETSEC.
Forrás: http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
Szép kövér wattafakk karira. :)
Minden Nagyok Klubjának ábécé szerinti utolsó tagja, a jáva-frakció elnöke olyan szinten belebolondult a Javába míg a Sunnál gyakornokoskodott (vagy mi), hogy valószínűleg sokan elgondolkodnak azon, hogy a nagy az ember vezetékneve, vagy az arcának méretére utaló jelző lehet-e. Íme a legújabb sziporka:
( NagyZ | 2010. október 22., péntek - 11:47 )
nem a vas a kerdes, hanem hogy milyen inkompetens embereket engednek javaban kodolni. barmikor lealazom neked a C -s webszervered static file kiszolgalasban grizzlyvel, pl.
(najo, nem alazom, de ugyanazt a teljesitmenyt siman hozza egy 5 soros kod.)
meg:
Ez a diskurzus felkeltette az érdeklődésemet, így gyorsan letöltöttem egy öt soros (valójában 164, de legyünk igazságosak: van benne vagy 40 sornyi komment) sample grizzly-webszervert, meg a legújabb nginxet, melléjük pedig a gatling webszervert, amelyhez jön egy HTTP szerver benchmark. A program a webszerver válaszidejét méri, a TCP connect idejét nem számítva.
Íme az eredmény 6-os, 64 bites sunos JDK-val, sokadszori futtatásra, hogy a JIT is tudjon dolgozni, ha akar:
Megdöbbentő, a C-ben írt webszerver még mindig több, mint háromszor gyorsabb, mint a javában írt.
Akit esetleg az érdekelne, hogy miért csak 4095 kapcsolatig megy az ábra, a válasz az, hogy alapból ennyit kezel a grizzly, amin biztos lehet módosítani, de fél óránál nem akartam többet rászánni erre a projektre.
# cat Makefile
lowphas: lowphas.o
cc -o lowphas -lsocket -lnsl lowphas.o
clean:
rm -f lowphas lowphas.o
# vi Makefile
[ ... átírom a cc-t gcc-re, mert cc nincs ... ]
# cat Makefile
lowphas: lowphas.o
gcc -o lowphas -lsocket -lnsl lowphas.o
clean:
rm -f lowphas lowphas.o
# gmake
cc -c -o lowphas.o lowphas.c
gmake: cc: Command not found
gmake: *** [lowphas.o] Error 127
Biztosan el is hinném, hogy ez így jó, azonban kb. másfél percnyi humán elfoglaltság után a gmake-et újfent kiadva a gmake gcc-vel lefordítja a programot.
Közben természetesen semmi sem történt. A partíció UFS, az OS Solaris 10 5/08.
Idén korábban érkezik a javamikulás, és nem csak a HUP-ra!
A HUP-on lefolytatott beszélgetés kapcsán már sokszor éreztem, hogy valahol gyűjtenem kellene a ZFS-sel kapcsolatos olyan hiányosságokat, amelyek az egyre jobban elülő hype mellett megmutatják, hogy koránt sem tökéletes ez a fájlrendszer, és kompromisszumok, tervezési hiányosságok -kövezzetek meg- hibák is előfordulnak benne szép számmal.
Szóval ezentúl ha ZFS-sel kapcsolatos átgondolatlanságba ütközöm, ZFS SUX címkével legyűjtöm majd ide.
Az első legyen a legújabb, amibe épp most belfutottam -nem zwei, nem FreeBSD listából ollózom-, a sendfile és a ZFS ARC találkozása. A ZFS ugyanis a sendfile() és mmap() alkalmazása esetén mind a page cache-ben, mind pedig az ARC-ban eltárolja (eltérő szervezésben, előbbinél pagesize, másodiknál ZFS recordsize) az adatot, duplán másolva azt, nem kímélve a korlátlanul rendelkezésre álló memóriasávszélességet, és CPU ciklusokat.
A jelenséggel itt foglalkoznak:
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-July/029369.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-July/029369.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-July/029654.html (a szövegkörnyezetből nem egyértelmű, hogy a fix mennyire fix, a konkrét módosítást sajnos nem tudtam megtalálni)
Van aki az életét tette rá a témára:
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-July/029654.html
A fentieket elolvasva érthetővé -de legalábbis halványan pislákolóvá- válnak azok az esetek, amikor az ARC lassabb, mint más, elvileg lassabb források (például maga a diszkalrendszer).
Andrew, David, Galen, apa elkúrta. Nem kicsit, de nagyon. :(
Diff a FreeBSD HEAD-ből:
- /*
- * XXX the map must be locked for write on entry, but
- * there's no easy way to assert that.
- */
-
+ KASSERT(vm_map_locked(map), ("kmem_back: map %p is not locked", map));
Végre valaki (davidxu@) lépett, és megírta a kqueue NIO selectort, amely be is került a jdk16 portba.
Újabb pont, amit kipipálhatunk a FreeBSD más OS-ekkel szembeni lemaradásokat tartalmazó listájáról.
Bzmeg, ilyen nincs, és mégis van:
A holokauszt meghatározó vonatkoztatási ponttá vált a XXI. századi európai kultúra számára, a multikulturális, egyenlőség elvű és autonóm - ugyanakkor másokkal szolidáris - egyénekből álló társadalom ideáljának negatív szimbóluma maga Auschwitz lett. A holokauszttal való szembesülés nem kizárólag a történelemórák, hanem az oktatás egészének feladata.
Beszarás.
Értem én, hogy az Android a plázacicák tucatterméke, de a 2.2-es verzióra már csak eljuthattak volna odáig, hogy a következő dolgok működjenek:
- multi PDP support (ez akár MMS-nél is fárasztó lehet, de egy vállalati környezetben, ahol az internet, és a céges hálózat más APN-en jön, egyenesen használhatatlanná teszi a telefont)
- ennek hiányában legalább tudna automatikus váltást az APN-ek között a lekért hostnév alapján. Kézzel váltogatni agyhalál, nem beszélve arról, hogy eleve lehetetlenné teszi az automatikus syncet, push emailt
- szerver (Exchange) oldali keresés az e-mailek között
- GAL lookup a kontaktoknál, beemelés a helyi kontakt listába onnan (elvileg vehetek a marketről ilyen programot: anyád)
- a tesztként megnyitott levélben éppenséggel egy word doc volt, az OS ehhez sem tartalmaz önmagában supportot
Ezek hiányában az Android sok embernek (aka üzleti felhasználás) csak egy gyémántporral teleszórt takonygombóc, olyan nélkülözhetetlen feature-ökkel, amelyeket az ősöreg WinMo-k is tudnak, hogy az állandó versenytársat(?), az iphone-t ne is említsük.
Azt hiszem a következő telefonom sem androidos lesz.
Aki a stable/8-nál is frissebb ZFS-t szeretne -esetleg a unix kvóta támogatás miatt-, annak nem kell két hónapot várnia (ennyi idő múlva van tervbe véve a trunkből való visszaolvasztás). Az alábbi patcheket kell feltennie a stable/8 forrásra:
http://people.freebsd.org/~mm/patches/zfs/v15/stable-8-v15.patch (zfs
version 15)
http://mfsbsd.vx.sk/zfs/head-9749-9866.patch (ABE)
http://mfsbsd.vx.sk/zfs/head-9788.patch (memory corruption bugfix)
http://mfsbsd.vx.sk/zfs/head-9909.patch (locking bugfix)
http://mfsbsd.vx.sk/zfs/head-9981-10143-10232-10250-10269.patch (stat
and rrwlock speedup)
http://mfsbsd.vx.sk/zfs/head-10143-addon.patch (adds missing difference
for previous patch if 9749-9866 is used)
... legalábbis a FreeBSD-ben, az alkalmazhatóság területén.
A ZFS egyik nagy hiányossága volt, hogy nem kezelt user/group kvótákat, így olyan helyeken, ahol a fájlok szétszórva helyezkedtek el, vagy bár az elhelyezkedésük megfelelő lett volna, de túl sok fájlrendszert (százezrek, milliók) kellett volna létrehozni, az általa kínált megoldás használhatatlan volt.
Szerencsére ezen idővel túltették magukat a fejlesztők, és a ZFS 15-ös verziójában megjelent a user és group kvóta (még ha egy bazi nagy hák is, de ezt már megszokhattuk ettől a fájlrendszertől). Beletelt egy kis időbe, de végre belekerült a FreeBSD-be is, így most már csak a deduplikációra várunk, aztán sajnos úgy tűnik búcsúzhatunk az OpenSolaristól, így nem lesz honnan leechelni.
Lehet viszont majd bizonyítani, hogy mennyire életképes egy fejlesztő nélküli fájlrendszer... :-O
Nem kritikus bug report a FreeBSD-hez:
Number: | 147479 |
Category: | misc |
Synopsis: | Dan Moschuk has passed away, calendar patch |
Severity: | non-critical |
Priority: | low |
A fáraók még tízezrek verejtéke árán piramisokat, és sírkamrákat építtettek, de ma már elég a halhatatlansághoz, ha FreeBSD-t fejlesztesz!
Minden évben eljön a fájdalmas elszámolás ideje: összesítjük, hogy nehezen megkeresett forintjaink hány százalékát viszi el a korrupt, bohócokat a kirakatban tartó maffia, és lerójuk kegyeletünket egy kisebb vagyon formájában az extra, becsületesen bevallott, és megszerzett jövedelmek (kurvák futtatása, szerencsejáték, szerv-, fegyver-, drog- (hello buci!) és radioaktív elem-kereskedelem) utáni járulékok, adók megfizetésével.
Ebben az évben azonban különös ajándékkal kedveskedtem legfőbb nemzeti pénzszivattyúnknak, remélem megharagudnak, és visszautalják a pénzt.
sajnos nem ertem azt az osmagyart, hogy "meg regelezni", de bizony ab -vel _en_ teszteltem (nem, nem azonos gepen futottak, hanem 10-15 gep rangatta, gigabiten). te elmondhatod ugyanezt, vagy csak a nagyvilagba tolod?