NevemTeve blogja

Mármint úgy értem, hogy túl simán ment már minden, kellett valami fordítási hiba.
libxml2-2.9.8

Legalábbis valami nézeteltérés van közöttük, adott egy C forrásprogram; gcc-vel és clang-gal is működik; de ha clang-gal fordítom, és gcc-vel linkelném, akkor nem sikerül:

Újabban már Java-irányban is kiváncsizom, persze nem a normális esetek, hanem a problémás hibakeresések irányába (vegyes jegyzetek)

2018-11-23 09:36
Unalmamban elkezdtem összegyűjteni, hogy hány külső komponens kell ahhoz, hogy a jax-ws működjön Java10-zel. Szerk: aztán feladtam. Mindenesetre az jó hír, hogy egyes jax-ws implementációknak az is túl megterhelő, hogy az xml-fejrészbe odategyék hogy encoding='UTF-8'. Mondjuk igaz, ezzel megspórolunk vagy 17 bájtot.
És akkor még van ez a szemrehányás, ami miatt szégyellem ugyan magam, de nem egészen tudnám, hogyan tudnám jóvátenni a vétkemet:

WARNING: Using deprecated META-INF/services mechanism
with non-standard property:
javax.xml.soap.MetaFactory.
Property javax.xml.soap.SAAJMetaFactory should be used instead.

20180203.1817
Na ezt csinálja öreg barátunk, a collect2. Kikeresi a "konstruktorokat" és "destruktorokat" az összes objekt modulokból, és megír egy C-programot, ami exportál egy-egy 'init' és 'fini' függvényt, amit aztán átadunk az igazi linkernek (/usr/bin/ld):

Nem tudom, hogyan kerültem ide, de érdekes dolgok vannak itt, például:

Hát kellett már valami, túl unalmas volt minden...
Debian Stretch Lilo 24

Szerk: google barátunk ajánlata: http://forum.index.hu/Article/jumpTree?a=33011952&t=9028250

Szerk: Semmi komoly: Windows, EasyBCD, boot-menüből sda7-et kivesz, visszarak, Save, Reboot, Örül

Na de linuxon nem fordul!

In file included from /usr/include/fcntl.h:25:0,
                 from nonrandomopen.c:34:
/usr/include/features.h:332:0: note: this is the location of the previous definition
 # define __USE_GNU 1
 ^
/tmp/ccWTsAQS.s: Assembler messages:
/tmp/ccWTsAQS.s:137: Error: symbol `open64' is already defined

Szerk: Megnézetem, a /dev/urandom megnyitását akarja ezzel megakadályozni!

$ host nuku
host: /usr/local/lib64/libcrypto.so.1.0.2: no version information available (required by /usr/lib/x86_64-linux-gnu/libdns.so.162)

Így hirtelen két lehetőséget vélek látni:
1. esetleg én csináltam valamit rosszul az OpenSSL fordítása során (na jó, ez csak poén volt)
2. valaki valamit ma$zturbékolt a libdns és a libcrypto közötti kapcsolatban, ami a házilag fordított OpenSSL-ben nincs meg.

20171209.1900: 'ldd -v' találni vélt valamit:

$ ldd -v /usr/lib/x86_64-linux-gnu/libdns.so.162
         Version information:
        /usr/lib/x86_64-linux-gnu/libdns.so.162:
                ...
		libcrypto.so.1.0.2 (OPENSSL_1.0.2d) => not found

Most olvastam valahol, hogy "A 2017-es Fujitsu Forum célja, hogy bemutassa, a japán technológiai óriás milyen megoldásokat tud ügyfeleinek kínálni annak érdekében, hogy a sikeres oldalon állhassanak a tavaly ismertetett négy stratégiai vonalon: a felhő, a mesterséges intelligencia, az IoT és a kiberbiztonság területén."

Nos, a jó hír az, hogy még én (úgy is mint öregedő és a fejlődéstől lemaradó troll) is egyetértek a felsoroltak 25 százalékával. A többiről vagy nem tudom, hogy micsoda, vagy a mezőgazdasági kistermelők látásának korlátozására tartom csak alkalmasnak.

Szoftvereladók kisszótára

Ezt véletlenül találtam, és nagyon hasznosnak tűnik:
https://stackoverflow.com/questions/17124881/oracle-proc-oci-install-ha…

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

El ne felejtsem holnap tesztelni!

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!

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:

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
google-chrome 59.0.3071.115 ilyesféle broadcastokkal szórakoztatja magát, nyilván, hogy ne unatkozzon.

Azt mondja nekem a kompjuter nagy szomorúan:

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

Budapest, 117.10.6.

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

python float got a colon after the decimal point after addition

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:

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

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.

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!

Szerk: azt látom, hogy van csatolmány (valasz.txt nevű), látszólag le is tudom tölteni (telefonon vagyok Chrome böngészőben), csak a tartalma nem tökéletes: "Ezt a mellékletet a rendszer eltávolította, mert a benne szereplő adatok biztonsági kockázatot okozhatnak."

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.

Ugyanis amióta én az ámítástechnikai iparban vagyok (25 év), mindig az volt a pillanatnyi helyzet, hogy 'most éppen kirúgjuk alólatok a széket, de majd a jövőben ügyelünk, hogy minden kompatibilis legyen'

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.

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.

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