Blogbejegyzések

Immutable vs mutable

tl;dr
Egyik korábbi blogomhoz érkezett egy ilyen hozzászólás:

Idézet:
"Eddig bármikor is vettem vmit automatából, sose lett új pénztárcám, és sose termett előttem egy másik automata."

Sokan vallják a fentieket, vagyis, hogy a valóságban nem képződnek új objektumok, hanem egy létező objektum állapota változik csak meg.
Ez a hagyományos OO szemlélet.
A másik szemlélet az FP szerinti, ami ellen a fenti idézet is irányul, vagyis, hogy ha változik egy objektum, akkor azt új objektumnak tekintem.

Sokan OO vs FP ellentétként élik meg, magyarázzák, de a fő gond nem az OO-val van, hanem a mutabilitással. Az OO-t lehet immutable-ként is használni, úgy sokkal kevesebb gond van vele(, illetve mutable-ként is, ha üzenetváltással kommunikálunk).
Ha már itt tartunk, akkor megjegyezném, hogy szerintem a következő programozási paradigmákat érdemes használni (csökkenő fontossági sorrendben), ha egyszerű, könnyen érthető, de hatékony programot szeretnénk készíteni:

  1. FP
  2. immutable OOP
  3. mutable (OOP) üzenetekkel (pl. akka, smalltalk)
  4. egyéb mutable

Microsoft IE biztonsági frissítés

A mostani patch kedden jött a KB3139929 Internet Exploreres biztonsági frissítés, ami többek között távoli kódvégrehajtást akadályoz meg. Nyilván telepítendő. A komikus az, hogy ezzel együtt telepíti a KB3146449 frissítést is, ami egy Windows 10 népszerűsítésére használt reklámgeneráló kódot hoz. Ez akkor aktiválódik, ha a felhasználó (egy domainbe nem kötött) IE-n egy új fület nyit.

RANT: szerverek cseréje

Lassan mindkét álltalam munkára használt N36L-t (Gen1) nyugdíjba küldöm. A két Micorserver valójában hibátlanul működik, csak mégis beletettünk már 4-5 évet mindkettőbe. És közben sokat változtak az igények. A Webszerver poszton szolgáló jószág a Drupal8-nak kevés már. Az irodai szerver poszton szolgáló testvére Pedig a 4 főnek 500Giga file-szerver, web-es alapú belső alkalmazás szerver posztról már addig jutott, hogy 8 főt kiszolgálva 4 virtuális gép rágja a két 1.3 Ghz-s magot és a 4 giga memóriát. Meg a 2 tera softraid 1 Btrfs-t :) Míg a rajta futtatott webes alkalmazások is olyan funkciókkal bővültek amik komoly terhelést jelentenek a proceszorra.
A webszerver (ez magán cucc) poszton már megvan az utód. Szintén nem mai csirke de 8 mag 16 Giga RAM és két SSD azért igen jelentős sebességnövekedést jelent.
Az irdai szervernek (na ez a cégé) még nincs utódja. Jó lenne valami hasonló előrelépés ott is.. csak 1U helyett torony kivitelben.. és jóval csendesebb formában, Ma egy éve adtam le az igénylést rá, hivatkozva a fentiekre. Igéretet többször kaptam. Alokált pénzt egyszer sem. Közben pedig kifogytam a trükkökből amikkel a kis gépet többre tudom rávenni.

És persze tudom, hogy sok helyen használnak jóval régebbi vasakat. pl. a HUP alatti két Sun is nemsokára már 7 éves lesz. Persze érdekes kérdés, hogy vajon maradnak-e akkor is ha a HUP új motort kap esetleg. Nem beszélve arról, hogy nagyon más kategória a két gép.

A várva várt SA-k

Hét végén hasraütésszerűen futtattam egy freebsd-update -et, és némi meglepetésemre jöttek javítások. Mostanra a biztonsági figyelmeztetők is megérkeztek hozzá:

OpenSSL és BIND

ZFS on Linux 0.6.5.5

Supported Kernels

Compatible with 2.6.32 - 4.5 Linux kernels.

Bug Fixes

Linux 4.5 compatibility zfsonlinux/zfs#4228
Create working debuginfo packages on Red Hat zfsonlinux/zfs#4224
Make arc_summary.py and dbufstat.py compatible with python3
musl libc compatibility for mount.zfs option parsing zfsonlinux/zfs#4222
Prevent arc_c collapse and possible panic zfsonlinux/zfs#3904
Prevent duplicated xattr between SA and dir zfsonlinux/zfs#4153
Fix zsb->z_hold_mtx deadlock zfsonlinux/zfs#4106
Prevent SA header corruption zfsonlinux/zfs#4150
Allow SPL's copy-builtin to run multiple times zfsonlinux/spl#526
Use safer flags for in-kernel memory allocations zfsonlinux/spl#523
Fix potential deadlock in cv_wait() zfsonlinux/zfs#4106
Fix livelock in shrinker zfsonlinux/zfs#3936

A T nem köt be

2016. január 29-én rendeltünk a T-től egy lakossági internet + telefon csomagot, amit mostanáig nem sikerült nekik bekötni.
Először két hét után érdeklődtem, akkor az ügyfélszolgálat időpontegyeztető részén azt a tájékoztatást kaptam, hogy a szerződés megkötését követő hétfőn járt kinn szerelő, de nem talált otthon senkit. Hogy erről miért nem kaptam előzetes értesítést, vagy hogy miért nem hívott a megadott mobilszámomon, amikor állítóag ott járt, azt nem tudom. Ekkor nagyon kedvesen megígérték, hogy hamarosan újra keresni fognak, de jelenleg időpontot nem tudnak adni, mert a kollégák nem töltöttek még ki valamilyen időrendet.
Egy hét elteltével ismét érdeklődtem. Akivel beszéltem, nem látta a rendszerben, hogy járt volna nálam bárki, de ismét megígérte, hogy hamarosan jönnek.
Újabb egy hét múlva megint telefonáltam. Ekkor a vonal túlvégén beszélő srác viszonylag sokáig kotort a rendszerükben, majd közölte, hogy nem vagyok felvéve valamilyen listára, ezért nem is jöttek volna hozzám. Állítólag felvett, ekkor kaptam is egy üzenetet a mobilomra, miszerint kérésemre egy későbbi időpontban jönnek bekötni. Azt ígérte, 1-2 napon belül keresnek.
Lassan megint eltelt egy hét, de semmi hírük.

Csináljak-e otthonra samba AD-t?

Két gépről van szó, a nyilvánvaló okok hogy miért ne:

- Minek?
- Lassú lesz a profilok szinkronizálása (vagy nem).
- Hirtelen nem tudom hogy milyen win-ek vannak otthon, az egyik az valami professional (vagy nagyobb), de a másik szerintem kb. a home valami.
- Egy user van, én. Néha kettő, esetleg három.
- Hogy fog menni vele a OpenELEC?
- Meg még biztos van.

Viszont kéne tesztkörnyezet. Van-e még valami ellenérv, hogy miért ne?

Csodás dolog ez a csomagszállíás liberalizáció...

...csak épp kurva jó lenne tudni, hogy ki fogja ténylegesen kihozni a csomagot.

Nem értem, miért olyan nehéz ezt feltüntetni weben, hogy ki hol kivel van szerződésben. Vagy még inkább: létrehozni egy egységes, EU-s tracking rendszert, amibe köteles lenne az összes EU-s posta és futárcég csatlakozni. Eskü, nem sajnálnám rá az adót.

dtelnet-ben az AltGr megint bekavart

Emlékeztető önmagamnak: kedves én, az AltGr+7 megszűnt működni, pontosabban Alt+Ctrl+7 ként működik.

A legutóbbi fejlesztés pont az volt, hogy


Ctrl+2 -> ^@ 0x00
Ctrl+3 -> ^[ 0x1b
Ctrl+4 -> ^\ 0x1c
Ctrl+5 -> ^] 0x1d
Ctrl+6 -> ^^ 0x1e
Ctrl+7 -> ^_ 0x1f
Ctrl+8 -> ^? 0x7f

Ha ehhez még Alt-os is nyomunk, akkor teszünk elé egy ESC-et. Ezzel szemközt az AltGr pont úgy csinál, mintha Ctrl és Alt is lenne nyomva... már nem emlékszem a részletekre, de van egy olyan érzésem, hogy nem lesz fáklyásmenet a kettő megkülönböztetése. Vagy lehetne azt mondani, hogy az új fejlesztés ne működjön Alt+Ctrl esetén? Pl. Alt+Ctrl+5 maradjon ° csak sima Ctrl+5 legyen ^]

Hamarosan megvalósulhat locsemege és hokuszpk álma

Igaz továbbra sem SHA-256 hash ütközés lesz és pláne nem a családi fotóalbumban található baba-mama képek között, meg nem is SHA-1 és MD5 ütközés egyszerre kovacsani biztonsági mentésénél...

Az RSA 2016 konferencián Adi Shamir (az S az RSA-ból) megemlítette, hogy Marc Stevens és munkatársai a gyakorlatban is dolgoznak olyan 2-blokkos SHA-1 ütközés generálásán, amelynél az első blokkpárt már megtalálták és a következő néhány hónapban képesnek kell lenniük arra, hogy megtalálják a második blokkpárt ahhoz, hogy egy valódi, tényleges ütközés megvalósuljon.

Dual Screen filming...

Lehet, hogy a káva zavaró, de távolabbról már annyira nem.

Win alatt az eyefinity megy, de linux alatt CSAK KDE alatt találtam olyan lehetőséget, amit könnyen be lehet állítani, s egy logikai képernyőként hozza a kettő fizikai képernyőt videólejátszás alatt a támogatott lejátszóknál (VLC, Mplayer... meg még pár...).

DE nem tudom a képet széthúzni mint Win alatt az MPC-HC-val, így a két képernyő széle között sok sötét sáv marad obb és bal oldalt :S