Elfogadás vs megtűrés: Kommunizmus, Antifa, Nácik, Multik - Linux
Vložit
- čas přidán 11. 07. 2024
- És mi lenne, ha félre lehetne tenni az ideológiát?
Egy kis térkép a történésekhez - ahogy én látom.
#linux
#woke
#magyar
#lunduke
#futo
#magosit
#licence
00:00:00 Intro
00:01:26 OpenSuse és a tolerancia
00:10:30 Lunduke: tech news / ladybird
00:12:36 NixOS "irtás" antifa zászlóval
00:18:31 Régen hogy kezelték?
00:20:09 NixOS alapító lemondatás
00:22:36 Hasonló esetek: Stallman
00:23:31 Miért baj ez?
00:24:39 Ladybird: Támadják, mert politikamentes?
00:28:01 Fejben dől el mi idegesít téged!
00:29:26 Transz, punk, skin disztrók: Tőlem csináld...
00:30:25 Woke vagy? Magyarul beszélj! :-)
00:31:34 Multik, mozilla, gugli, licence-ek
00:41:26 FUTO: free software, source first, open source, fairsource
00:45:04 Pénzkeresés nyílt forrással? (FUTO, MagosIT)
00:51:15 Oszd meg és uralkodj?
00:53:23 Pale moon, netsurf, dillo, ladybird
00:54:49 MagosIT gamedev licence (fairsource pénzkeresés)
00:58:14 MagosIT webdev licence (fairsource pénzkeresés)
00:59:03 MagosIT appstore-based licence (fairsource pénzkeresés)
01:00:00 FUTO-s ötletek
01:02:57 LundukeOS
01:05:53 Meritokrácia
01:07:58 Az inga kilengése és a ló túlsó oldala
01:08:38 Az open source kommunizmus, vagy kapitalizmus?
01:14:30 Linus Torvalds "woke"? Nem.
01:25:08 OpenSSH sérülékenység
01:30:55 Összefoglalás
01:33:07 Elfogadás vagy megtűrés?
01:41:12 Outro - Věda a technologie
A prog-on egyértelműen a windows-t és a js-t istenítik a C/C++ meg maga az ördög, ami helyett bármi jobb, akár a Rust is. Egy S... nevű figura volt egy időben nagyon meggyőződve arról, amikor kijött egy Unreal WebGL-es Firefox demo, hogy ez a jövő, az összes játékot JS-el fogják fejleszteni, lőttek a natív nyelveknek. Ehhez képest most a mobil játékok aránya kb 60% a legnagyobb és kulcsfontosságú a low level optimalizálás és a low level API-k használata, a böngészős játékok aránya pedig még az 5%-ot se éri el. Kíváncsi vagyok ezzel kapcsolatban a nyelvekről compilekről szóló videodra majd. :)
ez a ladybird most elkezdett érdekelni , kiváncsi vagyok milyen lesz
Engem érdekelne mi a problémád a Wayland-el.
Amennyire én tudom, kevesebb az útvonal a grafikus felületen a megjelenítés és a vezérlés között. Arra lett kitalálva amire ma használjuk a gépünket.
Engem is érdekelne. Nekem pl az, hogy nvidia kártyám van és nem működik megfelelően a wayland. Emiatt pedig nem veszek új kártyát. ;-)
Engem érdekel a Rust miért tetszik neked egyre kevésbé
Király ez a video is. Annyi észrevételem van, hogy a Pale Moon firefox-based. Én a Mullvad-ot tartom kicsit külön utasnak bár valójában ez sem az. A Ladybird -re kíváncsi vagyok, hogy mi lesz a sorsa.
Üdv!
Én azért tartom mégis különutasnak, mert nem csak egy "szimpla" fork 2016 körülről, hanem már előtte gyakorlatilag teljesen forkolva volt, csak akkor kezdték el más néven is nevezni az engine-t, mert már annyira felismerhetetlenné mássá alakult, mint a gecko.
Csak hogy néhány dolgot említsek: A goanna engine a gecko-val ellentétben semmi rust elemet nem tartalmaz, végig supportálják az XUL-t és emiatt a régi plugin rendszert, de ami számomra a legfontosabb, hogy nem álltak be a multi-process browser sorba!
forum.palemoon.org/viewtopic.php?f=26&t=17442
^^Itt a fickó úgy fejti ki az álláspontját ezzel a "minden tab egy új process és minden szál helyett is csak process van mindenütt" dologgal kapcsolatban, hogy én se tudnám jobban! Iszonyatosan pazarló dolog és aki még érti is, hogy pazarló, az is csak esetleg arra gondol, hogy az OS process mivel drágább, mint a sima szál, de a mögöttes további perf loss-al már nem is foglalkoznak jellemzően azok az emberek sem: tehát hogy mondjuk minden message passing lett, a cookie-kal mi történik, vagy ami ugye a legdurvább, hogy amikor van is osztott kód, azokat többször, több process-nek kell elérhetővé betenni és betölteni meg ilyesmi. Persze mindegyikre vannak "workaround"-ok, hogy ne legyen félelmetesen lassú, de ram usage-et egy teljes böngészőn, amit napi böngészésre használhatsz tényleg náluk látok legkevesebbet!
A mullvad browser sajnos sokkal közelebb áll a standard gecko-hoz (firefox), mint a pale moon, ahol ilyen extra nagy méretű változások vannak a forkban, hogy tényleg méltán nevezik "goanna" engine-nek már lassan 10 éve és nem csak egy forknak. A mullvan ilyen mód lényegében inkább az "úgy viszonyul a mullvad a firefoxhoz, mint a brave a chrome-hoz" sztori...
Alapvetően egyébként ha a brave és a mullvad közül kéne ajánlanom valamelyiket, inkább mondanám én is az utóbbit, de a moon, szerintem valóban igazi gem - a Ladybird-nek van azért valóban esélye, hogy valami hasonló (sőt elvileg jobb) legyen. A ladybird amúgy az egyik ritka kevés projekt, ahol már most C++23 van és ugye nem valami legacy kódbázis, hanem viszonylag új is, meg kulturált, de daily browingra szerintem még nem jó.
A pale moon-hoz képest a netsurf még a nulláról saját engine-es, ami már a ladybird-höz hasonlóan "majdnem jó napi böngészésre" és érdekes, de az is egy más OS-ről származó "szökevény". Lightos dolgokra érdemes néha feltenni, főleg öregebb gépen. Még egy egész kis JS-t is ki lehet erőltetni belőle, ha kézzel build-eled, de a DOM-ot kéne refaktorálniuk, hogy rendes support lehessen, szóval ne számíts sok jóra, csak lefut a kód és "néha nem totálisan hülyeség" az eredmény. A dillo meg ugye még a HTTPs-el is küzdögetni szokott, de az is ground-up saját engine-es. Sajnos más dologról nem tudok: ez a három + a lady most jelenleg csak a "valóban különutas" és ez elég szomorú szerintem. Mármint a valóban külön út tényleg azt jelenti, hogy a rendering már saját, architekturálisan meg minimum brutál erősen már eltér az eredeti engine-től, vagy ground-up tényleg. Pár kis change bele az még nem ilyen, de hogy a threading modell teljesen más, meg a renderer már.... szóval az már szerintem jogos a palemoon esetén, hogy az saját engine... a fickó viszont csak 1-2 éve kezdett másokat is beengedni a fejlesztésbe, mert előtte teljesen one-man-show volt - csoda, hogy nem égett ki!
Igazából a pale moon legnagyobb hátránya, hogy nagyon össze van nőve az x86-al jelenleg. Volt arm fork egy ideig, de azt tényleg valaki más csinálta one-man-show és ő viszont abbahagyta azt. Meg bár régi, egymagos gépeken ez a legjobb és a legkevésbé pazarló, de SSE(2) viszont kell hozzá. Egyrészt attól, hogy kell gyorsabb az alap build, de másrészt kicsit korai pentium / amd nem viszi, csak az olyan 20 éves környékiek, vagy max 25 évesek (az SSE1-es build, ami 99'-ig visszafele támogat, az ugye nem official, de még létezik - a rendes build SSE2-es). Szóval a 25 évnél régebbi gépekre gyors böngészési élményt varázsolni már csak a netsurf / dillo irányban lehet...
Örülök, hogy tetszett a videó! Egyébként amit írok, nem kötekedés jelleggel írok, hanem hidd el én örülnék a legjobban, ha a mullvad vagy pár másik dolog valóban külön út lenne, de nagyrészt még nem 😞. Nagyon káros, hogy egy olyan "kvázi-dualizmus" van, ahol a webkit / chromium 90%+ és a maradék mind gecko és a gecko is sok architekturális döntésben csak koppintja a webkitet sajnos.... A pale moon, de még a netsurf is ebben ilyen kis gyémántok tényleg és örülök, hogy van most még egy irány és még pénz is került mögé - kíváncsi leszek 🙂
Meg a mullvad / brave jellegű dolgokra nem tűnik jó "kiváltó terméknek" a pale moon. Nincs baj vele, de más a fókusz. A mullvad / brave-re szerintem a ladybird jobb kiváltó lesz ha sikerül nekik... A pale inkább a kevesebb bloat és kevesebb pazarlás fele megy, mint mondjuk privacy dolgok felé - a lady-ben kevesebb a bloat-os cél is van és privacy-s cél is van, de még nem olyan használható... Érdekes lesz tényleg mi lesz belőle ;-)
@@u9vata Nagyon köszönöm ezt a nagyon mély elemzést és véleményt. Én ennyire mélyen nem néztem meg a mullvad-ot és a pale moon-t, én ehhez képest "csak egy tojásban ülő veréb fióka vagyok" :D Magyar nyelven nem hiszem, hogy szakmai oldalról ennyire egzakt forrás lenne. Szóval én levédetném vagy beküldeném eme sorokat egy szaklapba. :-) Csak így tovább! 🙏
IFC? Oh koléga :))
Archicad kapcsán találkoztam.
Használva, vagy fejlesztőként? 🙂
Fejlesztőként maga a szabvány is nagyon macerás, mert túl sokféleképp engedi ugyan azt leírni - másrészt sajnos az van, hogy implementálod a szabványt... amit mások vagy jól kezelnek... vagy nem....
Az maga, hogy elvileg nyílt szabvány az jó lenne - de a megvalósítás nagyon félrement pl. ott is... Sajnos eleve is bonyolult dolog és arra még rá is épül mindenféle cég minden üzletpolitikája is.
@@u9vata fejlesztve, c++.. van szívás :))
btw érdekelne a saját nyelved amit említettél.
@@hudumannaia Ha még vannak ilyen feladataitok, akkor a nemsoká open source-olódó mini tool-om (a stepvis, amit csomó részt itt livekódoltam lényegében), lehet hogy hasznos. Nekem elég hasznos volt a legutolsó formája.
A programnyelv(ek)ről: Ez igazából két programnyelv! Az egyik maga a fordító utasítás-nyelve, mert teljesen más módon történik a fordítás, mint a megszokott / tanított dolog. Tehát nincs LARL, vagy rekurzív leszállás, ellenben nagyon vizuálisan látszani fog, hogy a fordító melyik menetben miből-mit állít elő (már ha bekapcsolod, hogy ezt látni akarod). LLVM-t sem tervezek - lesz vagy a C-re fordítás, vagy a másik választás a saját bytekód generálósdi, valamely kisebb cuccal. Az egyik nyelv (nevezzük ezt meta-nyelvnek) lényegében használható arra, hogy saját programnyelveket alkoss és kényelmes metaprogramozásra is - tehát az inkább fordító-technológia. Ez a meta-nyelv nagyon extrémen újszerű dolgokat tud - sokkal többet vesz fel a forth-lisp vonalból, mint a szokásos dolgok, de annál sokkal "low level"-ebb és lightweight-ebb. Ezzel kb. egy library behúzni a "host-olt" másik nyelvem, de az is ezáltal kiegészíthető - illetve más is csinálhat hasonló nyelveket ezzel a dologgal (például egy shader fordítót).
A host-olt nyelv amit a meta-val írok le az már C-szerű: Igazából először csak "példa nyelvet" akartam a fenti technológiához, de ez lett mára a fő cél szerintem. Az egész abból indult, hogy "volt egy nagyon jó kis ötletem" - amivel 95%-át megfogjuk minden memory safety bajnak egy natív nyelven úgy, hogy nem fogod naphosszat valami borrow checker levezetéseit szidogatni.
A jelenlegi markdown doksiból csak copy-zok ide bekezdés címeket:
- handle-oriented programming (OOP helyett, faékes, de bölcs ownership szabályokkal)
- rekordok
- tagged union
- tagged enum (igen - ez egy másik dolog)
- unchecked és checked switch statement
- annotációk (lásd @resource)., amiből a legtöbb nyelvi elem
- fordítási idejű és tagged union interfész-alapú programozás
- Úgynevezett "like"-olás: Ez annyira top secret, mint a handle-oriented programming, de baromi áttekinthetővé teszi az algoritmusokat és adatszerkezeteket
- public, readable, protected, private
- Sajátos (nem exception-ös) hibakezelés
- több visszatérési érték
- HolyC-szerű kiegészítések a switch statement-hez
- Valódi "tömb" tíípus: ptr+hossz, de előírt optimizációkkal fordítási időre ahol lehet
- NonOwningPtr típusú smartptr (ez egyébként C++ban is implementálható - lehet hogy levideózom, de ehhez a nyelvhez fontosabb dolog)
- "jobb" elnevezések és default-ok
- "jobb" default típuskonverziók (pl. floating és integer-ek közt stb.)
- párhuzamosság: nem akarok async keyword-öt látni se... egy kicsit a go-hoz közeli dolgokat szeretnék, de van két-három saját érdekes konstrukcióm, amit még a "meta" nyelvhez / build lépésekhez találtam eredetileg ki, de ide is szerintem át kéne venni
- interfész-alapú generic (nem olyan powerful, mint a template)
- metaprogramozás a meta-nyelven lehetséges - na ez viszont extrém módon powerful: lényegében saját DSL-jeid lehetnek és azokra fordítási idejű check. Mondjuk shader fordításhoz, DB library-hoz stb.
Jah... természetesen... statikus típusrendszer, zárójelekkel és nem python-szerű indentálós hülyeséggel, suckless minimalizmus (a meta-nyelv főleg... azt bootstrapelhetőnek akarom akár embeddeed is) továbbá természetesen GC sem lesz!
Sok kis részletet most kihagytam - ezekhez vannak source példák - de egyébként több változatban is, mert azért nem mindegyiknél van eldöntve melyik legyen. Metaprogramozásra a zig comptime valszeeg kényelmesebb, mint ahogy el van választva meta és programnyelvre nálam - ellenben minden másra szerintem ez kényelmesebb.
Szokásos kérdés: "Mikor lesz kész?" - Szokásos válasz: fogalmam sincs 🙂.
Természetesen open source-nak tervezem, de nem véletlen nem teszem ki sehova - az első változat kódját például nullára kukázhattam simán, mert most sokkal jobb és tisztább, egyszerűbb a jelen elképzelés. Valószínű, hogy a meta része lesz előbb kész - azt lehet hogy külön is kidobom, csak magában is... De embereknek szerintem a "rendes" nyelv a praktikusabb.
Standard libnél nem akarok olyasmit, mint a jai: használjatok C-s libeket és csőváz... A standard lib és a közeg viszont olyannak van elképzelve, hogy nincsenek "meglepetés allokációk", tehát ha valami mindenképpen allokálgat, annak átadod a függvényeket / handle-t, hogy mivel tegye azt és nem random meghív valami malloc-ot, mint a sima C libek.
Kb. ennyi. Először hobbinak indult (az eredeti kód olyan is volt...), de elkezdtem komolyan venni, csak hát az ember ideje véges. Viszont jó pár szerintem nagyon jó ötlet kezdett megjelenni - főleg ezen a poszt-OOP vonalon.
@@u9vata Remélem nem haragszol meg ha azt mondom csomó dolgot nem értettem :/
Attól függetlenül sok sikert és ha felraksz valami videót ide erről akkor jó eséllyel meg lesz nézve. :D
Kíváncsi de nem nagytudású ember vagyok. Sokat tanultam tőled pl az optimalizációról.