reklama

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 - LarryLin

Stran: [1] 2 3 ... 15
1
Odkladiště / Re:Sken všech veřejných domén
« kdy: 13. 02. 2020, 17:58:34 »
vystupoval v pořadu "Den D"
To si matně pamatuju, dokonce jsem si během této diskuze na to vzpomněl, ale nevěděl jsem, že výsledkem je zrovna tento web. Jestli se nemýlím, tak tu investici nezískal a utkvělo mi v hlavě jak ten žadatel o investici říkal: "...no a když to nevyjde, tak přijdeme o peníze." a myslím, že Tomio mu do toho skočil a řekl "Né vy, to my přijdeme o peníze".  :)

2
Distribuce / Re:Hledá se skutečně profesionální distribuce
« kdy: 05. 02. 2020, 20:31:01 »
V openSUSE s Plasma touchpad nefungoval, v openSUSE s GNOME vše fungovalo. A to je openSUSE asi jediné velké distro, co bere KDE jako "first class citizen", jak to musí vypadat jinde si ani nechci představovat.
Nechci se zastávat KDE, taky jsem tam našel jednu drobnou chybu v efektu při křekrývání oken, ale to co popisuješ klidně mohl být problém openSUSE - špatně to ubalili. Podobný problém řešili i na Manjaru v unstable verzi a jestli jsem to správně pochopil, tak to byla právě chyba baličů, kteří vytvořili balík plamsa-framework-5.46.0-2.1 ale ostatní zbytek frameworku očekával verzi 5.47.0. Někdy je problém zjistit kdo tu chybu udělal, ale hodit to na KDE jen proto, že v Gnome to fungovalo by nebylo spravedlivé.

3
Distribuce / Re:Hledá se skutečně profesionální distribuce
« kdy: 05. 02. 2020, 19:10:30 »
Asi před půl rokem jsem si říkal, že zkusím Plasma 5, abych viděl, kam to pokročilo, tak jsem to nainstaloval na notebook a nefungoval touchpad, tedy pohyb kurzoru jo, ale ne klikání.
Jsi si jistý, že to byl problém v KDE? Tady https://bugs.launchpad.net/ubuntu/+source/sddm/+bug/1800295 je popsaný bug s klikáním v KDE, ale dole je odkaz kde je daný problém popisovaný u Xubuntu a další člověk v diskuzi danou chybu popisuje na Ubuntu.

Myslím, že společným problémem linuxového desktopu je špatné otestování. Kdysi jsem narazil v Manjaru na balíček, který nešel nainstalovat, ani nemohl jít, protože tam byla triviální chyba. Chybu opravili rychle, ale už to, že se balík dostal do stable hovoří o né moc poctivém testování a nemyslím, že na jiných distrech je to jinak. V tomhle vyhrává distro, které má nejvíce unstable uživatelů. KDE má nevýhodu, že je už dost překombinované a rozhodně složitější na otestování než jednodušší DE.

4
Distribuce / Re:Hledá se skutečně profesionální distribuce
« kdy: 05. 02. 2020, 16:39:56 »
Fedora má za sebou Red Hat, má za sebou Debian taky nějakého komerčního hráče? (Nic jsem nenašel).
Taky jsem tímto stylem přemýšlel o Fedoře. Ja jsem chtěl přejít na Fedoru právě proto, že má za sebou Red Hat a protože na rozdíl od Debianu se výrazně podílí na rozvoji sw na linuxu. Moc se mi nelíbí anitikapitalistické výkřiky, že linux, který vyvíjí nějaká firma je špatný. Pokud by neexistoval Libvirt nebo VFIO, tak by pro mne přechod z Win na Linux byl složitější. Za oběma projekty stojí právě Red Hat. Samozřejmě těch projektů co dělá Red Hat je mnohem více.

Bohužel jsem u Fedory zažil zklamání. Měl jsem ji na zkoušku v dualbootu. Když jsem si ji po několika měsících znovu spustil, tak byla rozbitá. Přitom když jsem ji opouštěl byla OK. Zřejmě se zaktualizovaly GNOME Shell Extensions, které nebyly kompatibilní se starou verzí Fedory. Taky jsem měl problém při instalaci přes Gnome Software. Myslím, že jsem instaloval Redshift. Dal jsem instalovat a nic se nestalo. Pak se mi to povedlo přes nějakého jiného správce balíčků. No a to byla další věc co mi vadila, že není jeden hlavní správce balíčků. V Gnome Software totiž bylo jenom něco (aplikace) a balíčky jsem musel hledat zase jinde - v PackageKit. Jenže PackageKit byl hrozně jednoduchý - mám dojem, že mi tam scházely vypsané závislosti jednotlivých balíčků. Na netu jsem našel chválený yumex, jenže jsem zjistil, že Fedora přestala používat yum a přešla na dnf :( Skončil jsem u dnfdragory. Když jsem zase za nějaký čas zapl Fedoru, že jí dám ještě šanci, tak jsem ji chtěl zaktualizovat, jenže moje verze byla -3 verze oproti aktuální verzi a nešlo ji jednoduše zaktualizovat. Vše se stáhlo, ale po restartu nedošlo k aktualizaci, jestli si dobře pamatuji, problém byl v GPG keys. Celkem jsem se s tím natrápil.

Fedoru jsem úplně nepohřbil, ale moc mě zatím nepřesvědčila. Mám dojem, že Red Hat má hodně stabilní RHEL a pak hodně testovací Fedoru. To co je mezi tím vyplňuje Debian a další distra.

Chtěl jsem vyzkoušet openSuse, na ten jejich YaST jsem zatím slyšel jen chválu, ale po přečtení recenze se mi do toho moc nechce - nevypadá to stabilněji než Fedora.

Mám Manjaro s Xfce, žádný zásadní problém jsem neměl, ale občas se nějaká chyba objeví takže taky se dívám po novém stabilnějším distru a vypadá to, že asi skončím u Debianu s Xfce nebo na Xubuntu.

Prohrabal jsem se různými distribucemi a z nějakého důvodu postupně dospěl k Manjaro s KDE. Proč zrovna Arch linux, sám nevím.
Já vím. Protože Archlinux má nejlepší dokumentaci ve vesmíru ;) a ze všech dister co jsem zkusil má nejlepší GUI package manager - rychlý, přehledný, jednoduchý a zároveň se všemi potřebnými informacemi o balíčcích.
Jako začátečníkovi ti mohu Manjaro s Xfce doporučit. Díky Archwiki, která je jednoduchá a přehledná, rychle vyřešíš konkrétní problém a zároveň nahlídneš pod pokličku linuxu. V dokumentaci Debianu budeš hledat řešení déle - nemají ji graficky formátovanou. Přejít pak z Manjara na jiné distro není problém. Když si v Xfce uděláš pár změn, např. použiješ ikonky Faenza, přidáš nějaký vysunovací dock, tak to bude i krásné. KDE Plasma má asi hezčí efekty, ale nikdy mě nezlákalo, abych přešel. Naopak čím jsem starší tím víc se mi začíná líbit jednoduché čísté prostředí bez efektů a zbytečností. Zkusil jsem si ve VM i MacOS (s plnou 3D akcelerací) a taky mě to nenadchlo.

Snad ti můj názor bude nějak užitečný.

5
Distribuce / Re:Hledá se skutečně profesionální distribuce
« kdy: 05. 02. 2020, 11:21:03 »
pokial na tom maju ist veci z windows xp / dos (DOSbox) tak urcite MX linux (32bit/64bit podla cpu) a wine + dosbox.
Wine a dosbox funguje i na ostatních distribucích.

6
Distribuce / Re:Hledá se skutečně profesionální distribuce
« kdy: 04. 02. 2020, 15:19:26 »
Treba chyceni okna...
osobne v Xubuntu i s Xfce 4.14 na to narazim a obcas radeji pouziji zkratku "ALT+PravaMysKdekolivNadOknem+PosunMysi" na zmenu velikosti okna, protoze pouziva tema oken ktere "nema"(1px?) ramecky a vychozi WM v Xfce xfwm4 kterej bere okraje pro chyceni podle tematu_oken, resenim by bylo pouzit jine WM nebo jine TemaOken (pripadne stavajici upravit aby melo ramecky sirsi)
Taky mě štval úzký rámeček a bylo to to první co jsem si na linuxu přizpůsoboval. Je to celkem triviální změna, stačí jít do adresáře /usr/share/themes/<použité téma>/xfwm4/ otevřít patřičný soubor *.xpm v Gimpu a obrázek roztáhnout (podle potřeby i přebarvit) a uložit. Pro aplikování změny stačí překliknout téma na jiné a pak zpátky na to upravené. Byl jsem tenkrát úplně nadšený když jsem zjistil, že takovou jednoduchou změnou si mohu vytvořit zcela originální vzhled oken :)

PS: myslím, že v mém případě šlo i o to, že když jsem měl okna přes sebe, tak se mi špatně orientovalo kde jedno okno končí a druhé začíná. Uplně výborné to má Win7 kde je rámeček nejen široký, ale i odstínovaný, bohužel u Win10 od toho vývojáři upustili (alespoň teda ve výchozím nastavení, možná to jde někde v nastavení změnit).

PS2: možná lepší než upravovat originální *.xpm je celé použité téma zkopírovat do nového adresáře pro případ, aby se po aktualizaci nepřepsaly provedené změny.

7
Windows a jiné systémy / Re:Nelze se připojit na SAMBA disk
« kdy: 30. 01. 2020, 17:10:39 »
Ahoj díky za tip mapování \\name\slozka a \\IPadresa\slozka jsem zkousel na Win10 proste nejede.
Asi přejdu na Wedos disk ...
Wedos disk v žádném případě. Za ty prachy seženeš i dvojnásobnou kapacitu.

8
/dev/null / Re:Hackathon na dálniční známky.
« kdy: 27. 01. 2020, 14:22:02 »
Trochu jsem to včera sledoval https://www.facebook.com/znamkamarada/videos/518326918792325/ a zajímalo mě jaké technologie použili.
Prezentace je sice trochu zmatená, ale vzhledem ke shonu v jakém to vznikalo se to dá pochopit. Jestli jsem to správně pochytil, tak použili:

Eshop udělali 2x ( https://ferznamka.cz/ a https://fairznamka.cz/ ):
1) v ReactJS
2) v Kentico - https://www.kentico.com/
Včera jely oba, dnes se přesměrovává jen na fairznamka.cz

Udělali appky na Android a iOS.

Core system udělali v .Net.

Rozpoznání SPZ: ALPR Cameras + statická kamera od firmy CAMEA.

Integrace na účetní systém Abra.

Hostováno je na MS Azure Cloud.

Reporting: Power BI - https://powerbi.microsoft.com/cs-cz/report-server/

Jestli je tady někdo kdo se toho účastnil nebo zná bližší informace o technických detailech tak by bylo skvělé kdyby se podělil. Mě zarazil ten .NET. Více bych hádal Javu, myslím, že se jim přihlásilo více vývojářů v Javě než v .NETu.

9
Vývoj / Re:Využití a aplikace Machine learningu
« kdy: 22. 01. 2020, 12:36:36 »
V jedné firmě používali ML na odhad kdy bude zákazník objednávat další zboží. ML se učil chování zákazníků při opakovaných objednávkách a pak jim dokázal s předstihem dané zboží nabídnout. Nemusí se jednat jen o chování konkrétního zákazníka, že každé 2 měsíce objednává brusné kotouče, ale o chování nějaké skupiny zákazníků, např. když si někdo koupí základovku se 4 sloty RAM a zakoupí si jen 2 moduly RAM, tam mu ML za 5 let nabídne speciální nabídku dalších 2 modulů (pro upgrade PC).

10
Windows a jiné systémy / Re:Uspání virtuálního PC
« kdy: 10. 01. 2020, 11:44:52 »
no s verzi qemu si me zaskocil :-D

Xubuntu 18.04.3
qemu 2.11+dfsg-1ubuntu7.21
libspice-server1 0.14.0-1ubuntu2.4
libvirt0 4.0.0-1ubuntu8.14
virt-manager z gitu...

Teď jsi zaskočil zase ty mě. Qemu 2.11 je na můj vkus už hodně historická verze. Když jsem si před pár lety nastavoval virtuálky, tak jsem pro ně potřeboval nové funkce co byly v Qemu. Teď už nejnovější funkce nepotřebuji, takže pomrkávám po distru, které by bylo více stabilní a méně aktuální, ale s 2.11 bych kvůli vga-pass měl asi problém.

Spice (server) 0.14.0 jsem v kešce měl, ale právě kvůli Qemu jsem ho nemohl downgradovat. libvirtd (libvirt) mám 5.10.0.

11
Windows a jiné systémy / Re:Uspání virtuálního PC
« kdy: 10. 01. 2020, 11:33:32 »
No on můj dotaz nebyl na ovladače, ale na guest tools(guest-agent) https://wiki.libvirt.org/page/Qemu_guest_agent cituji z popisu
Citace
executing functions which need assistance of the guest OS. For example, freezing and thawing filesystems, entering suspend
Guest agenta nemám. Co vím, tak guest agent by byl potřebný pokud bych se snažil uspat nebo hibernovat OS uvnitř VM. Ten bug na který jsem narazil se ale týká pauznutí celé VM bez ohledu na OS.

PS: co mám své virtuály Windowsu v čistém Qemu (bez libvirtu), tak jsem pro guest agenta nikdy nenašel využití. Když potřebuji Windows uvnitř VM hibernovat nebo spustit nějaký Win program/script a potřebuji to udělat z vnějšku (z hostitele), tak vše dělám přes Qemu monitor - https://en.wikibooks.org/wiki/QEMU/Monitor

12
Windows a jiné systémy / Re:Uspání virtuálního PC
« kdy: 09. 01. 2020, 13:54:35 »
Zkusil jsem spustit virt-managera s parametrem --debug, ale našel jsem jen varování:
Kód: [Vybrat]
(virt-manager:31125): GSpice-WARNING **: 12:01:58.850: Warning no automount-inhibiting implementation availableZkusil jsem v nastavení VM nastavit Obrazovku "VNC server" místo výchozího "Spice server" a kupodivu to pomohlo - s VNC to nevytuhává. Zkusil jsem downgradovat Spice, ale Qemu vyžaduje min. verzi 0.14.2 (moje současná) a starší Qemu v kešce nemám. Downgrade spice-gtk, spice-protokolu, virt-managera nepomohl. Takže nevím který balíček za ten bug může.

Mám:
virt-manager 2.2.1
spice 0.14.2
qemu 4.2.0

Mám pech. Jen jsem chtěl vyzkoušet uspávání ve virt-manageru a zrovna narazím na bug. Asi mně osud naznačuje, že mám přejít na stabilnější distro :)

13
Windows a jiné systémy / Re:Uspání virtuálního PC
« kdy: 09. 01. 2020, 00:53:04 »
Tak nakonec jsem zjistil, že vůbec nezáleží na délce běhu VM. Jde pouze o to jestli je po pauznutí VM zavřeno okno dané VM.

Reprodukce problému:
1) Spustit virt-manager
2) Otevřít VM (stačí dvakrát na ni kliknout)
3) Spustit VM
4) Pauznout VM
5) Zavřít okno
6) Otevřít VM (stačí dvakrát na ni kliknout)
7) Obnovit VM (zrušit pauzu)
8) a VM je zatuhnuta

Pokud bod 5+6 vynechám nebo zavřu okno pouze když VM běží (není pauznutá), tak vše funguje dobře. Testováno na VM Win7, Debian9, Openelec, Alpine Linux. Všude se to chová stejně. Zvláštní. Že by nějaký bug v GUI virt-managera?

14
Windows a jiné systémy / Re:Uspání virtuálního PC
« kdy: 08. 01. 2020, 23:27:50 »
... to zrychlení času má na svědomí zřejmě nastavení:
<timer name="rtc" tickpolicy="catchup"/>
což je v libvirtu výchozí nastavení pro Win guesty.

15
Windows a jiné systémy / Re:Uspání virtuálního PC
« kdy: 08. 01. 2020, 23:03:49 »
Mně to nedalo a taky jsem ještě něco zkusil:

1) Ve virt-manageru jsem spustil VM Windows7
2) Ukončil jsem virt-managera i libvirtd
3) Napojil jsem se na VM napřímo:
Kód: [Vybrat]
sudo nc -U /var/lib/libvirt/qemu/domain-2-windows7/monitor.sock4) Pauznul jsem VM pomocí QMP:
Kód: [Vybrat]
{ "execute": "qmp_capabilities" }
{ "execute": "stop" }
5) nechal jsem cca hodinu odležet
6) Probudil jsem VM:
Kód: [Vybrat]
{ "execute": "cont" }
Takto jsem to udělal 2x a VM nevytuhla ani jednou, přitom když jsem pauzoval ve virt-manageru na desítky minut, tak VM s Win7 vytuhla vždy. Takže si myslím, že to vytuhnutí při pauznutí a obnovení ve virt-manageru je zřejmě bug libvirtu (nějaký problém se zámky stavů).

Ale to není všechno. Po probuzení té VM jsem si všiml, že čas není opožděn, ale naopak je na hodinách víc než ve skutečnosti. Po bližším pohledu jsem si všiml, že jedna minuta trvá jen cca 6 sekund. Když jsem si hodiny rozklikl, abych viděl ty windowsovské ručičkové hodiny, tak jsem se začal smát - vteřinová ručička uháněla jako při cestování časem :). Až po několika minutách se to vrátilo do normální rychlosti. Kdybych hledal řešení s problémy s časem, tak bych asi zkusil odstranit "no-hpet" nebo přidat "-cpu hv_time ..." (což u svých VM v Qemu scriptu takto mám).

Každopádně mě Libvirt a Virt-manager zase zklamal. Zase jsem se utvrdil v tom, že někdy věci usnadňuje, ale někdy je to zase zbytečná vrstva nad Qemu, která je zdrojem bugů (snad libvirtu nekřivdím, protože to může být i bug přímo v qemu).

PS: ani já jsem přes google nenašel jasnou odpověď na "monitor=remoteDispatchDomainResume"

Stran: [1] 2 3 ... 15

reklama