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:

suckit: image

 

Nézzük csak meg kicsit közelebbről!

suckit: image

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:

DONEFeatureTime guessedTime spentMoney receivedMoney needed
NoBackup to files20 hours60 min0 $800 $
NoEfficient Gmail backup20 hours80 min0 $800 $
NoBetter error reporting5 hours0 min0 $200 $
YesAdd cache10 hours1310 min400 $400 $
YesSpeedup 50%10 hours80 min10 $400 $
Yes--delete2folders3 hours270 min90 $0 $
YesNTLM auth3 hours300 min15 $150 $
YesWin32 imapsync.exe8 hours520 min45 $240 $
YesWin32 bug fixesvarious370 min100 $85 $
YesFix capability changes1 hour80 min0 $40 $
YesLarge mailbox --maxage4 hours270 min0 $160 $
Yesdkimap support3 hours120 min0 $120 $
Nogratis from here4 hours0 min0 $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...

Stallman és a pedofília

2011.03.27. 09:11

Stallman a lábról evés mellett a gyerekeket is szereti.

Google: googol million monkeys

2011.03.06. 19:16

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:

suckit: gmaps

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?

 

UCEPROTECT: ezek buzik

2011.02.20. 10:56

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.

Spamassassin fail

2011.02.13. 10:58

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.

suckit: hosok

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?

suckit: intelneon.png

ZFS funkciók

2011.01.01. 19:27

ZFS pool-verziók, és azok új funkciói. Hasznos lehet az eligazodáskor a ZFS-káoszban:

Nevada
Build
Version
Introduced
Features
Added
36 1 ZFS introduced*
38 2 Ditto blocks for meta-data
42 3 Hot spares
Double-parity raidz
62 4 ZFS command history
5 Added gzip compression
6 ZFS boot
68 7 Added slogs
69 8 Delegation
77 9 CIFS support
Filesystem-specific quotas
78 10 L2-arc
94 11 Improved scrub/resilver performance
96 12 Snapshot user properties
98 13 New "snapused" readonly property
103 14 Added passthrough-x to aclinherit property
114 15 User and group quotas
116 16 STMF property for COMSTAR
120 17 Triple-parity RAID-Z
121 18 ZFS snapshot holds
125 19 ZFS log device removal
128 20 ZFS Deduplication Properties, zle compression
128 21 ZFS Deduplication Properties
128 22 ZFS receive properties
135 23 Slim ZIL
137 24 System attributes
140 25 Improved pool scrubbing
141 26 Improved snapshot deletion performance
145 27 Improved snapshot creation performance
147 28 Multiple virtual device replacements
148 29 RAID-Z/mirror hybrid allocator
149 30 ZFS encryption
150 31 Improved 'zfs list' performance

 

TRIM support UFS-hez

2010.12.30. 20:35

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...

FreeBSD is broken

2010.12.28. 20:57

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:

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?

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:suckit: ajavaazisten.png

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.

Solaris: a legeslegfaszább OS

2010.10.07. 16:30

# 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.

Javamikulás

2010.09.28. 09:22

Idén korábban érkezik a javamikulás, és nem csak a HUP-ra!

suckit: javamikulas

ZFS RO^WSUX - duplagondol

2010.09.21. 22:05

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));

kqueue Javához!

2010.08.08. 23:17

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.

Holokausztoktatás!

2010.08.03. 16:56

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.

 

Android 2.2: használhatatlan

2010.07.31. 11:36

É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.

ZFS v15 FreeBSD 8 alatt

2010.07.23. 21:38

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

Oracle a memcachedről

2010.07.06. 10:06

Itt: http://en.oreilly.com/velocity2010/public/schedule/detail/13046

Death is just a bug report

2010.06.05. 22:41

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!

Adobe vallás

2010.05.13. 12:19

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.

suckit: adobevallas

süti beállítások módosítása