apal blogja

just for the record:

https://stackoverflow.com/questions/52998331/imagemagick-security-polic…

avagy:

$ convert papir1.jpeg papir1.pdf
convert-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/426.

# apt-get install gtk3-nocsd
$ export GTK_CSD=0
$ export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
$ gtkwhatever ... 

... csak mert nehany alkalmazasnal kimondottan hulyen mukodik ez a "client-side decoration" nevu baszmany... Ezzel a fenti hekkelessel mar egy fokkal vallalhatobb, de persze igy is jobb volt mint lett. Pl ez a Ξ jellegu menuzes is joval kevesbe hatekony mint a szokasos menurendszer eles hasznalat eseten (ha valaki tudja hogyan lehet azt visszaallitani, akkor szoljon :)).

Érdekes megállapítás: gcc-12 esetén RISC-V processzorokra a -march= kapcsoló már elkezd különbözni fordítás és linkelés esetén. Amennyiben speciálisabb Zxxx kiterjesztést használunk (azaz bármi CSR-t, azaz ilyen-olyan megszakításokkal dolgozunk!), akkor azt immáron már "kéri" a fordító, ellenben a linker meg meghülyül ha ottmarad ez.

Onnan is lehet látni hogy az Unicode karakterkészletet Ámerikában találják ki hogy a "mosógép" még mindig nincs a karakterek között, de "egy zászlópóznán, a szélben lengedező két darab döglött hal" (🎏) az van!

Egy kicsit intenzívebb fejlesztési szakasz és néhány korábban felmerült kérdés után kijött a korábban bemutatott, saját fejlesztésű AVR proci és/vagy SoC következő verziója. Javítva vagyon benne pár CPU core és perifériákat érintő bug, ami a tesztek során ugyan előjött, de jelenlegi felhasználásnál (azaz konkrét programok futtatásánál) nem jött elő, sem égen, sem földön.

Noha az "digitális elektronika" mint olyan arról lehet nevezetes hogy egyik állapotot egyértelműen kell kövesse a következő állapot, a hardver-leíró nyelvek közül is a Verilog szereti használni a sztenderd "0" es "1" (és "z") állapotokon felül az "x"-et. Ami... ami úgy van definiálva mint: nem tudjuk, nem érdekel, nem érint, vagy ennek valamiféle kombinációja. Szeretjük is használni az "x"-et már "beugró szinten is", már a legegyszerűbb igazságtábláknál is megjelenhetnek.
 

Kis hasznos az /etc/udev/rules.d/ konyvtarba, ha valaki sok FTDI USB UART-tal dolgozik:

SUBSYSTEM=="tty", ACTION=="add", RUN+="/bin/bash -c 'f=/sys/bus/usb-serial/devices/%k/latency_timer; test -f $f && echo 1 > $f'"

Kicsit gyanus volt hogy 921k6 baudon az oda-vissza tranzakciok ~12kB/sec-cel mentek... :)

struct __attribute__((__packed__)) whatever
 {      unsigned int  f1: 2;
        unsigned int  f2: 5;
        unsigned int  f3: 5;
        unsigned int  f4: 6;
        unsigned int  f5: 6;
        unsigned int  f6: 8;
 };

[...]

sizeof(struct whatever) = ?

$ top
[...]
 2983 apal      20   0  1.103t 277496 118228 R 176.2  1.7   0:08.10 chrome                                                             
 2502 apal      20   0 32.807g 320464 208048 S  21.8  2.0   0:16.80 chrome                                                             
 2939 apal      20   0  1.103t 188632 108684 S  21.8  1.2   0:02.02 chrome                                                             

Not bad... 

Márcsak szűk két óra: https://www.nasa.gov/nasalive

... tavaly sikerult beleplnem. Iden mar nem. Gondoltam megirom hosszabban is a tapasztalatokat, de aztan a gondolat tovaszallt - mondvan hogy valojaban sok ujat nem tudok mondani eme szoftverceg minosegerol. Mondjuk mar tavaly osszel is volt annyi sutnivalojuk a bizottsagoknak hogy a doktori vedesek es/vagy szigorlatok egyreszet attettek zoom-ra. Azaz van feny az alagut vegen, de a holnaputani esemenybol vsz igy meg es/vagy mar sokan kimaradunk.

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

... 

Márcsak kevesebb mint 11 óra! https://www.youtube.com/watch?v=J1nfIV-4_e8

Két kicsi magyar műhold, reméljük minden is rendben lesz :) A videó moszkvai időt mutat, magyar idő szerint szombat reggel 07:07-kor indulunk. (Node a mi visszaszámlálónk az csak-csak jó... bár a javascript sosem tartozott a kedvenc nyelvek közé, odafent azért nem azt kell használni)

Szerk: egy nap halasztás, start vasárnap reggel! két nap halasztás, lesz ez hétfő reggeli start is.

2020 vege, vegytiszta szuz android, chrome-mal, webes email attachment: ~2 megas jpeg. 

Elso sajat opencores-projekt: https://opencores.org/projects/softavrcore. Ha valakit erdekel full stack FPGA + AVR kombinacio. 

Kovetkezo feladat: hogyan is lehet svn-ben(!) ilyen dolgokat feltolteni a barhova is...

# ls -l /dev/md
lrwxrwxrwx 1 root root 8 Jun 15 17:22 md0 -> ../md127
 

... es mekkora orom amikor kiderul hogy a javascript a style.zIndex-eket stringkent hasonlitja ossze!

... es akkor ott bassza meg a pötterix onmagat ahol van!

Van egy USB3-Ethernet adapter, amit ha egyik USB-A 2-es csatlakozoba dugok akkor minden oke, de ha a masikba (ami konkretan egy USB2-es hub egyik vagy masik csatlakozoja) akkor nem mukodik csak ugy. A dmesg szerint az enumeration elejen mar elekad (de konkret hibat nem irt ki). Ellenben ha csak ugy felig dugom be hogy eppenhogy legyen kontakt, akkor szepen megy - ellentetben mechanikailag annyira nem tartos a dugvany.

Akkor ezekszerint ez az USB3 vs. USB1/2 hardveres szintu csatlakozo-kompatibilitas az igy sikerult? Eszi, nem eszi, nem kap mast? :)

... hogy az is egy kellemes erzes mikor kiderul ~fel nap debuggolas utan hogy a gray code -> binaris konverzio elott nem lehet csak ugy ad hoc negalni az osszes bitet :) Avagy: legkozelebb ne doljunk be az "ah, open collectoros a gray-enkoder kimenete, tokmindegy hogy hogy vesszuk le azokat a biteket" dolognak!

Na, most 10 e'v... + pa'r o'ra...

a minap, va'lta's polokent random mod egy emitten nyert hup-os volt nalam a mont blanc tetejen. szep kis kirandulas, keves levego, nagy hegy, nagyokat lehet pottyanni :]

Nemregiben ezt a pexec programot bevette'k a gnu projektbe. Mielott oda is teljesen felmenne, emitten egy lokalisan veglegesnek szant verzio (1.0rc7), itten. Sok aprobb fejlesztes: autoconf, mutexek, atomi parancsok, dinamikus terhelesmegosztas es -szabalyozas, doku; ha valakit erdekelne egy kis shell-szintu "data parallelization". Mindenfele hibajelentest, o"tletet, megjegyzest, egyebet addig is szivesen varok!

Ujabb pexec riliz, kiegeszitve egy kis osszefoglaloval. Ez a valgrind nagyon kiraly dolog, kar hogy eddig nem ismertem.

Egy kis karacsony elotti pexec frissites, miutan x nap elteltevel sikerult elerni a vasat, amin a legutolso fejlesztes keszult. Biztonsagi mentesnek is betudhato, ennek oromere; es egy kvazi-kritikus bugot is sikerult kijavitani (nem biztonsagi hiba, csak neha leblokkolt, ha az input kellemetlen formatumu). Apropo, biztonsagi hibak: tud-e' valaki jo modszert hogyan lehet keresni/talalni effajta reseket egy adott programon, ami me'g belathato meretu"? Oke, ne hasznaljon az ember strcpy()-t, ezen kivul...:)?