Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
Spouštět webový prohlížeč jenom kvůli nákupu kávy? Nestačí ssh? Stačí: ssh terminal.shop (𝕏).
Yocto Project byl vydán ve verzi 5.0. Její kódové jméno je Scarthgap. Yocto Project usnadňuje vývoj vestavěných (embedded) linuxových systémů na míru konkrétním zařízením. Cílem projektu je nabídnou vývojářům vše potřebné. Jedná se o projekt Linux Foundation.
Operační systém 9front, fork operačního systému Plan 9, byl vydán v nové verzi "do not install" (pdf). Více o 9front v FQA.
Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu. Řešeny jsou také 2 bezpečnostní chyby.
Lennart Poettering na Mastodonu představil utilitu run0. Jedná se o alternativu k příkazu sudo založenou na systemd. Bude součástí systemd verze 256.
Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
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).
Tiskni Sdílej: