- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Most ismét elgondolkoztam. Milyen szép volt a világ 1995-ben. Voltak honlapok, de egyáltalán nem kellett ilyen parásan mindenféle alattomosságtól félni.
Egyúttal egy érdekesség arról, hogy milyen nyelveken írt sorok és milyen arányban vannak a Firefox kódbázisában: https://4e6.github.io/firefox-lang-stats/
- A hozzászóláshoz be kell jelentkezni
Azon meglepődtem, hogy van benne assembly kód. Szép lehet ezt megannyi CPU architektúrára mind megírni. Mi az, amihez még a C sem elég alacsony szintű? Azért kérdem, mert MCU-ra írok épp hardware közeli kódot C-ben, regiszter szinten kell piszkálni a hardwert - nincs oprendszer -, s nincs szükség assembly programozásra. Ebbe tehát az interrupt service rutinok is beleértendők, meg a DMA kezelés is.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Például vektorizációnál kockás papír - ceruza módszerrel mélyebben átgondolva kb. duplázni lehet a tempót. Személyes tapasztalat (RF jelfeldolgozás).
20 éve ez volt egy látványos példa, ami azóta még tovább ágazott: https://www.mpg123.de/cgi-bin/scm/mpg123/tags/1.26.4/src/libmpg123/
* ott vannak a különböző CPU képességekre kihegyezett assembly-k
* ha meg nincs pl. Sparc procira, akkor ott a C-ben írt "generic".
Olyan helyen is assembly van, ahol futásidőben akarja lekérdezni a CPU képességeit, hogy aszerinti utasításkészlettel rendelkező függvényt használjon a szoftver a gyors műveletekhez.
Firefox esetén konkrétan például:
./security/nss/lib/freebl/sha512-p8.s
./media/libtheora/lib/arm/armopts.s
./third_party/rust/sha-1/src/lib.rs --> sha1_asm https://crates.io/crates/sha1-asm
És ide jutsz: https://github.com/RustCrypto/asm-hashes/tree/master/sha1/src
MCU: ha majd az ARM mikrovezérlőkben is benne lesz a NEON HELIUM, akkor ott is indulhat a kockás papír-ceruza módszer, amikor még egy picit tovább kell nyújtózkódni pl. a jelfeldolgozás számítási sebességével.
- A hozzászóláshoz be kell jelentkezni
lehet, hogy egy C kódot váltasz ki, ami egy kritikus helyen van (dom tree keresés/rendezés/összeállítás) és másodpercenként ezerszám hívódik meg. Ha csak x64-en nyersz +10% -ot ami a vezető arch náluk, akkor megéri az asm betét
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Én egyébként többet programoztam assembly-ben, mint bármilyen más nyelven, de azok jellemzően MCU-k, illetve régen még Z80. Szóval semmi bajom az assembly-vel, kedvelem, csak ilyen CPU architektúrákra, amelyből annyi van, mint csillag az égen, illetve igen bonyolult a hardware, meglehetősen kellemetlen ezeket a nagy vackokat assembly-ben piszkálni, ráadásul a C fordítok manapság jól optimalizálnak, meglehetősen célszerűtlennek tűnik egy felső rétegben futó alkalmazás egy-egy részét assembly-ben írni. Ha kernelről van szó, még megértem, a (g)libc esetén is esetleg indokolt lehet, de már ott is kérdéses, attól felfelé már nehezen hiszem el. Jó, persze aztán vannak az X-et megkerülő, az alkalmazást közvetlenül a videodriverrel összekötő, rétegeken átnyúló megoldások, amelyek gyorsak, de minden ésszerűséget, strukturáltságot nélkülöznek.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
én volt, hogy elkövettem asm betétet és csak 3%-ot nyertem az eredeti c kódhoz képest. Viszont ez egészen konkrétan egy adatbázis szerver volt, ahol a kérdéses kód minden query-nél lefutott, ha mindez másodpercenként 4m alkalommal történik, akkor ott már igen szignifikáns az a 3%
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
A C fordító (gcc, clang) normál esetben megdöbbentően jól fordít, kár hozzányúlni assembly szinten.
Akkor kell hozzányúlni, ha spéci dolgot szeretnénk elérni, amit a C fordító semmiképpen nem ért meg, és azzal nem +3%-ot, hanem akár +100%-ot is nyerünk és van eset, amikor ez szükséges.
Ilyen amikor valójában mélyebb optimalizáció kell. Például a fent írt vektorprocis témánál ott nyersz sokat, ha kockás papír - ceruza és ügyesen használod a 16 AVX regisztert vagy a 32 darab NEON regisztert, ezzel memóriaműveletet spórolva. Főleg ARM procikon jellemző, hogy a proci nagyon gyors de a RAM visszafog. Ezt az átfogó, már algoritmus átdolgozást is tartalmazó mutatványt nem lehet simán C fordítóval megoldani.
Tehát valójában nem az algoritmus fordítása, hanem az algoritmus és a regiszterszám (16 darab ill. 32 darab) összhangba hozása a varázslat. Lényeg, hogy az aritmetika során minél kevesebb legyen a RAM művelet.
Lásd még: https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Advanced_Vecto… ... AVX2 jellemző, AVX512 a procik kis arányában (főleg XEON-ok).
ARM Cortex A.. esetén: https://image.slidesharecdn.com/tphcc6ianrickardsneonopensymposia-14120… ... 64 bites módban dupla annyi NEON regiszter érhető el.
- A hozzászóláshoz be kell jelentkezni
Azért erre C-ben vannak mindenféle bűvszavak pl. register uint_fast32_t képében.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Mérd meg, hogy nélküle mennyivel lassabb a lefordított kód futása. Döbbenni fogsz.
A hitványabb fordítóknál a "register" szó tényleg segített, gcc és clang úgy tapasztaltam, hogy túllépett ezen.
Az "uint_fast32_t" szintén hatástalan alapból 32 bites int-tel dolgozó architektúrán.
- A hozzászóláshoz be kell jelentkezni
Arról nem is beszélve, hogy mekkora böhöm bloatware lenne indokolatlanul az FF. Még most is csak egy 56,4 MB-os csomagja van.
READY.
▓- A hozzászóláshoz be kell jelentkezni
A python gondolom a buildhez/valami toolinghoz kell, de Java? Mi a fene. :D
Egyébként hogy kivágták a Mozillából a Rustos részleget gondolom a komponensek átírása sincs már annyira erőltetve C++ról. Sikerült magukat még jobban beszopatni az egésszel így, félig ebben van írva a böngésző, félig abban.
- A hozzászóláshoz be kell jelentkezni
Java:
./mobile/android/
./third_party/libwebrtc/webrtc/sdk/android/
mappákban van a válasz.
Kiváncsi leszek én is, hogy mennyire vesznek vissza a Rust-beli törekvéssel. Ma az oldal szerint ( view-source:https://4e6.github.io/firefox-lang-stats/ )
100 * 3048461 / (3048461 + 8491973) = 26.415 % Rust arányt mutat a [ Rust + C++ ] kódmennyiséget nézve.
Meg kell újra nézni hónapok múlva, hogy merre mozdul el ez a 25 éves múlttal rendelkező kódbázis.
- A hozzászóláshoz be kell jelentkezni
Valami ilyet kellett volna az EU-nak is kiötlenie, nem azt a baromi idegesítő cookie-banner baromságot...
- A hozzászóláshoz be kell jelentkezni
Na igen. Meg esetleg szabványosított kézfogást bevezetni, hogy lehessen alapértelmezett válaszom. És ha nem lehet azzal a választással használni az oldalt, akkor legyen popup, hogy biza itt dönteni kell, bemegyek-e vagy sem és addig ne is jelenítse meg a tartalmat. Olyan csoda jó a technológia, csak valamiért a zavarosban szeretnek halászni.
- A hozzászóláshoz be kell jelentkezni
A cookie bannerban az a jo, hogyha nem az 'accept all'-ra kattintasz, akkor szembetalalod magad egy 10 oldalas kerdoivvel...
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
i don't care about cookies addon. uBlock origin mellett másik musthave cucc az internethez.
- A hozzászóláshoz be kell jelentkezni
ühümm, kíváncsian várom hány elb*szott entrspájz management felület fog egycsapásra működésképtelenné válni...
- A hozzászóláshoz be kell jelentkezni
Feltételezem, lehet kivételeket beállítani vagy kikapcsolni az egészet, ha több gondot okoz, mint amennyi hasznot hajt.
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
- A hozzászóláshoz be kell jelentkezni
Kattints az URL-től balra látható pajzs ikonra és ott beállíthatod.
- A hozzászóláshoz be kell jelentkezni
Kellett neked mondani. Most kiderült, hogy a hup is kémkedik. :-D
READY.
▓- A hozzászóláshoz be kell jelentkezni
hup -> twitter -> nagyvilág :)
- A hozzászóláshoz be kell jelentkezni
En azt hittem a cookie eleve igy mukodik.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Mondjuk 2021-ben nem ártana, ha egy weboldal self-contained lehetne. Értsd: ne lehessen olyan tartalmat beágyazni (képek, js), ami más URL-ről származik. Egy rakat problémát megoldana.
- A hozzászóláshoz be kell jelentkezni
Lehetni lehetne, csak éppen egy csomó funkcionalitás/szolgálatatás lényege pont az, hogy máshonna tölt be.
- A hozzászóláshoz be kell jelentkezni
... es pont ezektol olyan szajbakurt lassu az egesz interweb. Es meg nem is attol amit latsz (pofakonyv-lalykolos ikon meg ilyenek) hanem amit nem latsz. Kezdve az "ahany javascriptes library, annyi helyrol rantsuk le" mentalitastol az osszes adware-trackeren at a "lefuttatom az osszes fogadd-el-cookie-beallitasokat szkriptet akkoris ha a mar egyszer elfogadtad"-ig.
- A hozzászóláshoz be kell jelentkezni
>Kezdve az "ahany javascriptes library, annyi helyrol rantsuk le" mentalitastol
Ez nagyjából 10 éve nem divat már. Jellemzően használnak valami package + modulkezelőt fejlesztésnél és a kimenet egy (vagy mérettől/beállítástól függően több) JS bundle lesz, amit egy helyről hostolnak.
>az osszes adware-trackeren at
Ezek használata sajnos viszont az. De ha rászánsz kb. 2 perc munkát, akkor nevetségesen könnyen tilthatók (nem tiltja ezeket alapból a FF már egyébként?), onnantól pedig nem lassítanak semmit.
- A hozzászóláshoz be kell jelentkezni
Hát ez jó vicc... Csak így gyorsan, hogy mi honnan jön egy átlag weboldalnál:
- js engine külső siteból, ami azért jó, mert 2MB js kóddal nagyon hatékonyan meg lehet oldani 2KB-nyi hasznos tartalombetöltését (hajbajzer lájkolja ezt)
- fontok google
- videók youtube
- képek random
- analitics google
- facebook, twitter, youtube a tracking és a hülye like meg share gombok miatt
És még a jó franc tudja. Szóval az oldalak úgy 95%-a be sem töltődne így rendesen.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Igen, de attól, hogy ez így van, ez még nem jó. Amire reagáltál, ott épp az a felvetés, hogy az egész oldal arról a szerverről jöjjön, ahova ellátogattál. Pontatlan a megfogalmazásom. Arról az oldalról.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Mivel a funkcionalitásra szükség van, akkor max máshogy érik majd el a célt, legrosszabb esetben ugyan ezek a szarok valahogy keresztül lesznek proxyzva a célszerveren.
Tényleg sokkal faszább lenne, ha egy jól bekonfigolt böngészővel nem lehetne triviálisan kiszűrni az ilyen fosokat, meg magasabb költsége lenne (mondjuk a megnövekedett hálózati forgalom miatt) a weboldalak üzemeltetésnek. Biztosan mindenki nyerne rajta, de főleg a felhasználók...
Én jelenleg egy mezei FF installal + egy db. plugin (ublock) felrakásával mentesülök a webes szutymákok 90%-ától, köszönöm szépen, de nekem ez a rendszer így megfelel. Reálisan nézve kétlem, lehetne ennél kényelmesebb a helyzet számomra.
- A hozzászóláshoz be kell jelentkezni
A Mozilla is ráfanyalodik a reklámokra:
https://bitport.hu/a-mozilla-is-rafanyalodik-a-reklamokra
Most éppen tesztjelleggel hirdetések értékesítésével próbálkoznak. Mint a vállalat weboldalán olvasható, egyelőre kísérletként kínálnak hirdetőknek ún. szponzorált top site-okat, melyeket a Firefox kezdőoldalán vagy egy új tab/ablak megnyitásakor jelenít meg a böngésző. A szolgáltatást egyelőre csak egy szűk tesztelői körnek tették elérhetővé.
A Mozilla azt ígéri, hogy itt olyan szponzorált oldalakat jelenít meg, ami az adott felhasználónak hasznosak lehetnek. A modell szerint pénze ebből a Mozillának akkor lesz, ha a felhasználók rákattintanak a szponzorált lapokra. Emiatt a vállalat alapvető érdeke, hogy valóban releváns site-okat jelenítsen meg ezeken a "csempéken".
Ez elég érdekes lesz Total Cookie Protection -al.
- A hozzászóláshoz be kell jelentkezni
<insert födre köpős szmájli here>
Már így is tele van baszva fizetett - és a felhasználók szemszögéből kéretlen - szarokkal, mint:
- lockwise
- sync
- kitörölhetetlen kereső motorok
- kitörölhetetlen Root CA-k.
- "opt-out"-os telemetria
Most még majd reklámot is tol az arcomba??
Ehhez képest a főoldalon még mindig ez áll:
Nincsenek kétes adatvédelmi irányelvek vagy hátsó ajtók a hirdetőknek. Csak egy villámgyors böngésző, ami nem bocsátja áruba.
Ez már kimeríti a pofátlan hazugság fogalmát??!
- A hozzászóláshoz be kell jelentkezni
Amiket felsoroltál nem kötelező használni, vagy kikapcsolhatók.
- A hozzászóláshoz be kell jelentkezni
Egyrészt kikapcsolható, másrészt pl. a pocket (néhai readitlater) tök hasznos, én már sok éve használom.
Plusz továbbra is kérhető, hogy az új oldal teljesen üres legyen. Amúgy meg nem értem, hogy mi a problémád abból, hogy próbál önállóan pénzhez jutni.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Nekem van egy olyan kiegeszitom, hogy autosuspend tab.
Es be lehet allitani, hogyha 10 percig nem neztel meg egy tabot (vagy 20 vagy akarmennyi), akkor kilovi alola a javascriptet.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Most frissítettem... Más valaki nem tapasztalt olyan problémát, hogy a kerberos ticketeket eldobja/elrontja?
Simán kinit-tel kérek egy ticketet, amit használok site-okhoz történő auth-ra is.... És valahogy a frissítés óta random idő után, random site-oknál eltűnik a ticket (feljön a jelszóbekérés mint fallback), kinit -R pedig azt mondja hogy ticket expired, az pedig kizárt.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni