Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: 1 ... 9 10 [11] 12 13 ... 84
151
Jestli je to na kraji vesnice, tak bych se třeba úplně nebál jet bez šifrování... obecně jako lepší variantu vidím, udělat na tom GUEST essidu normálně WPA2 šifru a zájemcům dávat heslo. V tom případě se klienti nemohou odposlouchávat navzájem, s výjimkou broadcastového provozu. Jako na metalickém switchi.
Na otevřené síti může kdokoli v doslechu odposlouchávat hesla, která nejdou nad end-to-end šifrováním typu SSL/SSH. Tzn. klasické FTP, POP3, HTTP apod. se odposlechnout dají.

Tzn. ty sítě mohou být i tři:
1) interní LAN
2) sousedi
3) kdokoli kdo jde okolo. Heslo si klidně vylepte na vrátka.

Vykousnout guestovský ESSID+subnet lze velmi účinně v případě, že AP je zároveň NAT routerem do divokého internetu. Pokud AP jako uplink používá vnitřní LAN, je ta guestovská síť jenom zabalená do NATu, ale její traffic jede dál skrz interní LAN směrem na upstream gateway do internetu. Jak správně píšete, v tom případě je řešením, udělat pro guesty nejen ESSID, ale taky ohraničenou VLAN.

VLAN na Mikrotiku jsem potkal jednou, na switchi CRS-112 (RouterOS). Pro mě rozmazleného Ciscem a D-Linkem to bylo na Mikrotiku trochu přes koleno (každá VLAN asi na 3 kroky), ale nakonec jsem to dal. Kdyžtak prostě tady dál rozvíjejte téma.

152
Hardware / Re:Tiskové jazyku u tiskárny
« kdy: 02. 04. 2023, 22:43:44 »
Jak je to ohledně porovnání výstupu? Kde ne největší změna pokud použiju jednotlivé tiskové jazyky?
Např. u CAD aplikaci. tlouštíka čar, měřítko atd.

Tloušťka čar a měřítko by měly vyjít přesně stejně.

Teoreticky vektorové formáty (PS, PDF, ehm HPGL) by mohly kreslit jemné detaily trochu líp, ale to zjistíte spíš pod lupou. U hloupých formátů, kde do tiskárny jde už celostránková bitmapa v pevném rozlišení, máte šanci ovlivnit rozlišení té bitmapy. Takže třeba dithering šedých tenkých čar může být znát (v hrubším rozlišení). Tuším na to bývaly i nějaké testovací obrazce.

Dnešní kancelářské lasery mívají běžně 600 dpi (= pixelů na palec) ale ty obrazové body jsou černobílé tečky = barevná hloubka 1 bit. Plochy polotónů jsou emulovány buď pravidelným ditheringem nebo chybovou difuzí (Floyd-Steinberg). Rozdíl mezi 300 a 600 dpi je u jemných čar a polotónů poměrně znát.

Poňouknut Vaším dotazem, vyrobil jsem jednoduchý vektorový testovací obrazec: hvězdu z tenkých čar, rozteč 5 stupňů. Matici obrazců na A4 přikládám. V matici vodorovně tloušťka čáry 0.1/0.2/0.3 mm, svisle sytost 100/75/50/25% (černá a odstíny šedé). Zkusil jsem to na své m227 vytisknout ve třech variantách:

Výsledky jsem skenoval opět v m227 v rozlišení 1200 dpi (víc skener neumí).
Tady k příspěvku mám omezení na 4 přílohy - přikládám zipnutý původní obrazec v obou formátech a tři zajímavé výřezy ze skenů. Vynechávám nudné "bezchybné" obrazce typu 100% sytost v 600dpi nebo PS. Výše v textu jsou odkazy na kompletní A4 skeny - ve formátu PNG (= bezeztrátové), výsledné soubory mají každý asi 15 MB (surová data asi 150 MB každý obrázek).

Ve variantě "PCL5 v pevném rozlišení" bylo zajímavé, že nehrálo roli, zda v ovladači řeknu "poslat grafiku jako vektory" vs "jako bitmapy" - dithering polotónů vyšel v obojím případě přesně stejný. Zato se ve variantě PCL5 mírně lišilo moiré podle toho, zda jsem tiskl z PDF (Acrobat Reader) nebo přímo z Inkscapu (backend "vector"). Přiložené skeny jsou z PDF/Acrobatu.

Ve variantě PostScript při sytosti nižší než 100% je zajímavý "světlejší střed hvězdy" - patrně nějaké moiré ditheringu na mnoha překrytých čárách. Nedomyšlenost renderovacího enginu v tiskárně. Toto se chovalo shodně při tisku z Acrobat Readeru a z Inkscapu.

V některých ovladačích býval ke konfiguraci algoritmus ditheringu bitmap. V aktuálních ovladačích HP Universal Printing tato volba není. Takže Floyd-Steinberga leda v Irfanu v rozlišení tiskárny a výstup tisknout jako bitmapu 1bpp v měřítku 1:1. Anebo fotku prostě poslat embednutou v PostScriptu, ať si s ní tiskárna poradí. Tisk bitmap/fotek jsem netestoval.

153
Vývoj / Re:Jazyk pro ML
« kdy: 02. 04. 2023, 15:55:53 »
Strojove uceni ma smysl jen na GPU nebo jinem specializovanem HW. Nema smysl se pokouset o vlastni implementaci ML algoritmu na CPU. 99% usivatelskeho ekosystemu a tutorialu je v Pythonu. Pokud Vam nekdo radi C++ nebo Go "protoze je to rychlejsi", nema poneti, o cem mluvi.

Taktak. Třeba když vlezu na TensorFlow.org a zajímá mě reference API, dostanu se by default na variantu pro Python. Dokumentace pro C++ je hned vedle, v sousedním tabu, ale prostě první na ráně je Python. O tutorialech nemluvě.

Že ty knihovny co dělají rozhraní proti CUDA back-endu jsou kdesi vespod napsané nejspíš v C, to nehraje velkou roli.

A pokud by šlo o to, bavit se přes nějaké API třeba s natrénovaným GPT modelem, který provozuje nějaký dodavatel v cloudu, to je taky "někde jinde".

Snad mám jen trochu strach, zda doporučit ML jako směr studia člověku, který možná trochu začal programovat v nějakém procedurálním jazyku. Jednak z hlediska programátorských schopností, jednak třeba co do dostupnosti vhodných "námětů lákajících ke zpracování"...

154
Vývoj / Re:Jazyk pro ML
« kdy: 02. 04. 2023, 14:00:36 »
Jsem asi už starej na to, abych Python ocenil. Z těch nemnoha setkání si pamatuju v jeho historii jakési kotrmelce "doprovodné infrastruktury" (package management), na které se mi trochu těžko zapomíná. Když vidím nějaký zajímavý open-source nástroj, který je distribuován ve formě pythonových zdrojáků, mám chuť zde udeřit hlavou. Je to takový můj subjektivní podmíněný reflex, na základě předchozích zkušeností (bloatware, verzování, dependency hell, bugy v obskurních externích závislostech). Ale on si v dnešní době člověk moc nevybere. Dependency hell a jeho přenechávání uživatelům je spíš otázka vkusu autorů aplikace, než volby programovacího prostředí.
Ze vrozených charakterových vad bych zmínil "vymezení bloku v kódu hloubkou odsazení". Mám radši závorkovaté jazyky, kde si mohu odsazovat relativně podle svého, pokud mi "coding style" projektu dovolí.
Python je jazyk o něco vyšší úrovně než C/C++. Pro nativní systémové knihovny a syscally potřebuje mít kompletní "bindings". A pravda je, že jich má asi požehnaně.

Python se dneska běžně učí ve školách jako "jednoduchý" jazyk pro začátečníky - tam, kde se dřív učil Pascal.
Jsou lidi, kteří se ze zásady odmítají zajímat o to, jak věci fungují "pod kapotou" - těm musí Python vyhovovat lépe než C/C++.

C++ je potomkem starého dobrého C, což je takový "platformově nezávislý assembler". Pokud nechcete, v C++ už se nemusíte starat o detaily pointerů a alokací - moderní revize C++ se všemožně snaží, od těchto starých zvyků se navenek oprostit, programátora těchto starostí ušetřit. Osobně považuji za přínosné, že je přesto C++ k těmto "kořenům" dodnes relativně pevně přirostlé. Máte k dispzici plnou paletu nativních datových typů holého Céčka, operačního systému a v zásadě i hardwaru.

V jazyce C jsou napsané dnešní operační systémy. Takže různé novoty a okrajové vlastnosti kernelu, systémové standardní knihovny a dalších "nativních" knihoven můžete používat přímo, stačí includnout hlavičkový soubor. (Ve vyšších jazycích musíte čekat, až někdo napíše binding/wrapper/importní modul, nebo si ho napsat sám.)
C++ má oproti C spoustu výhod, snaží se odpoutat od nectností starého dobrého C, taky díky tomu lze narazit na "třecí plochy" v rovině kompatibility ABI mezi různými verzemi či značkami kompilátorů C++. Některé pekelné "vlastnosti" C++ (třeba přehlednost chybových hlášek kompilátoru ve složitých šablonách apod.) se postupem času zlepšují - blahodárným se ukázal vliv konkurence (po příchodu CLANGu zavál svěží vítr i ve vodách GCC/G++).

S čím Vám neporadím je "praktická použitelnost ekosystému" C++ vs. Python pro Machine Learning. Jestli třeba C++ představuje nějakou námahu navíc ve chvíli, kdy člověk potřebuje "odněkud rychle začít".

C++ není třeba studovat hned od začátku encyklopedicky. Pokročilejším vlastnostem budete přicházet na chuť postupně, jak budete potkávat složitější problémy. Budete narážet na přízraky minulosti - třeba doutnající válka "printf() vs. cout" není dodnes rozhodnuta. Pokud v C/C++ nějak začnete, nikdy se Vám to neztratí.

Dobře se bavte :-)

155
Hardware / Re:Tiskové jazyku u tiskárny
« kdy: 02. 04. 2023, 13:29:07 »
Hlavně hrozí to, až vyjde nová verze operačního systému pro který výrobce nenapíše GDI ovladač, tak máte smůlu.
U PS a PCL je v tomto případě naděje vyšší.

+1, velmi přesně a úsporně formulováno.

GDI vždycky znamenalo "užijte si tiskárnu, dokud nepřijde nová verze Windows, která Vám ji pošle do popelnice".
Přesněji řečeno: v Linuxu by životnost "ovladačů" (tiskových back-endů) mohla být o něco delší. Třeba projekt Gutenprint udržuje tiskové backendy pro všelijaké staré hrůzy.

Pod Windows "HP Universal Printing Drivers" produkují PCL nebo PostScript, který by měl chodit na širokém spektru tiskáren. Nicméně mám pocit, že jsem před pár lety zkoušel PS z aktuálního "HP universal printing" poslat na starou HPLJ6-P a nepochodil jsem. Podobně tuším s PCL5, těsně než HP přestali generický driver PCL5 publikovat. Jak funguje datový formát produkovaný "HP Universal Printing" drivery proti tiskárnám jiných výrobců, o tom nemám přehled.

Kdysi dávno, ještě před "HP Universal Printing", býval k dispozici "Adobe Generic Postscript Driver" - který produkoval PS, kompatibilní s tehdejšími tiskárnami. Tento byl ale dávno stažen z webu a dost možná už by v dnešních windows ani nefungoval.

Až do Windows XP jsou všechny tiskárny "GDI". Výrobce tiskárny musí dodat ovladač DDI, který dostává textové a vektorové příkazy z aplikace přes GDI. Některé ovladače z těch příkazů dělají PCL. V PCL3 se také grafika přenáší v bitmapě, teprve novější verze ji přenáší vektorově.

Ano GDI/DDI je/bylo programové tiskové rozhraní pro Win32 aplikace, než přišlo XPS. Pro mě osobně je zajímavé, že Windows Printing Spooler lokálně data spooloval i v dobách GDI/DDI ve formátu EMF = vektorový formát, "Metafile". Pokud správně chápu, s příchodem XPS se takto jmenuje jak rozhraní, tak interní spoolovací formát... dokonce je od té doby ve Windows by default nainstalována "virtuální XPS tiskárna" - což jsem chápal tak, že by Microsoft rád prosadil XPS jako formát souboru "přenositelného jazyka tiskových stran", jak odedávna funguje PS/PDF... což se moc nedaří.

Pod pojmem "GDI tiskárna" si obecně představuji černou skříňku, do které NEmohu přes standardní rozhraní LPT nebo USB-LPT nebo "něco nad TCP/IP" prostě nakopírovat soubor v nativním formátu jejího jobu, aby z tiskárny vyjel papír. Pro GDI tiskárnu potřebuju živý HW-specifický ovladač, který si s tiskárnou bude něco důvěrně švitořit, aby z ní vůbec kdy něco vylezlo.

"Ne-GDI" tiskárně lze doručit job v jejím datovém formátu libovolným způsobem (LPT / USB-LPT / síť (LPR, JetDirect, IPP)) a z ní prostě bez dalšího vypadne výtisk.

BTW. Existují i další jazyky, jako CPCL, TPCL, EPL a dokonce HPGL, který si dříve používal v plotterech a dnes se používá v "plotterech". Plotter v uvozovkách je obchodní označení velkoformátových laserových nebo inkoustových tiskáren od HP, které sice podporují HPGL, ale jinak nemají s plotterem nic společného.

:-) Jojo. Klasický plotter nebo-li souřadnicový zapisovač jezdil po papíře perem. Vektorové zařízení. K mému lehkému údivu spíše menšina plotterů měla plochou podložku, pevně uchycený papír a 2D portál - většina konstrukcí měla válec, pero na jediném lineárním pojezdu, a válely papírem tam a zpátky... nevím jak moc to bylo přesné, při složitějším výkresu. Tu dobu jsem možná zažil, ale tehdejší plotter jsem v chodu nikdy neviděl. Souhlasím, že dnešní "plotter" je vlastně velkoformátový inkoust nebo tak něco. Výkres si renderuje do bitmapy a tu plive na papír řádek po řádku. Takže papír sice jede po válci, ale výkres vypadne na jeden průchod.

HPGL je tedy vektorový formát, ideový příbuzný třeba formátu Gerber. HPGL je údajně podporován i běžnými kancelářskými tiskárnami HP (možná jsem to kdysi dávno i zkusil.)

...
 
Ohledně formátů tiskových jobů:

V dnešní době jako další generický formát funguje "PCLm" (vlastně tenký PDF obal okolo celostránkové bitmapy) - toto je podstatou "Apple Driverless Printing", vyskytuje se to na síťových tiskárnách které podporují IPP / AirPrint / Bonjour (což je dnes velká část tiskáren s Ethernetem nebo i WiFi).

A ostatně i PCL5/6/PS jsou často používány jenom jako "kontejner na celostránkovou bitmapu". Protože vektorových fontů je dnes široká paleta, a než cpát s každým jobem do tiskárny TrueType font (nebo ho převádě na PS font) apod., dává možná lepší jistotu výsledku před-renderovaná bitmapa. S kompresí nemusí být ani moc veliká. V konfiguraci tiskového ovladače může být k nalezení volba, zda má písmo embedovat nebo rovnou renderovat.

Pamatuju si, že kdysi dávno (kolem přelomu století) byl rozdíl, jestli člověk "vytiskl" fotku skrz PCL5 nebo PS. Pokud se tiskárna z PS rovnou nepoblinkala, tak byla šance na jemnější polotóny. Možná to bylo tím, že v případě PCL5 provedl konverzi rozlišení bitmapy ovladač na počítači (nějakým jednoduchým algoritmem) kdežto v případě PS byla bitmapa embednuta v původním rozlišení, a následně ji renderoval PS interpreter ve firmwaru tiskárny, který mohl sáhnout k nějakým nečistým kouzlům typu Resolution Enhancement Technology apod. Taky joby v PS mívaly větší objem, než joby v PCL (a trvalo déle je vytisknout).

Dlouho jsem nezkoušel, poslat do modernější tiskárny HP PCL3 (na úrovni třeba HP LJ III). Možná by to dodnes klaplo :-)

Třeba na Epsonech býval (díky popularitě této značky) velice známý formát Esc*P2. Ale on pomalu každý výrobce tiskáren měl nějaký svůj formát, většinou podrobně zdokumentovaný. Star, Zebra/Eltron/Comtec, Datamax...

Kromě "echt GDI tiskáren", typicky na USB, kde si bez živého proprietárního ovladače skutečně neškrtnete, existují levné tiskárny "z jednoho pytle s echt GDI", které sice vezmou job na jednosměrném LPT / USB-LPT, ale jejich formát jobu je "svůj". Byla taková doba... soudě podle seznamů u projektu Gutenprint apod., bývá ten formát nějakým společným jmenovatelem výrobce a rodiny tiskáren. Matně si vybavuji, že takový "svůj" formát nějaké řady moderních "GDI" tiskáren byl ve skutečnosti PCL3... ale neměl jsem nikdy čas to nějak moc zkoumat.

156
Proč je tam 2x "routing decision" blok: původní KTPD, ze kterého vychází Váš diagram, je v tomto bodě zřejmě mírně nepřesný. Našel jsem přesnější obrázek. Jak už zde psali druzí, ono se toho pod kapotou zřejmě děje ještě o něco víc, ale odpověď na Vaši otázku by tímto měla být jasná.

157
Sítě / Re:CONNMARK --restore musí být už v PREROUTING !
« kdy: 29. 03. 2023, 14:39:56 »
Přišel jsem na to.  pravidlo CONNMARK restore musí být taky v PREROUTING a nestačí v forward. Máte vysvětlení?

Odpověď se IMO přímo skrývá ve Vašem dotazu.

Na značku máte zavěšenu routovací tabulku, podle které se následně provede první "routing decision", poté jde paket do chainu FORWARD. Ve chvíli, kdy vstupuje do chainu FORWARD, už má rozhodnutý=definovaný outbound interface, proto např. lze v chainu FORWARD filtrovat podle iptables -o $OUT_IF .

Přesně proto je třeba, prokopírování značky z "conntrack entry" (mangling) provést už ve fázi PREROUTING - aby se podle značky dal paket vzápětí zařadit do konkrétní instance "routing table"... a "odroutovat" = rozhodnout výstupní rozhraní.

158
Problém mě zaujal, ale odpusťte starému člověku, jsem už pomalejší... nějak si z Vašeho popisu nedokážu poskládat topologii. A ono nakonec asi není ani vhodné, abychom znali konkrétně Vaše adresy = dalo by Vám práci, namalovat obrázek, a zároveň substituovat za veřejné adresy, aby Vám nikdo neťukal na vrátka, minimálně dokud si tu konfiguraci nedoladíte...

Takže víceméně namátkou pár řečnických doplňujících dotazů (a poznámek):

- ke směrování provozu se používají routovací pravidla. V linuxu příkaz "route". Nebo též "ip route". Specifikujete "destination subnet", a přiřadíte mu "next hop", kam se má posílat.

- "holý tun" mi přijde jako lehký nesmysl. Jedna ruka netleská. Netdevice typu "tun" je obvykle zakončením nějakého tunelu. Říkáte, že wireguard ne... tak co tedy? "device tun" si obvykle namapuje nějaká serviska, která dělá tunel, nebo virtualizaci nebo tak něco. Tzn. třeba u VPN ta serviska řeší enkapsulaci/dekapsulaci paketů do nějaké tunelové relace. Máte snad napsáno něco zcela svého, co ten "tun" nahodí, a nějak to handluje s jeho provozem?
Netdevice typu "tun" enkapsuluje 3.vrstvu. Tzn. minimálně point-to-point spoj. Potřebujete, aby na tom "tun" zařízení vyvstal nějaký subnet, minimálně /30 (možná by šel zařídit i /32 tzn. lokální konec "unnumbered".). Pak se můžete v příkazu "route" odkázat na vzdálený konec (jakožto next hop), aby kernel do toho "tun device" začal házet nějaké pakety tím směrem.

- třeba OpenVPN na "server" straně by default přiřadí tunelu subnet a automaticky ho přihodí do routovací tabulky lokálního kernelu. Vzdálené straně umí kromě přidělení IP Adresy na její konec tunelu navrch "pushnout" jeden či více dodatečných routů. Tzn. instance OpenVPN na klientské straně je nasype do kernelové směrovací tabulky na svém konci.

- connection marking má smysl používat až v situaci, na kterou standardní routing nestačí. Třeba když máte tentýž destination subnet viditelný více směry, a u příchozích spojení chcete, aby se opačný směr (traffic náležející téže relaci) posílal "zpátky tou cestou, odkud relace přišla". Osobně jsem to použil v situaci, kdy jsem měl dvě konektivity od dvou různých providerů... to ale není Váš případ...?

- taky se dá zařídit, v rámci prostého routingu, třeba když máte nějakého cestujícího VPN klienta, aby po navázání tunelu se default route přehodil dovnitř do tunelu - a na místní default gateway na LAN zůstane ukazovat jenom specifický route na veřejnou IP adresu vzdáleného VPN access koncentrátoru v divokém internetu. Přístup do internetu pak vzdálenému VPN klientovi řeší "centrála". Toto je třeba konfigurovatelná fičura OpenVPN = netřeba s těmi routy šachovat ručně, OpenVPN to zařídí.

- NAT může zůstat mezi LAN a WAN. Stačí obecná maškaráda. Na tomtéž routeru může být jeden konec tunelu, do kterého se dovnitř neNATuje.

Kladete poměrně pokročilé dotazy na IPtables. Je možné, že jenom nedohlédnu výšin Vašeho geniálního záměru. Upřesnění a dotazy vítány :-)

159
Hardware / Re:Hledám síťovou laserovou tiskárnu se skenerem
« kdy: 27. 03. 2023, 09:21:07 »
Třeba MF657Cdw   na Alze vidím 9990,-

DADF, hmm...
Ono to umí tisknout i na čtvrtku :-O  (200g/m2)

A startovací náplň na pár set stran. Sada originálních náplní na 2300 stran stojí asi desítku. Což je, pokud si pamatuju, podobná píseň jako u konkurence. Inu pane pořídil jste si opici, musíte mít na banány. A protože u většiny barevných laserů se točí i barevné fotoválce neustále, mají jakousi minimální reziduální spotřebu barevných tonerů i při ČB tisku. Prostě... za sebe jsem si to vyhodnotil tak, že doma barevně tisknout nepotřebuju.

160
Hardware / Re:Hledám síťovou laserovou tiskárnu se skenerem
« kdy: 26. 03. 2023, 21:46:41 »
Další tip nemám a reaguji OT. Ta vysvětlivka ohledně Xeroxu mi připomněla relativně dávnou zkušenost s ojetou voskovkou Tektronix Phaser, která nám zbyla ve firmě, poté co ji odložil kdosi mocný - ta věc měla tuším zapékací válec s povrchem ze silikonového kaučuku, který nebyl příliš mechanicky odolný. Když jsem bádal, kolik by stála výměna toho válce a asi dvou dalších vysloužilých věcí, zjistil jsem, že levněji vyjde kompletní nová tiskárna :-) BTW tahle divize Tektronixu byla převzata Xeroxem a tuším jejich vosková technologie / rodokmen při té fúzi zanikl.

161
Tohle už dnešní mládež ve škole asi nezažije...
Takže jste asi jenom koukal na blbou školu, podobně jako pan Poljak.
No jasně :-) Ale vyprovokoval jsem věcnou reakci od místního mazáka - což byl asi hlavní účel toho rejpance. Díky za uvedení na pravou míru.

Osobně k echtovní kryptanalýze necítím příchylnost, ale otevřít si tu a tam nějaký binár v IDA PRO, když v něm tuším zajímavou informaci (binární driver k jednoduchému proprietárnímu hardwaru na způsob GPIO) nebo pozoruji zvenčí chybu, toho jsem se historicky soukromě dopustil. Spíš bez valného úspěchu, ale je to činnost poměrně zábavná.
Pokud si představím, že mě někdo z něčeho takového chce zkoušet, jímá mě jisté zděšení.

162
Bazar / Re:Koupím Flex ATX zdroj
« kdy: 26. 03. 2023, 19:00:37 »
( me osobni preference vyhrava zatim Corsair )

Já bych se nebál Fortronu - cokoli co začíná FSP. Jeden takový FlexATX je aktuálně vidět v Googlu mezi reklamami v CZC.

Jinak obecně ze značek mám radši "průmyslové" věci - vedle Fortronu ještě třeba Delta nebo Zippy/Emacs. Ceny jistě hrozné, pokud seženete. Z kancelářských věcí mi docela sympatický přišel Chieftec (německá Čína). Ale FlexATX je dost exot. Kromě toho Fortronu se hledá těžko.

163
BTW jednou jsem kdesi slyšel/četl vyprávět nějakého Rusa, který popisoval, jak se na vejšce učili x86 assembler (a instrukční sadu) a v disassembleru hledat v bináru příležitosti pro buffer overflow, případně jak dolepit svoje úpravy apod. Tohle už dnešní mládež ve škole asi nezažije... a nechci tvrdit, že já jsem to ve škole zažil.

Nechci se pouštět do úvah, jak až moc povrchně se dá proplout IT vejška se zaměřením na bezpečnost (cestou excelového bojovníka v kravatě)... osobně bych si nejspíš lebedil v předmětech, kde se člověk po lokte umaže od vnitřností :-) pokud to bude z mého zájmu, pokud mě tím nebudou lektoři v nějakém smyslu naschvál samoúčelně šikanovat.

164
Dobrý den,

trochu listuju studijními programy VŠB (což říkáte, že jste udělal taky).

Na první pohled mi bakalářská "Informatika" na VŠB přijde velmi příjemně poskládaná. Dát funkcionální programování hezky zostra rovnou na start paralelně s úvodem do procedurálního C/C++ je možná trochu odvážné, ale nakonec asi proč ne, je to vejška. Kdo nechce, ať tam neleze :-) Vidím tam na první pohled přiměřenou porci matiky. Pokud zvládnete základní kurz C/C++ a základy vektorových počtů ve 2D/3D (to je látka spíš ze střední školy) tak základní kurz grafiky ve třeťáku byste odhadem měl zvládnout taky - zavolat si openGL, nasypat do něj nějaký jednoduchý model (pár faces, nebo s jakými primitivy se tam bude pracovat), přišpendlit textury, rozmístit světla a zavelet "kresli". Takhle zvenčí bych řekl, že po Vás nikdo nebude chtít, abyste *implementoval rendering engine* nebo tak něco.

Na magisterském studiu obor "Informační a komunikační bezpečnost" mi připadá poměrně sympatický přesto, že osobně zrovna k bezpečnostnímu cirkusu kdovíjak intimně nelnu. Dá se to poskládat i jako poměrně obecné "ajeťácké" studium. Třeba volitelný předmět "programování v operačních systémech" mi připadá tak nějak "konzervativně k jádru pudla" - osvěžující "jak to funguje pod kapotou", v dnešní záplavě všech těch javascriptů a UI designů a jiných rádoby pokrokových webovin. Jenom mám trochu strach, zda to nebude rozsahem "přes čáru" co do objemu domácích úkolů. Ono napsat kus softwaru, ve kterém budou sockety, vlákna, synchronizace mezi vlákny... to je rozsahem spíš na diplomku (nebo i víc) než na kurz co má týdně přednášku a cviko. Ale víte co se říká: nejhorší smrt je z vyděšení. A pakárnu si dělá každej sám - důležité je, vymyslet si zvládnutelné minimalistické zadání na semestrálku.
Pak tam vidím další volitelný kurz ohledně síťovin - bravo!

Vcelku mi přijde, že tahle cestička má šanci, dát Vám solidní všeobecné základy řemesla. Vidím tam o dost míň "pitomostí okolo" a rádobyvědy, oproti mé alma mater VŠE. Dostanete tam na talíčku se lžičkou věci, které jsem si já doštudovával z vlastního zájmu mimo školu a později při zaměstnání. Ve škole Vás většinou posadí do kokpitu a řeknou "tady je volant, támhle máš plyn a brzdu, nádrž máš plnou, hurá na dopravní hřiště". Vlastními silami člověk stráví určitý čas sháněním vozidla, čtením návodu, překonáváním různých banálních začátečnických neznalostí...

Bohužel nemám inside informace, který z předmětů je podaný snesitelně / prakticky / po lopatě, a kterého vyučujícího si případně fakulta pěstuje jako bubáka/síto.

165
Hardware / Re:Jaký jaderný modul pro touchpad
« kdy: 26. 03. 2023, 16:23:03 »
Ten touchpad je technicky I2C HID device, připojený k hostitelskému počítači skrz I2C HCI.
Zkusil bych se nejprve podívat, co je nataženo za ovladače.
Kód: [Vybrat]
lsmod | grep i2c
Hledal bych zmínky o i2c_hci, i2c_hid a i2c_designware .

Našel jsem volně k tématu nějaké vlákno ohledě ArchLinuxu...

Ten řádek ohledně "input device" je odkud? Z dmesg z distribučního jádra, se kterým touchpad funguje?

Stran: 1 ... 9 10 [11] 12 13 ... 84