NevemTeve blogja

Üdvözlet Tükörországból (vö: Lewis Caroll: Alice Tükörországban)

 ( NevemTeve | 2018. január 15., hétfő - 15:23 )

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

LinuxEBDA is big; kernel setup stack overlaps LILO second stage

 ( NevemTeve | 2018. január 10., szerda - 8:22 )

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

libzip sem fordul

 ( NevemTeve | 2017. december 13., szerda - 19:24 )

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!

libcrypto.so.1.0.2: no version information available

 ( NevemTeve | 2017. december 9., szombat - 16:08 )

$ 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:
[code]
$ ldd -v /usr/lib/x86_64-linux-gnu/libdns.so.162
Version information:

Egy a négyből: nem is rossz

 ( NevemTeve | 2017. november 10., péntek - 18:57 )

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

Szoftvereladók kisszótára

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

Szoftvereladók kisszótára

Oracle must have

 ( NevemTeve | 2017. október 23., hétfő - 19: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 - 18: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ő - 10: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 - 12: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ő - 17:19 )

Azt mondja nekem a kompjuter nagy szomorúan:

Egy megkésett Y2000

 ( NevemTeve | 2017. október 6., péntek - 13: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 - 8: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 - 19: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 - 12: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 - 18: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 - 9: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 - 14: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 - 15: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 - 20: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 - 17: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 - 18: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 - 18: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ő - 18: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 - 12: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.