NevemTeve blogja

Szoftvereladók kisszótára

 ( NevemTeve | 2017. november 10., péntek - 8:35 )

Szoftvereladók kisszótára

Oracle must have

 ( NevemTeve | 2017. október 23., hétfő - 18:14 )

Ezt véletlenül találtam, és nagyon hasznosnak tűnik:
https://stackoverflow.com/questions/17124881/oracle-proc-oci-install-handlers-for-sigsegv-sigabrt-and-friends-why-and-how

egy lehetőség: sqlnet.ora:DIAG_SIGHANDLER_ENABLED=FALSE

El ne felejtsem holnap tesztelni!

gthumb fejlődött: 2.11.5 -> nem tudom mennyi

 ( NevemTeve | 2017. október 20., péntek - 17:08 )

Kicsit értelmesebben: a jobboldali készülékemen (Debian 6) van egy gthumb 2.11.5, tudok vele elemi képmanipulációt végezni, például levágom a screenshotból a felesleget. A baloldali gépemen (Debian 8) szintén van egy gthumb. Annyira felhasználóbarát, hogy még a Help/About-ot sem találom, így a verziószámot sem tudom megmondani, de ennél nagyobb baj, hogy pl a 'Crop' műveletet sem lelem.

Szerk: na meglett a Crop... Az én hibám; az volt a gond, hogy én még olvasni tanultam annak idején, nem ikonokat felismerni. Kérek engedélyt meghunyászkodni!

file-mile

 ( NevemTeve | 2017. október 16., hétfő - 9:21 )

Akarom mondanom, van egy file, amin átok ül, sajnos: a 'file' utility nem boldogul vele, valamiféle végtelen ciklusba esik. Most éppen négy (mc-által indított) process álldogál így:

Kedélyeket borzoló programok

 ( NevemTeve | 2017. október 12., csütörtök - 11:17 )

Ma valahogy összejöttek kedélyeket borzoló problémák...

1. Firefox: újra működik a 'View Certificate' meg a 'Technical Details' a 'Page Information' / 'Security' résznél -- csak új profilt kellett csinálnom. Cserébe elromlott az f.i.hu [most nem írom ki a nevét]: HTTP 400 Request Header Or Cookie Too Large. (A telefonomon se működik, ugyanez a hibaüzenet, abba már bele is törődtem, az élet nem habostorta, Pelikán elvtárs!)

2. Mivel az ember legjobb barátja a tcpdump, elkezdtem nézelődni, hát látom, hogy a

Na ez sem sikerült... survey@popcon.debian.org

 ( NevemTeve | 2017. október 9., hétfő - 16:19 )

Azt mondja nekem a kompjuter nagy szomorúan:

Egy megkésett Y2000

 ( NevemTeve | 2017. október 6., péntek - 12:28 )

Ne firtassuk, hogy ezt hol találtam, de jópofa:
Budapest, 117.10.6.

Másvalaki problémája... Kígyó...

 ( NevemTeve | 2017. október 4., szerda - 7:15 )

Ez most kivételesen nem az én gondom, és nem is tudom reprodukálni... de azért érdekes.

Why can “%.10f” % Decimal(u) emit a string with a literal colon?

Python inserts a colon in a Decimal number from Access via pyodbc

gdb-8.0.1 sem fordul

 ( NevemTeve | 2017. szeptember 23., szombat - 18:58 )

Nem teljesen függetlenül attól, hogy elkezdtek C++ irányba fejlődni. De ha már így próbálkozom, ezt a szépséget írja ki a configure:

Rejtvényfejtőknek: Hol a hiba a képen?

 ( NevemTeve | 2017. szeptember 20., szerda - 11:47 )

Kódrészlet következik (pontosabban gdb backtrace), a kérdés: látunk-e valami furcsaságot:

standards.h: _ALL_SOURCE vs _XOPEN_SOURCE

 ( NevemTeve | 2017. szeptember 10., vasárnap - 17:23 )

Az együttműködés csodálatos jó dolog! Az 'fmemopen'-hez kell az _XOPEN_SOURCE>=700. Tehát beállítom az _XOPEN_SOURCE=700-at. Meg az _ALL_SOURCE-t.

Aztán mire kijön a cpp a <standards.h>-ból, az _XOPEN_SOURCE már csak 600. Az _ALL_SOURCE miatt.

Kérdés: hibázott-e valaki. Mármint rajtam kívül persze.

(Ismertelen segítő szoftver): veszélyes csatolmány cenzúrázva

 ( NevemTeve | 2017. szeptember 8., péntek - 8:17 )

Ahogy Váncsa István mondta, némely emberi agy egészen másképp műkődik, mint ahogy azt józan ésszel gondolkodva elvárhatnánk.

Ennek tudom az most az is, hogy az Outlook/OWA megsemmisített egy csatolmányt a bejövő levelemben, amely egy rendkívül veszélyes plain text file volt. Huhh, már abba is beleborzongtam, hogy ezt leírtam!

Azt hiszem, büszkén mondhatjuk, hogy az iparág ezzel újabb diadalmas lépést tett az értelemtől elfelé vezető úton!

Firefox: nehogy véletlenül inkompatibilis legyen...

 ( NevemTeve | 2017. szeptember 6., szerda - 13:10 )

https://support.mozilla.org/en-US/kb/firefox-add-technology-modernizing

A Firefox szerint az inkompatibilitás rossz dolog. Ezért, hogy a bővítmények ne váljanak véletlenül inkompatibilissé, szándékosan inkompatibilissé nyilvánítják őket.

De persze azzal az ígérettel, hogy a jövőben már kompatibilisek maradnak.

Na ebből mindent szóról-szóra elhiszek, kivéve az utolsó mondatot.

openssl -- SIGILL

 ( NevemTeve | 2017. augusztus 31., csütörtök - 14:30 )

20170831.1644
Van nekünk ilyenünk:

typedef struct stack_st {              
    int num;                           
    char **data;                       
    int sorted;
    int num_alloc;
    int (*comp) (const void *, const void *);
} _STACK;

struct stack_st_SSL_COMP { _STACK stack; };

typedef struct ssl_comp_st {
    int id;
    const char *name;
    COMP_METHOD *method;
} SSL_COMP;

20170831.1556
Szóval van egy 'ssl_cipher_get_evp', aki 'sk_find'-et hívott; persze nem direktben, hanem egy-két makrón keresztül:

crypto/stack/safestack.h:

# define sk_SSL_COMP_find(st, val) SKM_sk_find(SSL_COMP, (st), (val))

# define SKM_sk_find(type, st, val) \
        sk_find(CHECKED_STACK_OF(type, st), CHECKED_PTR_OF(type, val))

Szóval ilyen volt, ilyen lett:

ssl/ssl_ciph.c:530
i = sk_SSL_COMP_find(ssl_comp_methods, &ctmp);
i = SKM_sk_find(SSL_COMP, ssl_comp_methods, &ctmp);
i = sk_find(CHECKED_STACK_OF(SSL_COMP, ssl_comp_methods),
            CHECKED_PTR_OF(SSL_COMP, &ctmp))

crypto/stack/stack.c:271
int sk_find(_STACK *st, void *data)
{
    return internal_find(st, data, OBJ_BSEARCH_FIRST_VALUE_ON_MATCH);
}

crypto/stack/stack.c:247
static int internal_find(_STACK *st, void *data, int ret_val_options)

Eredeti post
Túl nagy volt itt a csend, már kellett valami... Megpusztul egy programocska, az SSL_accept-ben.

IIS 7.5 -- Valami 48K

 ( NevemTeve | 2017. augusztus 23., szerda - 19:37 )

Ugyebár ez nem jó, ami valami, az harminc, nem pedig 48 KB.

Valahogy 'hozzápiszkálódott' az IIS konfigjához (csakis a marsklakók lehettek, mert mindenki más tagad (még a Windows Update-ot is gyanusítom)), és emiatt valamilyen 48 KB -s korlát lett a POST-méretére (kidebuggoltam 49152 még ok, 49153 már nem)

Valamilyen SOAP-os ASP.NET-es okosság is van a történetben, csak hogy érdekesebb legyen.

Nagy utazás -- dbuson

 ( NevemTeve | 2017. augusztus 22., kedd - 16:19 )

Na jó, semmi komoly, csak arra lennék kíváncsi, hogy hogy került az AIX-omra egy /usr/local/etc/bash_completion.d/gdbus-bash-completion.sh nevű fájl?

Valaki arra készül, hogy egyszer talán majd dbus lesz az AIX-on? Vagy így akarjuk átrázni a kémeket? Persze csak azokat, akik nem ismerik az uname-t?

Szerk:
A glib volt. Az telepítette a gdbus nevű programmal együtt. Mindjárt szétnézek, van-e valahol egy kis systemd is..

php7: Nincsen nekije alloca

 ( NevemTeve | 2017. július 27., csütörtök - 17:30 )

Mármint eddig nem hiányzott neki, de most hiányzik. Az --enable-mbstring óta. Csak azért zavar ez az alloca, mert emlékezni vélek, hogy erre már rászaladtam valamikor... Nyilván utólag majd teljesen kézenfekvő lesz a dolog. Mondjuk nem volt include-álva az alloca.h, pedig kellett volna. Vagy include-álva volt, de nem kellett volna. Vagy balkézzel kellett volna lenyomni az Enter-t a ./configure-hoz. Szóval valami teljesen érthető hibát követtem el.

Szerk: google nevű varázseszköz megtalálta: https://hup.hu/node/115430#comment-1527342

Elmeorvosi kivizsgálásomat kérem gcc-ügyben...

 ( NevemTeve | 2017. július 26., szerda - 17:58 )

2017.07.30. 15:10
Legyen meg írásban is: http://web.axelero.hu/lzsiga/ekezet.html#Q0168

2017.07.28. 06:34
No, megnyugodtam, kényelmes gumiszobában meditálhattam, és arra jutottam, hogy az -finput-charset az az, amiről a preprocesszor UTF8-ra konvertál. Mindent. Nem csak az L", u", U", u8" stringeket, hanem mindent. A szoftver segít.

mc - már megint nem értek valamit

 ( NevemTeve | 2017. július 24., hétfő - 17:22 )

2017.07.25. 17:02
Ez lett belőle: https://midnight-commander.org/ticket/3843

2017.07.25. 14:58
Pédául ezt a sort lehetne meghaxolni, hogy UTF-8 esetén már 128-tól szíveskedjen unikódolni:

edit.c:3359         if (char_for_insertion > 255 && !mc_global.utf8_display)

2017.07.25. 12:25
Van egy ilyen rész benne (miután lenyomtam egy 'é'-t):
[code]
charsets.c:474 res = g_unichar_to_utf8 (input_char, (char *) str);

p/x input_char => 0xffffffe9
p res => 6
p/x str => {0xff, 0xbf, 0xbf, 0xbf, 0xbf, 0xa9, 0x0}

memset_s -- ez mi ez?

 ( NevemTeve | 2017. július 11., kedd - 11:13 )

Ezt kéri tőlem az apr-util. Nyilván egy derék komputer-tudós áttörést ért el a 'memóriaterületek feltöltése konstans byte-tal' nevű tudományterületén, és annak követésére kellett ez a fejlesztés. No, mindjárt utánanézek.

Samba -- nagy szellemek, ha találkoznak

 ( NevemTeve | 2017. június 29., csütörtök - 9:21 )

Szóval amire én rászaladtam 2016-ban, azt valaki már 2005-ben jelezte, csak elsikkadt...

Olvasmány fordító-optimalizáció ügyében

 ( NevemTeve | 2017. június 15., csütörtök - 19:53 )

http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf

Még csak belepillantottam, de jónak tűnik.

Szerk: pl. ilyesmiről hallottam a usenet sötét zugaiban: ha 'p' pointer esetleg lehet NULL, akkor pl. a strnlen(p,0) vagy a memcmp(p,q,0) is UB, tehát az optimalizáló akármit is generálhat oda, akár szándékosan rosszat is.

Kieg: itten van például ez a clang-os teszt
[code]
printf ("sin_addr at %d\n",
(int)offsetof (struct sockaddr_in, sin_addr.s_addr));

Mitől véd az O_NOFOLLOW?

 ( NevemTeve | 2017. május 27., szombat - 7:48 )

Amit értek: megnyitnám a "/fontos/outputfile"-t írásra, de aggódom, hogy a haxor esetleg odatett egy /fontos/outputfile nevű szimlinket, ami a /etc/passwd-re mutat. Mondjuk neki nincs írási joga a /etc/passwd fájlra, de nekem van, és ezzel rávesz, hogy tegyek kárt a fájlban.

Vagy lehet az egy érvénytelen symlink, amit ha megnyitok írásra, akkor ott hozok létre egy fájlt, ahol nem akartam.. és mondjuk elhasználom a lemezhelyet, vagy információ jut ki a gépből (ha mondjuk az egy NFS-en felmountolt lemezhely), stb.

samba-4.4.14 -- Már kezdtem megijedni...

 ( NevemTeve | 2017. május 26., péntek - 13:44 )

samba-4.4.14 -- Már kezdtem megijedni, hogy csak úgy ukk-mukk-fukk lefordul, de szerencsére megállt itt: [2342/3334] Compiling source3/smbd/open.c

netkit-telnetd elavulta magát -- de most jön a jó hír

 ( NevemTeve | 2017. május 22., hétfő - 18:56 )

A múltkor panaszoltm a netkit-telnetd-re, de most van jó hír is: AIX-on nem hajlandó fordulni, mert hogy:

checking for BSD signal semantics... no
This package needs BSD signal semantics to run.

Abban bizakodom, hogy van valahol a /usr/lib-ben valami jó kis kompatibility-library pont az ilyen kőkorszakbeli termékek részére...

Szerk: Van, a neve libbsd.a, csak nagy ravaszul nem a LDFLAGS-ba, hanem a CXXFLAGS-ba kell betenni, hogy -lbsd'

Szerk: Továbbá 'ncurses' helyett 'curses' van AIX-on. Most épp a 'forkpty' hiányzik neki. Folyt. köv.