Blogbejegyzések

Black Mesa: Xen

No, ezt is megéltük, megszülték a Crowbar collective-s arcok a Black Mesa záró részeit a Xen-t. Igen, azt amit MOD-ként még 2012-ben adtak ki, majd 3 évre rá Steamre is felkerült, mint standalone játék. És igen, 2005-ben kezdték fejleszteni. Tulajdonképp ugyanennyi idő kellett a Duke Nukem Forevernek, különbség az, hogy ez legalább jó lett.

Vasárnap kezdtem el, most értem a végére. Persze csak a Xen-től, rég volt már az, hogy együltömben (majdnem) végig vittem. (Anno 2012-ben a Lambda Core elején adtam fel fáradtság miatt. Hiába, évek telnek, változnak az idők). Azt kell, hogy mondjam, megérte a várakozást. Alaposan újragondolták a Xen-t, sokkal bővebb világot kaptunk. Nagyon tetszett a dizájnban, hogy jobban megjelent az idegen infrastruktúra, egyfelől szögletesebbek lettek a dolgok, mint mondjuk egy rendes építmény*, kerítés, szerkezeti elemek, stb. és nem teljesen egy trekie féle "semmi köze a fizikához, de jól néz ki" dizájner agymenés (bocs minden trekie fanboytól, az ST dizájna szar). Másrészről viszont sikerült megtartani a 90-es évekre jellemző absztrakt, kissé doomos-quakes formatervet, mindezt úgy, hogy sok helyen egészen felismerhető az, hogy mit honnan mintáztak - mindezt úgy, hogy tényleg az alapoktól újragondolták és kihasználták azt, hogy a source engine egy halom új puzzle típushoz ad lehetőséget. A sok bővítés mellett viszont van, ami kikerült: Nihilanth nem teleportál már el minekt sehova. Ez mondjuk nem biztos, hogy hátrány. Meg talán a végére egy picit sok volt az Interloper fejezet végére a futószalag, de mire elkezdtem volna unni már jött más.

Amivel vigyázni kell: úgy általában véve nehéz lett a Xen. Ezt a készítők is írják, hogy még a játékegyensúlyon csiszolni kell egy picit, most van egy-két rázósabb szakasz, bár nem vészes. Alapvetően az egész Xen nagyon szép, 1-2 hely van, ahol elkellene még pár polygon meg 1-2 nagyobb felbontású textúra. De az összkép az remek. Bugok sajnos még vannak, zömében apróságok a pályán, itt-ott be lehet akadni meg 1-2 helyen a "vízet" egy picit jobban ki kellett volna húzni, mert a levegőben ér véget. Illetve egy "ED_Alloc No Free Edicts"-be futottam bele, Interloper fejezet vége fele egy nagyon magas liften, ahol sok Controller szeretné megkeseríteni az életünket. Ott nem segtett a -num_edicts 2047 paraméter, amit többen javasoltak az interneten. Megoldás az god mode + noclip-el felmegyünk, a következő szinteken ahol alien gruntok is vannak kipucoljuk a terepet, majd folytatjuk. Még azelőtt jön elő, mielőtt a táposabb fajta Controller előjön. Többen jelezték, szóval a probléma nem egyedi.

Hosszban egyébként összemérhető hosszúságú volt elsőre, mint anno a Black Mesa Xen nélkül. Olyan 7 óra volt normál nehézségen. Anno a BM is kbl. 7-8 volt nekem.

* Ez tetszett Peter F. Hamilton Pandora Csillaga/Júdás elszabaduljában is, hogy a Primer cuccok is igazából hasonlóak voltak az emberi dolgokhoz, mert mégiscsak a műszaki dolgoknál a fizika diktál.

5.4.2-es kernel még nem az igazi

Intel N4200-t - i915 - használó pici notebook-omat ma emlékeim szerint négyszer kellett hosszú gombnyomással kikapcsolni. 5.4.2-es kernel, megfagyott a Xorg. Volt, hogy sikerült még konzolra váltanom, ott login, majd az első dolgom egy sync parancs volt. Utána dmesg. A VGA valamelyik részéről azt mondta, hogy hang up. Nem örültem túlzottan. Visszatettem az 5.3.15-ös kernelt, az teljesen stabil.

Azért írtam, hogy akinek i915, vagy efféle VGA-ja, APU-ja van, az maradjon veszteg, jobban jár egyelőre az 5.3.15-ös kernellel. Remélem, észreveszik, s hamar kijavítják a hibát.

Mandalóri

Megnéztem az első 4 részt.

Sajna sokkal többet vártam és lehet, hogy ez volt a baj. A 4. rész végére sem lépett túl egy vasárnap délutáni scifi sorozat színvonalán. Pedig az első részben volt pár olyan jelenet amiből azt gondoltam, hogy kiba jó lesz.

Ez az egyik: https://www.youtube.com/watch?v=1etNcuojPkE

Ez a jelenet hibátlan. Ha nem ismeretlen a SW timeline akkor tudod, hol vagyunk, kik ezek a rohamosztagosok és  ki a góré. Ahogy hátrafordulnak az zseni, Werner Herzog monológja azzal hanghordozással megint ..

El is tekintettem a rész többi hibájától. De ahogy haladunk előre a sokaságuk miatt inkább felerősödnek. A lopások más filmekből nem zavarnak. Volt már ilyen. A logikátlan baromságok!

-Nem veszi le a sisakját. Nem csak ki áll az ablakba egy óvoda elé.

-Sétál baby-yodával. Persze minden lépésnél távolodik a mandarin és ez minden snittnél újra mellőle indul. by kb eggyel megy. Komolyan, de szerintem sokat mondok.

-Leszáll egy bolygón. A céltól egy nap légszekéren. Mi a fenéért nem megy ü hajóval miért egy szekéren kell szenvedni? 

Mindjárt megnézem az 5. epizódot.

Samsung 850 EVO 1Tb Bad sector

Van használatban jó pár 850 EVO itt-ott, 512Gb/1Tb/2Tb méretben.

A héten sikerült produkálnia egy Bad sectort az elsődleges SSD-nek, amin egy rendszer fut.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   099   099   010    Pre-fail  Always       -       1
  9 Power_On_Hours          0x0032   092   092   000    Old_age   Always       -       38126
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       46
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       5
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   099   099   010    Pre-fail  Always       -       1
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   099   099   010    Pre-fail  Always       -       1
187 Uncorrectable_Error_Cnt 0x0032   099   099   000    Old_age   Always       -       44
190 Airflow_Temperature_Cel 0x0032   076   061   000    Old_age   Always       -       24
195 ECC_Error_Rate          0x001a   199   199   000    Old_age   Always       -       44
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       23
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       14102650139

Jó, hát már több, mint 4 éves. A wear leveling count 5, de az eddig kiírt mennyiség ha jól számolom olyan 6.56 Tb körül van.

A sector olvashatatlan, sikertelenül próbálta javítani. Visszakerestem és egy ext4 partíció esik rá, amelyen egy mysql bin log fájlhoz tartozik a kérdéses sector. Az adatbázisok mennek, mentés van szerencsére. Várom, hogy kiforogjon a kérdéses log fájl és akkor elvileg felszabadulhat. Azt nem tudom, hogy akkor végre megoldja magától az SSD, ha megy a discard/fstrim? Ha tartósan ott tartja olvashatatlanul, akkor mit tudok csinálni az ext4-gyel? Vagy úgyis kuka az egész?

Azt hittem az SSD majd hirtelen fog megmakkanni, meg fura hibajelenségekkel szórakoztat majd, mint a gyengélkedő pendrive-ok és hogy bad sectort utoljára HDD-n láttam...

Egyébként Crucial-on gondolkozom következő körben. A 6Tb utáni köhögést kicsit korainak érzem, még akkor is, ha már eltelt több, mint 4 év. Stressz teszteken 10x ennyit mértek. Ja és távolról sincs betelve a cucc, továbbá eminens majom módjára még konfiguráltam neki külön over-provisioning-et is, nem is keveset (hdparm -N). Egyébként Win 7 alatt elképesztően belassult az évek során. A sequential read/write lassabb mint egy jó HDD-n, de a random read miatt még mindig versenyképes az élmény, hiába fordítottam különös figyelmet a partícionálásra. Az NTFS a ludas valamiért egyébként, mert benchmark-okban még mindig hozza a jó értékeket és ext4/btrfs/xfs alatt nem lassul be. Nincs kedvem és türelmem emiatt gyalulni és visszamásolni. Most nézem, hogy azon az 1Tb-s EVO-n eddig 5.3Tb íródott. Akkor még van 1.3Tb idő? A system drive egy Lite-On NVME SSD...

Ezt ma olvastam

" Amíg ilyen jól teljesít a gazdaság, nem várható változás, ami jó hír a bankoknak és az ügyfeleknek is, a követelésvásárlók számára pedig a fokozatosan csökkenő állományok kezelését ígéri. Történelmi mélyponton van a munkanélküliség, a foglalkoztatottsági rátánk az egekben, robbannak a bérek, miért is lenne nagyobb a bedőlési arány? Bármilyen fronton nézzük, a lakosság elkölthető jövedelme, illetve vagyona folyamatosan nő. "

Karácsony - Megoldva

Minden karácsonyi ajándék elintézve.

Idén még 6 napot dolgozok es Január 7-ig szabadság.

Fát kell csak vennem meg egy jófajta száraz fehérbort.

Addig is valahogy ki kell birni az irodában a irigykedő kollégákat, a stresszes admin asszisztens hölgyeket, a flusztrált scrum mastert, hogy 30 effort ponttal kevesebb lesz a team capacity, de ez menni fog :-)

Szép napot!

Revolut - adatszivárogtatás

Bicskanyitogató, álszent és szemforgató "tájékoztató" levél, miután frissítetted az alkalmazást amiben alapbeállításként szivárogtatnak. Most letilthatod ha akarod. Persze, ingyenes, stb....az összes alkalmazás adatvédelmi tájékoztatóját átolvasom az elejétől a végéig mindig és minden módosítást követően így én vagyok az oka mindennek és ha nem akkor is :-).

https://www.youtube.com/watch?v=WberQSoM6Rs

NextCloud manuális telepítéssel, IPv6, dinamikus DNS, VirtualBox

Nem is olyan egyszerű... inkább időrabló és időnként nagyon bele kell ásni az elmét - főleg a neten terjedő hülyeségek miatt. A dokumentációk sokszor túl bonyolultak, így egyszerűbb kérdezni a Google-tól. Sok a hülye, már megint be kellett látnom.

2019-11-28 OSS Leap 15.1 LVM2 hiba

h170pro4:/ # cat /etc/os-release 
NAME="openSUSE Leap"
VERSION="15.1"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.1"
PRETTY_NAME="openSUSE Leap 15.1"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.1"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

A tegnapi frissítéssel ezek jöttek:

h170pro4:/ # egrep 2019-11-28 /var/log/zypp/history | grep -i lvm2
2019-11-28 08:34:03|install|liblvm2cmd2_02|2.02.180-lp151.4.6.1|x86_64||download.opensuse.org-oss_1|762754806ee9220108ecaf86ea22703c0d3ce6cb4905a601acdaf016b00fb037|
2019-11-28 08:34:03|install|liblvm2app2_2|2.02.180-lp151.4.6.1|x86_64||download.opensuse.org-oss_1|301022ed0dcbb3b5a66f556a3da5ee72d40aec334b903294db65885ae73d5927|
2019-11-28 08:34:04|install|lvm2|2.02.180-lp151.4.6.1|x86_64||download.opensuse.org-oss_1|d70107477bca599ea0b6708ce6fa99440bf56a4140032cdc891b16ee115d61db|

Az lvm2 tuti hibás! A softraides PV/VG/LV-ok nem mindig látszanak bootoláskor(próbáltam az /etc/lvm/lvm.conf fájlban a filteren állítani, de nem sokat segített).

Csúnya workaround:

1: Commenteld ki /etc/fstab-ban a sorokat:
h170pro4:/ # fgrep "#" /etc/fstab 
#/dev/raid1/home                            /home          xfs   noatime                       0  0
#/dev/raid1/vms                             /home/ice/vms  xfs   noatime                       0  0

2:

h170pro4:/ # cat /etc/systemd/system/workaround.service 
[Unit]
Description=LVM2 bug workaround service
After=basic.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/workaround.sh

[Install]
WantedBy=multi-user.target

systemctl --system daemon-reload

h170pro4:/ # cat /usr/local/bin/workaround.sh 
#!/bin/bash

/usr/sbin/lvm pvscan --cache --activate ay
/usr/bin/mount -o noatime /dev/raid1/home /home
/usr/bin/mount -o noatime /dev/raid1/vms /home/ice/vms

chmod +x /usr/local/bin/workaround.sh

systemctl start workaround.service

Ez a workaround mountol bootoláskor.
 

HUP és az IPv6 - visszatekintés

ipv6 ready

A napokban újra fellángolt az IPv6 téma internet-szerte és itt a HUP-on is, annak kapcsán, hogy a RIPE NCC bejelentette, kifogytak az IPv4 címekből.

Személy szerint mindig is fontosnak éreztem az IPv6 szekerének tolását (még akkor is, ha sokszor szarkasztikus megjegyzésekkel is illettem a bevezetésének "sebességét"). Már a HUP elődjeként 2000 körül általam indított kezdetleges szerveren is külön menüpontot szántam neki (keresd meg, ha érdekel). Éppen ezért, örömmel vettem, amikor több mint 10 évvel ezelőtt bra bejelentette, hogy mi is elérhetők lettünk IPv6-on. Azóta a HUP a technológia elterjedtségének fokához mérten, stílszerűen és annak megfelelő minőségben, azaz BÉTA üzemben "folyamatosan" elérhető IPv6-on.

Valószínű, hogy 10 évvel ezelőtt a HUP az első fecskék közé tartozott az IPv6 támogatás bevezetésével. Hazai viszonylatban legalábbis mindenképpen. Sajnálattal kell megállapítanom, hogy az elmúlt egy évtized alatt ez a fecske nem csinált nyarat.

Azóta is nagyítóval kell keresni a hazai neten az IPv6-képes magyar nyelvű weboldalakat. Szégyen, hogy 2019 legnagyobb látogatottsággal magyar bíró weboldalai 100-as listáján alig akad, ami elérhető lenne az IP protokoll "új" verzióján keresztül.

Remélhetőleg, tíz év múlva, a HUP 20. IPv6-os születésnapján jobb hírekről számolhatok majd be! Addig is, álljon itt egy pozitív lista azokról a magyar nyelvű, nagyobb oldalakról, amelyek már sikeresen megugrották ezt a szintet:

[ IPv6-képes magyar nyelvű (web)oldalak ]