Poslední příspěvky

1

Sítě / Re:Optika od Cetinu - jen pro O2?

« Poslední příspěvek od Vietnanka kdy Dnes v 22:24:30 »

Dnes před barákem šaškoval nějaký chlap s pásmem, ušel asi 10 m a  a pak 2 šli do auta a něco zapisoval do notýsku a pak odjeli, znamená to, že s optikou je to na spadnutí?  Do schránky mi akorát chodí nabídka od 1 z 3 wifinářů tak jednou ročně.

2

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 22:21:22 »

Ale moc Swing nových aplikací asi nevzniká, ne? Podle mě Swing už spíš legacy framework. Javy FX by bylo škoda. Doufám, že dojde k určité renesanci desktopových aplikací.

Těžko říct, ono nevzniká moc nových desktopových aplikací v Javě obecně. Ale vývojové nástroje od JetBrains jsou Java+Swing, a to je rozhodně pořád živé. Nejspíš se tam nebudou moc přidávat nové vlastnosti (i když JetBrains myslím má nějaká svoje vylepšení), ale zase to není ve stavu, že už by se to jen nechávalo umřít.

3

Vývoj / Re:Metody Dockeru v PROXMOX

« Poslední příspěvek od Vietnanka kdy Dnes v 22:18:56 »

Pokud se focusnu na Proxmox, vychází mi 3 možnosti:
1. vytvoření VM * a v něm instalace dockeru.
2. vytvoření "CT" a v něm instalace dockeru , co je vůbec CT za zkratku. Mělo by jít o ve skutečnosti LXC container. A to naráží na nested virtualization.
3. instalace přímo do Proxmox operačního systému

ptal jsem se na to AI, asi 3 zajímavé body mi stály za zamyšlení:
-bezpečnost, AI odpověděla, že  +že jelikož docker v LXC  (ale logicky i docker v proxmoxu)má stejný kernel jako proxmoxu , nemusí být tento kernel "vyladěn na izolaci a bezpečnost"

Isolation Mechanisms:
While both Docker and LXC use namespaces and cgroups to provide isolation, the level of isolation can differ based on how they are configured. LXC containers are designed to behave more like lightweight VMs, providing a more complete environment, while Docker containers are optimized for running applications and may have different security configurations.

- výkon, přestože docker ve VM bude mírně zpomalený hypervizorem, tak docker v LXC by měl být na to hůř? nejlépe docer přímo v proxmoxu.
- instalovat a provozovat docker pod root uživatelem (Defaultní v proxmoxu) nebo vyhrazeném?
- featury - něco ve smyslu že docker pod LXC může mít omezené featury (jelikož jsem nadhodil téma nested containers, mimochodem asi něco jiného než nested virtualization)

 * BTW: existuje DockerOS ^, podobně jako je Armbian, Proxmox ?
2) ta ai (GPT-4o mini)se zlepšila, nemusel jsem po 5.otázce si připadat že konverzuju s zaslepeným zacykleným robotem a po 25.otázce stále se dozvídám věci k věci (i když to klouzá po povrchu a třeba radí, že sluníčkově radí, že stačí do grubu přidat amd_iommu=on a prásk je to zapnuté a beru to s rezervou) a nestal se nějaký AI renonc


Co vybrat, co je nejlepší z těch 3 způsobů nebo je docker (pod rootem ) v proxmoxu něco jít nahý v podvečer Václavákem (na Slovensku  íst s iphonem  ghettem v Žilině)?

4

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od anonacct kdy Dnes v 22:13:22 »

Objektivně ale když nepoužiješ cargo, tak naopak ztrácíš spoustu informací které k tomu auditu potřebuješ.

Myslím si, že cargo (nebo i třeba npm či nuget) je mezivrstva, která dělá těžší detekovat backdoory nebo jiný prapodivný kód. Problém je, že v crates repozitáři občas bývá jiný kód než v repozitářích se zdrojovými kódy.

Dokonce studie z minulého roku zjistila více než 15 procent z nejpoužívanějších 999 crate mají na crates jiný kód než v repozitářích. Takže mi to přijde jako časovaná bomba.

Osobně si naklonuji repozitář, projdu si jednotlivé commity a pak si vyberu určitý commit, který vložím do svého projektu. Nebo používám přímo API operačního systému či široce používaných knihoven, kterým věřím víc než nějakým frameworkům.

Jenže dobrý package management znamená, že lidi začnou publikovat menší knihovny, které řeší jednu konkrétní věc. Hledat commit, který ty chceš, když máš N závislostí, a ty závislosti můžou mít tranzitivní závislosti je jen obrovská ztráta času.

Package management řeší totiž i ty tranzitivní závislosti, a popřípadě konflikt mezi něma. Pokud používám ekosystém, kde jsou knihovny na jednu věc, a ne frameworky co mají tunu funkcí, tak tento přístup prostě není možný.

Co je horší, v C++ začal být trend "header-only" knihoven, které lidi dropnou do projektu a už nikdy neaktualizujou. Toto je naprosto katastrofické, protože je ani nezajímá jestli tam třeba není nějaká chyba.

Package management právě řeší dobře ty chyby v závislostech. Nebo chceš mi říct, že když aktualizuješ tvoje závislosti, tak děláš review každého commitu co ty závislosti mají? Tomu nevěřím, že by to bylo možné dělat i u menšího projektu.

Už se mi moc nechce o tom diskutovat. Jen bych doplňil ještě pár věcí o C++:

  - ještě jsem nikdy nezažil C++ projekt, kde by přišli vývojáři a začali hned pracovat - místo toho se začnou hádat o coding style, kde použít exceptions, kde používat result/expected typy, atd... C++ má milion konvencí, co lidi tak nějak používají jednou tu a jednou tam, ale dohodnout se je velmi těžké. I nastavit věci jako automatické formátování atd...

  - když jsem začínal v minulosti C++ projekty, tak nastavit build system a CI, aby tam byly různé sanitizery, testy, podpora pro různé platformy, gtest, SIMD, atd... To je práce na týden a vždycky to dopadlo tak, že jsem vzal jiný projekt a udělal copy/paste základního CMakeLists.txt a CI pipeline, a jen upravil pro potřeby nového projektu. Prostě nastavit C++ projekt je neuvěřitelný opruz a CMake ačkoliv používaný v C++ ekosystému, je ten největší hnus co jsem kdy musel používat.

5

Sítě / Re:MikroTik a doména pro Google API

« Poslední příspěvek od Vietnanka kdy Dnes v 22:10:37 »

mě se těžko radí, zdá se mi ten dotaz takový od prostředka, něco jako články od  Clocka. Proč zmiňuješ mikrotik a jakou hraje roli , co chceš docílit, co je konkrétně "Tento počítač" localhost a na co chceš google api a jaké google api? Odkud je screenshot?
pochopil jsem jen z toho že na raspberry ti běží node red.

6

Software / Re:Sdílená grafika s video výstupy pod VM

« Poslední příspěvek od Vietnanka kdy Dnes v 22:06:34 »

Taky se o to zajímám (jsem na bodu 0.0).  A vlastně mi to přijde komické, když Virtualbox a spol. to umí obraz jednotlivých VM  přímo jako okýnka na ploše hosta. a že proxmox umí zprostředkovat obraz guestů přes web ui přes ten jejichi vnc nebo spice(prý je tam nějaký QXL KVM spice video driver)

poznámka nepotřebuju nutně host grafiku v VMkách tedy ne passthrough, stačí akcelerovaná (paravirtulizovaná) nebo i emulovaná vždyť virtualbox geust po instalaci taky má microsoft basic video driver

jsem teď chytrý po chatu s AI (štěstí, že to neutne po 15 otázkách) , a vím, že mezi proxmoxem a vmware player je podstatný rozdíl, kdy proxmox je něco jako arch linux , kde není defaultně nic.

2. "Scraped from" Guest Virtual Screen (Transparent for Guest)
This method involves using the host to capture the display output of the guest OS without requiring any configuration on the guest itself. This can be achieved using tools that allow the host to access the guest's display.

Steps:
Use Proxmox's Built-in Features:
Proxmox provides a web-based console that allows you to access the VM's display directly from the Proxmox web interface. This is not RDP or VNC but serves a similar purpose for management.
Install a VNC Server on the Host:
You can set up a VNC server on the Proxmox host that captures the display output of the guest VM. This would require configuring the host to access the VM's framebuffer or display output.
Use a Virtual Display Driver:
In the guest OS, you can configure it to use a virtual display driver that allows the host to capture the display output. This may involve using a specific configuration in the VM settings.
Conclusion
Both methods are viable for accessing the virtual screens of guest operating systems. The first method, originating from the guest OS, is straightforward and allows for direct access. The second method, where the host captures the guest's display output, can be more complex but provides a transparent experience for the guest. Depending on your requirements and preferences, you can choose the method that best suits your needs.

byl o chat s GPT-4o AI kolem proxmox /docker způsobů (docker<LXC , docker<(K)VM, docker přímo v proxmox) a došlo i na otázky kolem potřeby dostat obraz z guestů  někam, a konkrétně na fyzický hdmi port počítače (bez USB krámů)a tohle byla otázka konkrétně "jestli tedy existují 2 metody jak získat obraz, 1. bylo záchyt (úkol) RDP/VNC v guestovi a 2. záchyt obrazu v proxmoxu(tedy transparentní pro guesta)"

7

Sítě / Re:MikroTik a doména pro Google API

« Poslední příspěvek od Exceptions kdy Dnes v 21:57:47 »

redirect_uri_mismatch nejspíš znamená, že tam máš typo, je to háklivé i na třeba koncové lomítko nebo jiný rozdíl. Projdi si to ještě znovu. Sem jsi moc informací nenapsal, takže ti těžko poradit přesněji. Tohle obecně funguje.

8

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Radek Miček kdy Dnes v 21:53:25 »

Objektivně ale když nepoužiješ cargo, tak naopak ztrácíš spoustu informací které k tomu auditu potřebuješ.

Myslím si, že cargo (nebo i třeba npm či nuget) je mezivrstva, která dělá těžší detekovat backdoory nebo jiný prapodivný kód. Problém je, že v crates repozitáři občas bývá jiný kód než v repozitářích se zdrojovými kódy.

Dokonce studie z minulého roku zjistila více než 15 procent z nejpoužívanějších 999 crate mají na crates jiný kód než v repozitářích. Takže mi to přijde jako časovaná bomba.

Osobně si naklonuji repozitář, projdu si jednotlivé commity a pak si vyberu určitý commit, který vložím do svého projektu. Nebo používám přímo API operačního systému či široce používaných knihoven, kterým věřím víc než nějakým frameworkům.

9

Sítě / Re:Optika od Cetinu - jen pro O2?

« Poslední příspěvek od Radek Zajíc kdy Dnes v 21:51:45 »

Ono je jedno, kdo koho koupil, protoze jak Nej tak Nordic PPFka rozporcovala tak, ze infrastrukturu ziskal CETIN a zakazniky O2. Infrastrukturu by jednoho dne mel nabidnout vsem velkoobchodnim partnerum, ale zatim se to nedeje.

10

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Ondrej Nemecek kdy Dnes v 21:26:47 »

Současný UI toolkit pro javu je JavaFX.

Ono je to složitější. JavaFX je modernější než Swing a původně ho měl nahradit. Pak ale Oracle JavaFX opustil (protože si Oracle obecně s desktopovou Javou neví rady, resp. s desktopovými aplikacemi vůbec…) a nyní JavaFX stojí na nepříliš velké komunitě. Takže jeho budoucnost není moc jistá. Naproti tomu Swing je stále součástí Javy a komunita kolem něj (včetně velkých a obřích firem) je tak velká, že o jeho budoucnost není potřeba se bát.

Pro nějaký hobby projekt je JavaFX dobrá volba, pokud by ale měla vzniknout nová desktopová aplikace psaná v Javě, u které by se očekávalo dlouhodobé použití, volil bych Swing.

Typicky dnes ovládá vývojář několik jazyků a celou škálu technologií.

No, typicky dnes vývojář píše v několika jazycích. Do jaké míry je doopravdy ovládá už je různé.

Ale moc Swing nových aplikací asi nevzniká, ne? Podle mě Swing už spíš legacy framework. Javy FX by bylo škoda. Doufám, že dojde k určité renesanci desktopových aplikací.