Poslední příspěvky

1

Sítě / Re:CETIN - připojení bytu

« Poslední příspěvek od Trident Vasco kdy Dnes v 18:42:12 »

...

Telecom je proste telecom a nikdy se nic nezmeni. Tech zazitku s nima mam celou radu za minulych 30 let a je to porad totez. A klidne i presne opacne = klidne ti na misto poslou technika kterej to ma zapojit a ten pak zjisti, ze nejblizsi draty koncej 5km od baraku. Ostatne parkrat sem tu psal, oni skupovali lokalni wifinare, a pak se snazili na DSL previst vsechny jejich klienty, i takovy, kterym zadny jejich draty nevedli ani na pozemek, natoz do baraku.

Nepredana sit je procesni bordel a nekdy za nej muze i developer nebo realizacni firma. Nebot Cetin sam nemusi stavet sit. Drive stavbu bylo mozne postavit i vlastni realizaci a sit se pak predavala (tohle jeste fungovalo i za O2). No a tak si to obvykle prvni clovek co mel byt napojeny vse vyzral.
Zase neni to pri tak rozsahle siti nic noveho. Da se to v pohode udelat mistnim pruzkumem.
Akorat jste narazil na nekoho pro ktereho jsou mapy siti svate. Podivejte kdyz se nepredaji radne pripojky elektriny,vody nebo plynu mate uplne stejny problem. Taky vas nepripoji.

To druhe to nebyl problem Cetinu ale O2 ktera skupovala wifinare a neresila tyto pripady. Coz mne u O2 neprekvapuje. Ti byly tak neschopni ze nebyli schopni ani prodat sluzbu na optice ktera byla dotazena az do bytu a patrila jim. Jen se zrusila a znovu zavadela sluzba po novem najemci.

2

Software / Re:BTRFS replace - zapisuje něco na původní disk?

« Poslední příspěvek od stemar kdy Dnes v 17:56:53 »

Jen update - as se někam blížím, jen tedy netuším kam. Zkusil jsem, ze zoufalství začít úplně odznovu, s novou bitovou kopií jednoho z těch původních disků (uloženou jako sda.img). Doběhl dd, pustil jsem na sda.img btrfs inspect-internal dump-super a dostal jsem:

Kód: [Vybrat]

btrfs inspect-internal dump-super --force --all  sda.img
superblock: bytenr=65536, device=sda.img
---------------------------------------------------------
csum_type               0 (crc32c)
csum_size               4
csum                    0x1d92253c [DON'T MATCH]
bytenr                  65536
flags                   0x1
                        ( WRITTEN )
magic                   ........ [DON'T MATCH]
fsid                    2db8f54a-3a36-4e3c-8e1f-6ef781966d66
metadata_uuid           00000000-0000-0000-0000-000000000000
label                   srv
generation              1598019
root                    6673317888
sys_array_size          258
chunk_root_generation   1598019
root_level              1
chunk_root              67139272704
chunk_root_level        0
log_root                0
log_root_transid (deprecated)   0
log_root_level          0
total_bytes             246096592896
bytes_used              53234524160
sectorsize              4096
nodesize                16384
leafsize (deprecated)   16384
stripesize              4096
root_dir                6
num_devices             2
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x161
                        ( MIXED_BACKREF |
                          BIG_METADATA |
                          EXTENDED_IREF |
                          SKINNY_METADATA )
cache_generation        1598019
uuid_tree_generation    1598019
dev_item.uuid           f3793453-4d55-46eb-9388-e9e716178818
dev_item.fsid           2db8f54a-3a36-4e3c-8e1f-6ef781966d66 [match]
dev_item.type           0
dev_item.total_bytes    123048296448
dev_item.bytes_used     60196651008
dev_item.io_align       4096
dev_item.io_width       4096
dev_item.sector_size    4096
dev_item.devid          2
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

superblock: bytenr=67108864, device=sda.img
---------------------------------------------------------
csum_type               0 (crc32c)
csum_size               4
csum                    0xbdf30df2 [DON'T MATCH]
bytenr                  67108864
flags                   0x1
                        ( WRITTEN )
magic                   ........ [DON'T MATCH]
fsid                    2db8f54a-3a36-4e3c-8e1f-6ef781966d66
metadata_uuid           00000000-0000-0000-0000-000000000000
label                   srv
generation              1598019
root                    6673317888
sys_array_size          258
chunk_root_generation   1598019
root_level              1
chunk_root              67139272704
chunk_root_level        0
log_root                0
log_root_transid (deprecated)   0
log_root_level          0
total_bytes             246096592896
bytes_used              53234524160
sectorsize              4096
nodesize                16384
leafsize (deprecated)   16384
stripesize              4096
root_dir                6
num_devices             2
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x161
                        ( MIXED_BACKREF |
                          BIG_METADATA |
                          EXTENDED_IREF |
                          SKINNY_METADATA )
cache_generation        1598019
uuid_tree_generation    1598019
dev_item.uuid           f3793453-4d55-46eb-9388-e9e716178818
dev_item.fsid           2db8f54a-3a36-4e3c-8e1f-6ef781966d66 [match]
dev_item.type           0
dev_item.total_bytes    123048296448
dev_item.bytes_used     60196651008
dev_item.io_align       4096
dev_item.io_width       4096
dev_item.sector_size    4096
dev_item.devid          2
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

Jak já to čtu, tak tam našel 2 kopie superblocku (na třetí není místo, je to 128G disk), celkem smysluplně oba naplněné, nesouhasí magic - očekávané a csum - nevím ale to může být tím přepsaným magic. Celkem tedy docela nadějné.
Neudělám nic jiného než že přepíšu to magic v obou superblocích:

Kód: [Vybrat]

echo "_BHRfS_M" | dd bs=1 count=8 of=sda.img  seek=$((64*1024+64))
8+0 záznamů přečteno
8+0 záznamů zapsáno
8 bajtů zkopírováno, 0,000129285 s, 61,9 kB/s

echo "_BHRfS_M" | dd bs=1 count=8 of=sda.img  seek=$((64*1024*1024+64))
8+0 záznamů přečteno
8+0 záznamů zapsáno
8 bajtů zkopírováno, 0,000323182 s, 24,8 kB/s

a dám znovu btrfs inspect-internal dump-super ať vidím, co jsem udělal. A co nevidím a svým očim nevěřím:

Kód: [Vybrat]

btrfs inspect-internal dump-super --force --all  sda.img
superblock: bytenr=65536, device=sda.img
---------------------------------------------------------
csum_type               0 (crc32c)
csum_size               4
csum                    0x1d92253c [DON'T MATCH]
bytenr                  65536
flags                   0x1
                        ( WRITTEN )
magic                   _BHRfS_M [match]
fsid                    2db8f54a-3a36-4e3c-8e1f-6ef781966d66
metadata_uuid           00000000-0000-0000-0000-000000000000
label
generation              0
root                    0
sys_array_size          0
chunk_root_generation   0
root_level              0
chunk_root              0
chunk_root_level        0
log_root                0
log_root_transid (deprecated)   0
log_root_level          0
total_bytes             0
bytes_used              0
sectorsize              0
nodesize                0
leafsize (deprecated)   0
stripesize              0
root_dir                0
num_devices             0
compat_flags            0x0
compat_ro_flags         0x0
incompat_flags          0x0
cache_generation        0
uuid_tree_generation    0
dev_item.uuid           00000000-0000-0000-0000-000000000000
dev_item.fsid           00000000-0000-0000-0000-000000000000 [DON'T MATCH]
dev_item.type           0
dev_item.total_bytes    0
dev_item.bytes_used     0
dev_item.io_align       0
dev_item.io_width       0
dev_item.sector_size    0
dev_item.devid          0
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0

ERROR: failed to read the superblock on sda.img at 67108864 read 72/4096 bytes
ERROR: error = 'Success', errno = 0

Tedy magic v prvním superbloku už sedí, zato se z něj ztratila podstatná část dat, od label dále. Druhý superblock zmizel úplně -

failed to read the superblock on sda.img at 67108864

Co to, sakra, je? dd dostal 8 znaků, tvrdí že zapsal 8 znaků, dokonce tam těch 8 znaků vidím na správném místě... Kam, sakra, zmizel ten zbytek superblocku a proč?

3

Odkladiště / Re:AI pro analýzu obsahu mnoha dokumentů

« Poslední příspěvek od Tomas-T kdy Dnes v 17:27:35 »

Ano, AI obecně je správný nástroj na podobnou práci.
Ne, současný GPTChat není vhodný nástroj na podobnou práci.
I naše firma vyvíjí online nástroj pro těžení faktur a účtenek, je je IČO samozřejmě jednou ze získávaných položek.
Krmí se to přes API, přes mail nebo z nějakého připojeného online úložiště.
Ale není to zadarmo a demoverze má samozřejmě striktní omezení na počet dokumentů (ani nevím, zda to nakonec kolegové nezprovoznili jen na pozvánky, žádné veřejné demo pro každého).
O ekonomické návratnosti vývoje té aplikace si sice myslím své, ale technicky to funguje.

4

Bazar / Re:Prodám Tuxedo InfinityBook Pro 15 - Gen9 - AMD

« Poslední příspěvek od Rike kdy Dnes v 17:24:28 »

Ta nabídka je spíš pro někoho, kdo skutečně uvažuje, že si koupí nové Tuxedo s AMD. Výhodou je, že nebude muset čekat 2-3 týdny a řešit klávesnici. Řekněme, že ten layout klávesnice jsem ochotnej dát zdarma, tedy sleva cca 5% z původní ceny (2160 Euro).

Jinak je to úplně nové, nakrouceno to nemá ani 30 hodin. Záruka je přikoupená tříletá a když předám Tuxedo účet novému majiteli, má ji automaticky on.

Takhle nabouchané jsem na trhu našel akorát jedno Lenovo (bavíme se o AMD Zen 4) a nějaký Zbooky. Lenovo je snad s Linuxem obvykle v pohodě, jak je to u HP, to nevím, ale dřív s tím bylo dost problémů. Tohle je pro Linux postavený a odzkoušený.

Na prodeji samozřejmě netrvám, tedy že bych to chtěl za každou cenu prodat, i za těch nabízenejch 15 tisíc. Pořád to něj můžu nacpat Widle a vyhodit stávající workstation. Jen je to škoda, když už je to navržené pro Linux, tak jen kdyby někdo měl fakt vážný zájem...

5

Sítě / Re:CETIN - připojení bytu

« Poslední příspěvek od armyk kdy Dnes v 17:04:07 »

Update pro vsechny.
1) Psal jsem na CETIN. Tam se vyjadrili, ze tam sit je, ale ze nekdo (majitel, respektove SVJ to zamitli cca 3 roky zpet). A ze dodelani je mizne se souhlasem a zadosti o incesticni akci u nejakeho poskytovatele. Divny, protoze to stejnak budou realizovat ani, ale budiz.
2) Napsal jsem tedy na 02. Hlavne proto, ze maji moznost krasne komunikovat pres iMessage, funguje to paradne. Pani ze tam je pouze DSL.
3) Logicky jsem nemel zajem a rikam jak ziskat optiku. Ona se uvolila, ze to proveri s Cetinem.
4) za cca tyden odpoved, ze uz kontaktovali nekoho z SVJ a ze souhlasil a uz tu pry nekdo byl se domluvit a instalace na konci mesice.

Takze je to porod, vsechno dela Cetin, ale musi se jit pres operatora, jinak se s vami nebavi.

No tak to jen takova zkusenost pro ostatni….

6

Studium a uplatnění / Re:Potřebuje embedded vývojář vyhlášku 50?

« Poslední příspěvek od Jaroslav Juha kdy Dnes v 17:02:11 »

Takze kdyz prohlasim, ze rizika prace na VVN pod napetim jsou nulova, tak sem prave splnil svou povinost a zadny skoleni nepotrebuju.

No to snad ne. To jako že podle Vás mohu v ČR pondikat jako elektrikář/výrobce nebo opravář elektrických strojů/výrobce rozvaděčů nebo cokoliv podobného, přijímat a plnit zakázky a to vše tak, že sám prohlásím, že je to bez rizika a nepotřebuji vůbec nic?? To asi ne...

7

Vývoj / Re:Bind socketu na konkrétní síťovou kartu v C

« Poslední příspěvek od M_D kdy Dnes v 16:43:03 »

Já chválím za ten rp_filter - bez jeho vypnutí to nefunguje, pokud mám víc síťovek ve stejném IP segmentu. :-)
Jsem to zkusil pustit. Funguje to a data dojdou zpět do recvfrom(). Pokud binduji konkrétní iface a client IP, tak by měla být shoda toho IP a iface, datagram musí přijít tím bindnutým ifacem a navíc musí být vypnutý rp_filter pro daný iface (zkrátka musí souhlasit na příchozím daná IP a iface). Pokud jako odchozí IP dám jinou, než odpovídá na vynucený iface, tak ono to odejde přes bindnutý iface se zadanou IP, ale vlivem ARP a forward tabulky ve switchi se odpověď vrátí často jiným ifacem a je smůla (pokud se vrátí tím předepsaným, tak se data také doručí do recvfrom()). Je to celkem striktní v případě unicast provozu.

8

Hardware / Re:Levný nevýkonný hardware na virtualizaci

« Poslední příspěvek od dj-bobr kdy Dnes v 16:24:49 »

Kdybych šel po něčem seriózním, tak koupím buď něco nového (NUC) a nebo Dell PowerEdge R620 či podobný repas z CzechServeru (ano, i to byla jedna ze zvažovaných možností), ale toto je domů do labu, nejde o výkon, největší důraz je na spotřebu (u rackáren se těžko dostává pod 50W), klidně i mírně zabastlim (aspoň boost měnič z 12V rozvodu na 19V DC vstup..) a cílem je vybrat něco tak do dvou tisíc včetně dopravy

Tak to PPS není až tak kritický, v nouzi rozchodím GPS na NanoPI NEO, které mám v šupleti nevyužité a pár GPIO pinů má. Nebo zkusím vymyslet něco, co by GPIO nahradilo (takže nějak po vánocích nastuduju, co běžného jede interruptem a ne pollingem, DSR/CTS/DCD/RI u HW sériáku, nějaký input pin LPT, něco jiného na SuperIO švábu..).
A nebo oželím multilateraci letadýlek, nejde o život.

Zatím největší pomyslné skóre má u mě řešení na HP T640 a možná dřív ještě zkusím tu desku z ThinkPada W541, jestli v pohodě pojede (dělal jsem na ní nějaké pokusy s SPI flashema).

9

Odkladiště / Re:AI pro analýzu obsahu mnoha dokumentů

« Poslední příspěvek od XXX_Sam_XXX kdy Dnes v 16:21:11 »

Pokud umíš aspoň trochu kódit, tak
https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/invoice?view=doc-intel-4.0.0

Pokud neumíš, tak nějaké hotové řešení
https://www.algodocs.com/

Bude jich určitě daleko víc.

Né že bys neuměl s ChatGPT, jen si spíš neprostudoval jeho použití. Samozřejmě oni ti tam nechtějí dávat takovéto funkce.
OpenAI má další služby, kde jde nahrávat soubory pomocí API. Ale opět musíš umět aspoň trochu např. Python.

10

Software / Re:BTRFS replace - zapisuje něco na původní disk?

« Poslední příspěvek od stemar kdy Dnes v 16:15:50 »

Fakt moc oceňuji tu snahu pomoci. U mě je to nějaké složitější. BTRFS tvrdošíjně hlásí chybu superblock checksum a to na všech kopiích superblocku. Jsem si 100% jistý, že jsem na těch původních discích žádnou operaci nedělal, první operací poté co jsem zjistil že nejdou namountovat bylo dd do souboru na jiném disku a vše ostatní pak probíhalo až tam.
Že ale nějakou záchrannou operaci neudělal proaktivně za mými zády nějaký mountovací démon (Kubuntu), to už si tak úplně jistý nejsem...
Uvidím, celé to vlastně od začátku bylo myšleno jako trénink, rozšíření znalostí o BTRFS, to se tedy naplňuje měrou vrchovatou...