Příspěvky

1

Server / Re:Proč něco zabíjí službu v systemd?

« kdy: 14. 08. 2023, 18:29:30 »

Proces může zabít kohokoliv kde má práva, včetně sám sebe.  Dokonce existuje funkce `raise`, která pošle signál na sebe sama.

Ten ABRT smysl dává a může to být ošetření fatální chyby dotNet runtime - v C je to typicky výsledek `abort()` nebo selhaného `assert`.  KILL je zvláštní, ale možná to dotNet runtime nebo nějaká knihovna řeší takhle místo ABRT.

V každém případě by šlo asi dát breakpoint na `raise()` nebo `kill()` a zjistit stacktrace, kdo se sestřelí.  Taky bych čekal, že aplikace bude mít nějakou snahu zalogovat fatal error předtím, než se zabije - nějaké lokální soubory, dump nebo system log atd.

2

Vývoj / Re:Využíváte umělé inteligence běžně?

« kdy: 20. 06. 2023, 17:54:42 »

skvely komentar, mi pripada, ze nejvice chatgpt pouzivaji kolegove juniorove, ktere se ptaji jak neco maji udelat, kdyz nevi jak zacit.

A nebo zkušení kolegové, kteří se dostávají do nové oblasti.

Nedávno jsem se učil Python a k tomu hodně specifické použití.  ChatGPT pomohl opravdu hodně, kdy bych musel brouzdat dny v dokumentaci a kódu, abych udělal, co jsem potřeboval.  Některé odpovědi byly sice špatné, některé vysloveně sebejistě lhal, ale v zásadě ty příklady byly dost dobré, aby buď fungovaly nebo měly chyby, ale nasměrovaly mě na správnou už velice specifickou dokumentaci.

Jeden z vtipných příkladů (podotýkám, že tady jsem byl opravdu líný a dal jsem dotaz jenom ze setrvačnosti), byla priorita walrus operátoru a porovnání v Python (if a:= expr is not None).  Nejdřív odpověděl kontraindikativně, že závorky nejsou potřeba kvůli vyšší prioritě :=, ale závorky tam napsal: if (a := expr) is not None .  Tak jsem zkusil, že píše, že walrus má vyšší prioritu, tak proč je tam píše - doplnil závorky na: if ((a := expr) is not None) .  Tak jsem zkusil ještě jednou - opět se omluvil a vyhodil závorky úplně: if a := expr is not None .  A to samozřejmě nefunguje, bo priorita je přesně opačná :-D .

Takže i přes ty chyby za mě dobré.  Dokáže poskytnout hodně užitečných informací a je to dramaticky rychlejší na učení než google.

3

Hardware / Re:Výběr notebooku od Dellu pro programátora

« kdy: 13. 09. 2022, 18:52:02 »

Používal jsem pro vývoj (hlavně java) necelé 2 roky Latitude 5510 ve variantě s i5 9300H.  ... Kolega stejný model akorát s "U" verzí CPU měl a přehřívání nepozoroval.

Dobrá poznámka.  U porovnání, co jsem psal, byly i7-1185G7 v Latitude 5320 a i7-1195G7 v XPS 13" .  Oba mají podle Intel stejné TDP, ale XPS byl znatelně víc horký.  "H" high performance do notebooku rozhodně nebrat, předpokládám, že G7 jsou něco mezi.

4

Hardware / Re:Výběr notebooku od Dellu pro programátora

« kdy: 12. 09. 2022, 22:51:10 »

Latitude, Precission a XPS jsou asi hlavní řady, které stojí za úvahu, jak psal mikrom.  XPS je víc na design a limity, co lze dnes dosáhnout.

Já mám Latitude 5320, 32 GB RAM, 512 GB disk.  Měl jsem XPS 13" (32 GB RAM, 1 TB disk), který jsem po týdnu nebo dvou vrátil.  Porovnání:
- Všechny (13") mají přileptanou RAM, takže nejdou rozšířit (bez drsnějších metod).
- Oba jsou poměrně lehké, XPS mírně níž.  Latitude mi přišel vizuálně odolnější, ale fyzicky jsem nezkoušel :-D
- Latitude měl menší disk, 512 GB je trochu málo na dual boot.  To byla aktuální volba, je dobré myslet dopředu.
- XPS je tenký, prostě na limitu, jak se dá elektronika nacpat do nejmenšího prostoru - prakticky závodí s Apple (možná už dozávodil po přechodu Apple na M1).
- Latitude je celkem chladný při normální práci a přijatelně teplý i při zátěži.  XPS měl teplou klávesnici i při normální práci - na psaní ok, ale nechat prsty na klávesnici pár vteřin ležet bylo dost nepříjemné.  To byl důvod, proč jsem ho nakonec vrátil.

Linux:
- Na Latitude nepoznal odpojený zdroj při default plánu nabíjení v BIOSu (connected but discharging).  Ten druhý (méně agresivní) fungoval správně.
- Tapping na touchpad vyžadoval úpravu xorg.conf , myslím, že u obojích.  Není to velký problém, spíš něco, co by mohly distribuce dávno vyřešit - nevím, zda je to specifické pro Dell nebo to nefunguje všude...
- Jinak žádné problémy v Linuxu.

5

Studium a uplatnění / Re:Vhodnost notebooku s Apple Silicon pro studium na VUT FIT

« kdy: 08. 09. 2022, 21:53:16 »

Co je špatného na MacPorts?

MacPorts jsem nepoužíval, jenom Homebrew.  Co jsem pochopil ze srovnání, tahá si MacPorts víc závislostí s sebou, jinak jsou podle recenzí srovnatelné (ale jak říkám - bez osobní zkušenosti).  U Homebrew jsem viděl dvě velké nevýhody ve srovnání s Linuxovými distribucemi:
- Nesrovnatelně míň balíčků: Perl modules jsem například musel skoro všechny tahat přes cpan.  V Ubuntu / Debian vždycky jako balíček, u Redhat až na pár obskurnějších taky.
- Kompilace SW ze source code (jakože stažena mimo Homebrew) si ne vždycky dokázala poradit s nestandardní instalací závislost z Homebrew.  Nebylo to obvykle těžké opravit, ale je to práce navíc u něčeho, co v Linuxu funguje přirozeně díky standardním cestám.

Ale každý dva roky budete čelit nutkání koupit nový model - opět od aple, laple od aple, hodinky od aple... taková čtyřčlenná rodina jen za 4 mobily a příslušenství může vysolit co dva roky 200k jen to fikne.

Nutkání koupit nebo nekoupit nový model má každý bez ohledu na značku.  Znám spoustu lidí, kteří používají iPhone starý 4 roky a žádné nutkání nemají.  Naopak, díky podpoře funguje velice dobře, často líp než Android (co bych za to dal).  Otazníkem je kvalita - mi se u dvou pracovních Macbook nafoukla baterka, ten druhý možná pravda kvůli přehřívání a vylitém pití.  Celé je to horší s novými modely a jejich neopravitelností.  Ale kupovat si nový laptop jen pro to, že existuje novější, je nesmysl, zvláště, když ten vývoj se poslední dekádu nijak extra neposouvá (s výjimkou přechodu na aarch64).

Ale opravdu to tak je, myslim že na ajfounu vyfotíš fotku a máš ji na cloudu. To samé stáhneš soubor, hudbu, film... Nic nemusíš dělat, nastavovat. Rozbije se ti ajfoun - koupíš nový, ťup, a máš tam všecko co jsi měl na starým. fotky, všecko.  V podstatě ani nemusíš vědět, kde to vlastně je...  Je to pohodlnější než se mořit s ftp, sambou, rsyncem atd. 
Pro někoho kdo nechce, nepotřebuje nebo nerozumí technice je to úžasné.
Současně je to poměrně bezpečné.

Ale ano, je to přístup ala čtyřleté dítě. Mě se to nelíbí taky.

Tohle je standard i u Google Photos třeba.  Jaké by mělo být správné řešení - všechno neustále synchronizovat ručně?  Synchronizace do/z cloud je zrovna část, kde ten rozvoj technologie oceňuju - fotky, kontakty, nastavení, historie atd.

6

Studium a uplatnění / Re:Vhodnost notebooku s Apple Silicon pro studium na VUT FIT

« kdy: 06. 09. 2022, 19:45:07 »

Stejně jako na Linuxu, macOS je čistokrevný Unix (certifikovaný POSIX), akorát vychází z BSD, takže například má kqueue místo epoll, ale rozdílů je dost málo (a kde jsou, je na vině Linux, protože nepodporuje plně POSIX).

Linux není POSIX, protože se nikomu za to nechce platit, viz odpověď na https://unix.stackexchange.com/questions/522413/why-are-most-linux-distributions-not-posix-compliant .

Jinak defakto POSIX, ANSI C atd splňuje.  Problém je, že POSIX a ANSI C jsou dobré pro běžné projekty, ale nedostatečné pro vysoce optimalizované servery ohledně networking, storage a cokoliv dalšího.  Takže různé systémy přišly s různými řešeními a standardy jsou vždycky o kus pozadu.  Viz například kqueue vs epoll - POSIX měl dlouho jen select, později poll, druhý o něco lepší než první, ale oba nepoužitelné pro high concurrency networking.  Situace je ještě o něco horší, bo POSIX se zpožděním dohání vzniklé mezery, ale programy se stejně píšou tak, aby běžely i na starších systémech - jako příklad open_memstream - pěkná funkce, ale standardizována až od roku POSIX 2008.  Na spoustě ostatních UNIXů nejspíš není ještě dnes.

By mne zajímalo co lidi vidí na Applu tak zázračného!

Kombinace hardware a podporovaného software:
- Hardware: měl Apple vždycky na špičce (samozřejmě i cenově) - rozlišení displeje nejvyšší, váha nejnižší, rozumné chlazení, které udržuje laptop výkonný a zároveň přiměřeně chladný.  Od M1 nemá konkurenci - chladný laptop s bezkonkurenčním výkonem a tichým chlazením (potenciálně pasivním) a výdrží na dvoj-trojnásobku oproti konkurenci.
- Software: V prvé řadě je v zájmu komerčního SW, jako například MS Office, což je pořád v řadě korporací standard.  V předchozím zaměstnání jsem si z toho důvodu vybral Apple, kolega si vybral Linux.  Integrace na maily snad nějak fungovala, ale byla o dost komplikovanější, na něco snad používal virtualizované Windows.  V nové práci jsme modernější, takže jedem přes web, kde to jde, ale pro starší korporáty je pořád Windows nebo MacOs nejschůdnější volba.

Samozřejmě je tu spousta proti - Linux rozhodně dává víc svobody, jaký software použít a instalace balíčku je mnohem lepší než na Homebrew.  To na těch bodech výš ale nic nemění.

Osobně preferuju Linux hlavně kvůli prostředí (Linuxové virtuální desktopy mi vyhovují o dost víc než MacOs například).  Ideálně bych měl M1 hardware a na něm Linux, stejně jako to vyřešil Linus Torvalds.  Ale to je u současného zaměstnavatele práce navíc, která se mu nevyplatí, zvláště, když většina je s MacOs spokojena.

7

Vývoj / Re:TIME_WAIT po ukončení socket-komunikace

« kdy: 08. 08. 2022, 13:21:58 »

Obvykle je to kvůli chybějícímu shutdown() .  Samotný close() nestačí, bo ten vzniká i automaticky se zánikem procesu a není jasné, jestli ještě něco odněkud nepřijde.

8

Vývoj / Re:Kolik je potřeba RAM, aby tento kód doběhl? :D

« kdy: 06. 08. 2022, 07:31:54 »

Teď jsem si všiml, že prvků je 11, ne 10.  Takže všechny kalkulace vynásobit 2.6* ...

9

Vývoj / Re:Kolik je potřeba RAM, aby tento kód doběhl? :D

« kdy: 06. 08. 2022, 07:26:04 »

720 GB + něco málo.  Dvouprvkový tuple zabere 56 B, zaokrouhleno na 64 B a celé pole bude mít 8 B na prvek.  Samotné hodnoty budou sdílené.

Za předpokladu, že ta velikost zahrnuje i alokační overhead, jinak bude dalších 16 B navíc na každý tuple.  Navíc může celý seznam růst po skocích, což by mohlo jít až na 128 GB na výsledné pole, místo 80 GB.

10

Hardware / Re:Menší telefon

« kdy: 05. 08. 2022, 16:01:13 »

Pro nějaké uzavření - nakonec jsem skončil u Asus Zenfone 8.  Rozměrově je prakticky stejný jako původní Nokia 4.2, takže mi hezky vleze do cyklistické tašky.

HW zatím dobrý, paměť i storage by snad měla dostačovat.  Notifikační dioda je opravdu mini, snad si zvyknu.  Cena 12 kKč, což mi přijde pro moderní telefon, který by snad měl 3 roky vydržet, celkem ok.

Jediná neznámá zůstavají security updates.  To prakticky diskvalifikovalo Samsung A41, případně i poslední zmiňovaný Sony Xperia XA2 (je pravda, že někdo zmiňoval, že Asus na to taky docela kašle, tak je to s otazníkem).  LineageOs je případné řešení, když podpora vyprší, ale historicky jsem na něm ztroskotal - aplikace strašně padaly, dost možná kvůli poddimenzovanému HW, který už novějším verzím nestačil.  Takže riziko zastarání se snažím řešit po HW i SW stránce, abych se k téhle noční můře mohl vrátit nejdřív za 2-4 roky.

Díky všem za rady!

11

Hardware / Re:Velikost SSD Macbooku pro programátora (Air vs Pro)

« kdy: 03. 08. 2022, 11:57:06 »

Plánuju LAMP a do budoucna s Dockerem a prostě musim doufat, že bude stačit. Příplatek za 16GB je 12 000 a to je nogo pro mě.. Tady někdo rozjel Docker s PHP dokonce na 8GB https://www.peckadesign.cz/blog/macbook-air-8gb-m1-smysluplny-pomocnik-na-webovy-vyvoj

Na konci článku píše autor, že 8 GB šlo přežít, ale je to málo.  Dle mých zkušeností MacOs žere víc RAM než Linux - nevím, co za tím je, jestli si alokuje šílené buffery navíc nebo jsem měl jen smůlu na výběr aplikací.

Pokud je 12000 navíc problém, tak bych asi nezvažoval Mac, bo s 8 GB RAM bude za rok nepoužitelný.  Alternativně buď něco jiného nebo jeden nejmenovaný e-shop nabízí pronájem za 42 Kč / den (16 GB RAM, 1000 GB disk).  To je na 2.5 roků stejná cena jako základní model (8 GB RAM, 256 GB disk), který takovým použitím odrovnáš mnohem dřív.  A za těch 2.5 roků si koupíš něco použitelného...

12

Hardware / Re:Velikost SSD Macbooku pro programátora (Air vs Pro)

« kdy: 02. 08. 2022, 12:09:50 »

250 GB je dost minimum i na běžnou práci.  Pokud zůstaneš u LAMP stack, s pár závislostma, tak to asi půjde přežít, ale reálně si stáhneš pár git repository, nějaké hračky kolem, IDE, k tomu připočítej dnešní browser s cache a disk je fuč.

Klíčová je ale paměť.  Opět - PHP je hračka, která nic moc nežere, ale všechny věci kolem už ano - systém samotný, IDE a hlavně browser - pár oken s JavaScript a lítá to v GB...

Pro srovnání: Já kupoval notebook nedávno osobní a podmínky byly minimálně 32GB RAM a 512 GB disk.  U obojího si říkám, že jsou teď na hraně.  V práci jsem měl Mac 2015, 16 GB RAM, 512 GB disk.  Neustále 8-12 GB ve swap, po 2-3 letech tak pomalý, že se s tím pracovalo opravdu blbě - nevím, jestli samotný nedostatek RAM s rostoucí náročností JavaScript stránek nebo ten swap už opotřeboval SSD natolik, že s bídou hledal funkční místo, expert nejsem.  V nové práci jsem dostal Mac 16 s M1 Pro, 32 GB RAM a 512 GB SSD.  Nově používám docker a už jsem opět pár MB ve swap.  Co se s tím stane za rok nebo dva - bůh suď...

13

Vývoj / Re:jak skriptem udělat ~md5 bloků disku, paralelizovaně

« kdy: 29. 07. 2022, 14:51:55 »

shell je na paralelizaci peklo.

Buď Java nebo python (python je taky s otazníkem, ale pokud bude kód mimo GIL, tak asi půjde).  Řešení v Java:
1. Namapovat celý disk do paměti, případně po částech (celý v základní Java nepůjde - má limit 2GB).
2. Vytvořit Executor.
3. Tlačit do do Executor jednotlivé tasky (podle bloků) a omezit je počtem CPU, případně mírně vyšším v závislosti na zpoždění IO.  Tasky budou počítat MD5 nebo kontrolovat nuly apod.
4. Ve správném pořadí vyhodnocovat výsledky (zapsat je do výstupu nebo cokoliv) a cpát do Executor další bloky.  Kdysi jsem řešil podobný problém a publikoval: https://github.com/dryuf/dryuf-concurrent/blob/master/src/main/java/net/dryuf/concurrent/executor/CapacityResultSerializingExecutor.java
5. Čtení z disku můžou dělat přímo ty tasky a jít přímo po bytech, místo, aby četly bloky do další paměti.  Podle overhead může být kontraproduktivní, záleží na JVM, jak moc to zoptimalizuje.
6. Alternativně, pokud by IO bylo špatné v nesekvenčním přístupu (staré HDD), tak v takovém případě může být lepší načíst celý blok v hlavním vláknu.

Jestli dobře počítám, tak při 50 MB/s, 4 jádra a 5 TB disk, celá věc proběhne za 25000 s, tedy zhruba 7 hodin...?  I v jednom vlákně půjde "jen" o 1 den.

14

Hardware / Re:Menší telefon

« kdy: 12. 07. 2022, 13:31:25 »

Díky všem za tipy.  Hledal jsem původně podle velikosti displeje (5.7"), koukám, že doba pokročila, a na stejnou velikost se dá nacpat větší displej...

Unihertz vypadá jako naděje, že se snad do budoucna někdo najde, kdo bude reagovat na minoritní trh .  Zatím ale trochu pod mou preferenci.

Jak je to teď s podporou.  Vybral jsem si předtím Nokia 4.2, neboť byla Android One, takže pravidelné updaty.  Předchozí Huawei a Samsung bylo v tomhle peklo.  Zlepšilo se to nebo je to pořád s bídou první rok a potom vlci sežerte mě?

15

Hardware / Menší telefon

« kdy: 11. 07. 2022, 20:27:36 »

Potřebuju obnovit telefon (mírně rozbitý displej, málo paměti atd, jinak jsem spokojený).  Původně Nokia 4.2, 5.7" displej, těsně se vleze do cyklistické tašky pod sedlo.

S ohledem na poslední bod potřebuju něco podobné, což se zdá v poslední době téměř nemožné.  Hrubé podmínky:
- maximální rozměry: 150*71*9 mm (což je ta Nokia 4.2 a je to skutečně maximum, +- 1mm)
- dual SIM
- 4GB RAM, možná víc
- 64GB storage
- NFC

Rozměrově sedí iPhone a Google Pixel, ale neumí dual SIM, která je pro mě klíčová.

Po aplikaci filtru v nejmenovaném e-shop n mě vypadl prakticky jediný odpovídající Samsung XCover 5, který by asi šel (paměť je na hraně, takže nevím, jestli rychle nezastará), ale je to zbytečně moc do terénu.

Je to skutečně tak, že jsou v nabídce už pouze telefony mířící velikostí k tabletům nebo je někde alternativní obchod s něčím bližším opravdu telefonům?

Díky za doporučení.