Společnost Raspberry Pi patřící nadaci Raspberry Pi chystá IPO a vstup na Londýnskou burzu.
Google na své vývojářské konferenci Google I/O 2024 představil řadu novinek. Keynote byl věnován umělé inteligenci (DeepMind, Gemini, Responsible AI).
V Gitu bylo nalezeno 5 zranitelností. Opraveny jsou ve verzích 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 a 2.39.4. Útočník může připravit repozitář tak, že při jeho klonování (git clone) může dojít ke spuštění libovolného kódu.
Virtualizační softwary VMware Workstation Pro a VMware Fusion Pro jsou nově pro osobní použití zdarma. Softwary VMware Workstation Player a VMware Fusion Player končí.
Linuxová distribuce Endless OS (Wikipedie) byla vydána ve verzi 6.0.0. Přehled novinek i s náhledy v příspěvku na blogu, poznámkách k vydání a také na YouTube.
Byl vydán Mozilla Firefox 126.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vylepšena byla funkce "Zkopírovat odkaz bez sledovacích prvků". Přidána byla podpora zstd (Zstandard). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 126 je již k dispozici také na Flathubu a Snapcraftu.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 11.0. Přehled novinek v aktualizované dokumentaci.
Byla vydána nová verze 24.0 linuxové distribuce Manjaro (Wikipedie). Její kódové jméno je Wynsdey. Ke stažení je v edicích GNOME, KDE PLASMA a XFCE.
Byla představena oficiální rozšiřující deska Raspberry Pi M.2 HAT+ pro připojování M.2 periferii jako jsou NVMe disky a AI akcelerátory k Raspberry Pi 5. Cena je 12 dolarů.
V Praze o víkendu proběhla bastlířská událost roku - výstava Maker Fair v Praze. I strahovští bastlíři nelenili a bastly ostatních prozkoumali. Přijďte si proto i vy na Virtuální Bastlírnu popovídat, co Vás nejvíce zaujalo a jaké projekty jste si přinesli! Samozřejmě, nejen českou bastlířskou scénou je člověk živ - takže co se stalo ve světě a o čem mohou strahováci něco říct? Smutnou zprávou může být to, že provozovatel Sigfoxu jde do
… více »Co si budeme namlouvat. Pro linux je dnes jen málo opravdu kvalitních programů, které trpí spoustou nedodělků, a ještě méně komerečních programů. Neříkám, že opensource programy jsou špatné, ale přeci jenom ty komereční jsou častěji kvalitnější, stabilnější a hlavně většinou plní svou funkci.
Na linuxu se mi nelíbí, že existuje spousta grafických rozhraní jako je GTK+, QT, atd. Programátor má potom těžký výběr, pro které rozhraní program udělat, a o to těžší je převést nějaký program do linuxu, pokud je napsán ve WinAPI.
Možná by nebylo špatné, kdyby někdo napsal knihovny, které jsou 100% kompatibilní s Windows (nejlépe XP) a k tomu příslušné eSDéKáčko. Poté už by nebyl takový problém převádět spoustu kvalitních programů do linuxu. A nějaké ty SW patenty nás zatím u nás v Evropě trápit nemusí. Možná, že by se toho mohli uchytit vývojáři WINE, kteří už přece jenom vědí, jak na to.
Možná si říkáte, že jsem jenom blázen, ale uznejte, že po naprogramování takovéto knihovny by se zvýšil počet programů pro linux a časem už by ani nikdo nevěděl, co je to Windows.
Tiskni Sdílej:
a to pouze na 32bit linuxuIMO můžete na 64bit wine spouštět 64bit Win32 aplikace.
a to pouze na 32bit linuxuSeš úplně mimo.
Vývojáři WINE snad vytvářejí emulátor, který spouští WIN aplikace (a to pouze na 32bit linuxu). Já myslel vytvořit knihovnu, se kterou by se program jednoduše znovu zkompiloval bez změny kódu programu.Wine is not emulator. Wine je implementace WinApi pro Posixové systémy. Vytvořit jednu knihovnu je nesmysl, už kvůli tomu, že si Windows dodnes nosí balast ještě dob Windows 3.11 (jakže se jmenovalo to rozhraní pro multimédia? DDI?) kvůli zpětné kompatibilitě. Což je imho krásná ukázka koncepce v komerčním provedení .
ty komereční jsou častěji kvalitnější, stabilnějšíNebudu komentovat, to by byl zase flamewar.
Programátor má potom těžký výběrOMFG. Chudáček programátor. A co třeba Javisti, když si musejí vybírat mezi AWT/Swing/SWT.
a o to těžší je převést nějaký program do linuxuSměšné. To je asi jako říct, že lidi chodí pěšky, protože si nedokážou vybrat auto.
Možná by nebylo špatné, kdyby někdo napsal knihovnyUž je tu Winelibs. Asi nemáte potuchu, jak pokročilejší je GTK/Qt ve srovnání s WinAPI. V GTK/QT (a i v Javě) se prostor okna nějak "rozděluje", takže z toho plynou výhody, jako je bezproblematické roztahování okna (widgety se přizpůsobí). Ve Windows je to natvrdo (ano, třeba Delphi apod. to nějak "řeší"): control má natvrdo své rozměry i umístění. WinAPI je založeno na těžce neefektivním zasílání zpráv; troufám si říct, že přímé volání metod/funkcí toolkitu bude rychlejší. GUI je z celé aplikace naprosté minimum - tím že do Linuxu (ještě více) zanesete nekvalitně navržené GUI/API Windows, které se s časem rozšiřuje už od dob Windows 3.1 (a asi i 2.0), ničemu nepomůžete.
Asi nemáte potuchu, jak pokročilejší je GTK/Qt ve srovnání s WinAPI. V GTK/QT (a i v Javě) se prostor okna nějak "rozděluje", takže z toho plynou výhody, jako je bezproblematické roztahování okna (widgety se přizpůsobí). Ve Windows je to natvrdo (ano, třeba Delphi apod. to nějak "řeší"): control má natvrdo své rozměry i umístění.Přesně tak, vždyť GUI definované v XML souboru má být novinka nových Windows (Avalon, Aero, nebo tak se to bude jmenovat), zatímco trapné Qt i Gtk to už hezkých pár let zvládají. Layout managery, aby ve Windows pohledal (pouze .Net je už obsahuje). Už jsem vzpomínal v článku o Kommanderu, viděl jsem aplikaci ve Visual Basicu, kde yohle programátor řešil ručně a byla to podstatná část kódu aplikace
A co třeba Javisti, když si musejí vybírat mezi AWT/Swing/SWT.Tady je to jasné. AWT je pasé (některé věci se stále používají, ale GUI jako takové ne), se SWT mám špatné zkušenosti - takže u mě jednoznačně vítězí Swing.
WinAPI je založeno na těžce neefektivním zasílání zpráv; troufám si říct, že přímé volání metod/funkcí toolkitu bude rychlejší.Přímé volání ano. Ale co třeba události v Qt (vytvořit instanci potomka
QEvent
, nastavit parametry, zavolat metodu), o signálech/slotech nemluvě. Zasílání zpráv (jak synchronní, tak asynchronní) zase tak těžce neefektivní není, tady bych zásadní problém neviděl. Zvlášť v porovnání s X protokolem.
GUI je z celé aplikace naprosté minimumGUI je ta nejnáročnější a nejkomplikovanější část aplikace. U průměrné aplikace zabere vývoj a ladění GUI přes 60 % času stráveného celou aplikací. Nicméně souhlasím s tím, že zatahovat Win32 API do Linuxu (WINE nepočítám) by byla chyba.
Zasílání zpráv (jak synchronní, tak asynchronní) zase tak těžce neefektivní neníPravděpodobně nemáte moc velké zkušenosti z prvky jako je Win32 TreeControl. Je to brutálně pomalé.
GUI je ta nejnáročnější a nejkomplikovanější část aplikace.Já GUI dodělávám k existujícímu kódu. A u všech aplikací, co jsem zatím dělal, bylo nejsložitější "jádro", ne GUI, které si z velké části naklikám a zbytek znám z hlavy.
A u všech aplikací, co jsem zatím dělal, bylo nejsložitější "jádro", ne GUI, které si z velké části naklikám a zbytek znám z hlavy.Mohou být aplikace se strohým GUI (např. pár vstupních a výstupních polí, nějaké to tlačítko). Ale většinou je to mnohem horší - sice to jde v základu naklikat, ale pak nastává dlouhé období jemných úprav, aby byly např. povoleny (nebo viditelné) jen ty prvky, které mají v dané situaci význam. Každé složitější GUI musí být také již ve fázi návrhu (před implementací) otestováno po ergonomické stránce. To mnoho vývojářů zanedbává, a výsledkem je nespokojenost uživatelů. Prostě, kvalitní GUI je vždy těžká práce.
A u všech aplikací, co jsem zatím dělal, bylo nejsložitější "jádro", ne GUI, které si z velké části naklikám a zbytek znám z hlavy.Mohou být aplikace se strohým GUI (např. pár vstupních a výstupních polí, nějaké to tlačítko). Ale většinou je to mnohem horší - sice to jde v základu naklikat, ale pak nastává dlouhé období jemných úprav, aby byly např. povoleny (nebo viditelné) jen ty prvky, které mají v dané situaci význam. Každé složitější GUI musí být také již ve fázi návrhu (před implementací) otestováno po ergonomické stránce. To mnoho vývojářů zanedbává, a výsledkem je nespokojenost uživatelů. Prostě, kvalitní GUI je vždy těžká práce.
Dobrý programátor sa nezamýšla nad tým, ktorú knižnicu použije vo svojej aplikácii. Dobrý programátor robí GUI až nakoniec.
V komerčných firmách sú programátori platený za prácu. Členovia týmu pracujú často v jednej budove/kancelárii a komunikácia nie je problém. K dispozícii je tým profesionálnych testerov a nad tým všetkým stojí minimálne jeden manažér "s bičom". To je krvou zaplatená kvalita.
Nefňukaj! Nie je umenie pracovať s kvalitnými aplikáciami. Predstav si, čo dokážeš ak teraz prestaneš používať X-i...
Dává ta věta někomu smysl? Kvalitní program má nedodělky?
Programátor má potom těžký výběr, pro které rozhraní program udělat.Může si napsat vlastní.
Pokud chce napsat kompatibilní program napříč mnoha OS, může to napsat v Javě. Možná to ještě nevíte, ale Linux a Windows nejsou jediné OS.
Co si budeme namlouvat. Pro linux je dnes jen málo opravdu kvalitních programů, které trpí spoustou nedodělků, a ještě méně komerečních programů.
Hezkej den
Dobra prostitutka se preci taky nehodnoti podle toho, jak je zmalovana, ale jaka je v posteli ..Ne? A podle čeho?
Poté už by nebyl takový problém převádět spoustu kvalitních programů do linuxu.Nevím sice které "kvalitní programy" pro Windows máš na mysli, ale předpokládám, že firmy jako Adobe, Autodesk, Microsoft a jiní se určitě nebudou snažit "nějak matlat" svoje aplikace tak, aby nějak chodily v nějaké distribuci GNU/Linux . Nemám nic proti Windows (dokonce pro ně pracovně vyvíjím i nějaké aplikace), ale i v mnou používané distribuci (Fedora Core 4) jsem našel alternativy pro mnou používané aplikace z Windows. A pokud budu potřebovat napsat nějakou multiplatformní aplikaci, tak si ji napíšu v Javě (JFC/Swing toolkit), nebo v Pythonu (PyGTK bindings pro GTK).