Mikorist

da . da ne bude posle šta je ovaj radio na ovom sistemu. evo u crevca sitna

diya Linux već postoji kao moj MX Linux AUDIO derivat od 2023. Ono što sam sada uradio jeste da sam automatizovao proces kojim od pripremljenog root filesystema, kernela i boot konfiguracije ponovo pravim kompletan Live ISO. Do sada je dosta toga bilo rađeno ručno. Sada je cilj da postupak bude ponovljiv, proverljiv i da mogu da napravim novu verziju bez sećanja na to šta sam poslednji put ručno menjao. To je zapravo najveća promena. Ne pravim novi distro od nule, nego sam postojeći sistem prebacio iz faze "znam kako sam ga prošli put sklopio" u fazu "znam tačno šta se nalazi u buildu i mogu ponovo da ga napravim". Trenutna struktura projekta je: MX-25.2-AHS-diya/ ├── build.sh ├── ovo.sh ├── update-kernel.sh ├── qemu.sh ├── root-mx25/ ├── iso-work/ ├── kernel-backups/ ├── boot-backups/ └── ... Tri skripte su stvarni deo procesa izrade sistema. qemu.sh je pomoćna skripta za testiranje ISO-a u QEMU/KVM i ne računam je u build pipeline. build.sh Ovo je glavni builder. Osnovna ideja je da root-mx25 više nije samo neki direktorijum iz kog ručno pravim ISO, nego predstavlja konkretno stanje sistema iz kog mogu ponovo da napravim Live filesystem. Skripta uzima kompletan root-mx25/ i od njega pravi novi linuxfs preko SquashFS-a. Pre nego što bilo šta napravi, proverava da postoje osnovni direktorijumi i fajlovi koji su potrebni za build. Proverava i da iso-work nema zaostalih privremenih fajlova. Ovo mi je bitno zato što je ranije bilo moguće da u stagingu ostane nešto iz prethodnog pokušaja, pa posle više nije sasvim jasno šta je zapravo ušlo u ISO. Sada build prekida ako pronađe stvari kao što su .tmp, .temp, .new ili backup fajlovi tamo gde ne treba da budu. Postojeći linuxfs se pre zamene automatski backupuje. Novi linuxfs se pravi iz root-mx25 uz XZ kompresiju, sa parametrima koje sam odredio za ovaj image, i zatim se ubacuje u iso-work/antiX/. Posle toga se ponovo prave MD5 fajlovi za: linuxfs vmlinuz initrd.gz Na kraju xorriso pravi kompletan bootabilni ISO na osnovu staging direktorijuma. I ovde sam namerno ostavio jednu stvar koja mi je ranije napravila problem kao automatsku proveru. Ako nešto pukne tokom izrade, privremeni linuxfs.new se briše preko trap cleanup. Dakle nema više ručnog redosleda: raspakuj ISO kopiraj filesystem promeni kernel promeni boot napravi checksum pokreni xorriso pa se posle pitaj šta si zaboravio. Sada build ima definisan tok i proveru na više mesta. update-kernel.sh Kernel sam odvojio od filesystem builda zato što je to posebna stvar. Skripta skenira root-mx25/boot/ i pronalazi kernel koji treba da ide u Live sistem. Namerno neće da nagađa ako pronađe više od jednog kernela. Ako ih ima više, prekida rad i traži da se stanje prvo sredi. Trenutno je u sistemu: 7.1.11-1-liquorix-amd64 Odgovarajući kernel se kopira u Live staging kao vmlinuz. Ali kernel sam po sebi nije dovoljan. Live sistem mora da ima odgovarajuće module u initrd-u. Zato skripta uzima postojeći Live initrd.gz, raspakuje ga, ubacuje module za konkretan kernel i zatim ga ponovo pakuje. Posebno proverava da su prisutni ključni moduli: overlay squashfs loop isofs Posle repackovanja ne veruje samo sebi na reč, nego ponovo raspakuje napravljeni initrd i proverava da su moduli stvarno unutra. Pre promene se čuvaju backup kopije prethodnog kernela i initrd-a. Time je rešena i jedna od stvari koja je kod ručnog rada najnezgodnija: kernel i modules tree više nisu nešto što treba ručno usklađivati svaki put. Skripta praktično kaže: ovo je kernel koji imamo u root filesystemu, ovo su njegovi moduli, ovo je Live initrd i sada ćemo ih napraviti kao jednu proverenu celinu. ovo.sh Ovo je boot customization. Ne pravi filesystem i ne menja kernel. Njegov posao je da sredi boot deo ISO-a. Automatski radi izmene GRUB konfiguracije i ISOLINUX/SYSLINUX konfiguracije u staging direktorijumu. Podrazumevani boot je systemd, SysVinit entry se uklanja iz glavnog menija, a boot meni se preimenuje u diya Linux. Pre svake izmene pravi timestampovani backup GRUB, ISOLINUX i eventualno SYSLINUX konfiguracije. I ovo je jedna od stvari koje više ne želim da radim ručno. Boot konfiguracija je dovoljno nezgodna da jedna pogrešna izmena napravi ISO koji izgleda sasvim normalno dok ne pokušaš da ga podigneš. qemu.sh Ovo nije deo distribucije niti build procesa. Samo služi da mogu brzo da pokrenem napravljeni ISO kroz KVM/QEMU i proverim da li boot i osnovni sistem rade pre nego što ISO prebacim na pravi hardver. Na taj način mogu da uhvatim glupost u boot konfiguraciji pre nego što krenem da testiram pravi sistem. Audio deo Posebna pažnja je posvećena USB audio putanji zato što je to jedan od razloga zbog kojih je ovaj sistem uopšte toliko ručno podešavan. Na testnoj mašini koristim Amanero Combo384: Amanero Combo384 VID:PID 16d0:071a USB 2.0 High Speed Konkretna putanja je: Amanero ↓ USB 2.0 HS ↓ xHCI 00:14.0 ↓ IRQ 125 ↓ snd-usb-audio ↓ ALSA Amanero je fizički na USB 2.0 High Speed vezi, odnosno 480M. Kernel ga vidi kao card 0: Combo384 Amanero ALSA vidi playback uređaj, a PipeWire ga vidi kao: Combo384 Amanero Analog Stereo Amanero koristi eksplicitni USB feedback endpoint. Ne forsiram implicit feedback samo zato što taj parametar postoji u snd-usb-audio modulu. Trenutni snd-usb-audio parametri su: lowlatency=Y autoclock=Y use_vmalloc=Y implicit_fb=N Nema ručno nametnutih Amanero quirkova, quirk_alias podešavanja niti device_setup intervencija. USB descriptori su provereni direktno na uređaju. Audio playback endpoint je isochronous OUT, sa feedback endpointom za sinhronizaciju. To je bitno jer ovde više ne pričamo o nekom generičkom "USB DAC tweakovanju", nego o konkretnom uređaju i konkretnom USB audio putu. Playback koji koristim za ozbiljno slušanje ide direktno na ALSA. Za normalan desktop i stvari poput YouTube-a koristi se PipeWire. Za YouTube ostajem na 48 kHz. Ne vidim razlog da 48 kHz sadržaj nepotrebno pretvaram u 96 ili 192 kHz samo zato što veći broj lepše izgleda u nekom panelu. Trenutni direktni ALSA playback koji sam proveravao radi sa: S32_LE 2 channels 48000 Hz period_size 512 buffer_size 32768 MMAP_INTERLEAVED Dakle trenutno imamo vrlo konkretan i proverljiv lanac, a ne samo "audio je podešen". Realtime deo Ovde je bilo najviše posla zato što sam prvo morao da odvojim stvarne realtime mehanizme od gomile starih audiofiličarskih recepata koji kruže Linux forumima godinama. Kernel boot parametri trenutno uključuju: threadirqs intel_idle.max_cstate=0 nmi_watchdog=0 usbcore.autosuspend=-1 skew_tick=1 iommu=soft mitigations=off CPU governor je performance. Energy performance preference je takođe performance. Cilj nije da procesor "zvuči bolje", nego da se smanji mogućnost da scheduler, power management ili duboki CPU sleep ubace nepotrebno kašnjenje u audio putanju. Posebno sam gledao xHCI IRQ zato što Amanero ide preko USB kontrolera. Trenutno je: irq/125-xhci_hcd RT priority 95 HDA interrupt je: irq/136-snd_hda_intel RT priority 93 RTKit sam namerno spustio na oko 88/89. Ne jurim 99 samo zato što 99 zvuči kao više. Na ovoj mašini je bitnije da USB xHCI interrupt ima prioritet nego da neki userspace servis dobije apsolutni vrh scheduler skale. irqbalance je neaktivan, tako da IRQ koji je podešen za audio putanju ne šeta nasumično po procesorima. Amanero USB power management je isključen: power/control = on runtime_status = active I xHCI PCI uređaj je takođe: power/control = on runtime_status = active Proveren je i stvarni IRQ: IRQ 125 je xhci_hcd i trenutno ima veliki broj obrađenih interrupta, što znači da gledamo baš aktivan USB kontroler, a ne neki mrtav ili pogrešan IRQ. VM i scheduler podešavanja Audio specifične sysctl stvari su izdvojene u: /etc/sysctl.d/99-audio-latency.conf Trenutno: vm.dirty_ratio=10 vm.dirty_background_ratio=3 vm.swappiness=10 kernel.timer_migration=0 Ovde sam posebno pazio da ne ponovim staru grešku sa preagresivnim podešavanjima. Stari sistem je imao: vm.dirty_bytes = 335544320 vm.dirty_background_bytes = 167772160 što je 320 MB i 160 MB. To sam izbacio. Novi sistem koristi mnogo kontrolisaniji dirty cache: vm.dirty_background_bytes = 33554432 vm.dirty_bytes = 67108864 Uz: vm.dirty_writeback_centisecs = 500 vm.dirty_expire_centisecs = 3000 Poenta nije da se disk pretvori u realtime uređaj, nego da se izbegne pravljenje ogromnog dirty cache-a koji onda može da napravi veliki writeback burst. swappiness je 10. vfs_cache_pressure je 50, a min_free_kbytes 65536. Ne pokušavam da od virtuelne memorije napravim neki magični audio engine. Samo želim da filesystem, disk i swap ponašanje budu predvidivi. kernel.timer_migration Ovo je ispalo zanimljivo kao mali eksperiment. Pre promene: kernel.timer_migration = 1 Promenjeno je na: kernel.timer_migration = 0 Ideja je bila da se smanji nepotrebno premeštanje timer aktivnosti između CPU jezgara. Posle promene nisam dobio nikakav čujni šum niti neki čudni artefakt. Zvuk se normalno pojavljuje tek kada pritisnem play. Dakle za sada ostaje 0, ali ga ne proglašavam za "audiofilski tweak koji menja zvuk". Ako nema problema, to je samo jedno malo scheduler podešavanje koje ostaje jer nema razloga da ga vraćamo. THP Transparent Huge Pages trenutno nisam dirao. Stanje je: enabled: always [madvise] never defrag: always defer [defer+madvise] madvise never Aktivni izbor je madvise. Neću da stavljam transparent_hugepage=never samo zato što može. Ako je sistem već u razumnom default režimu, nema potrebe da pravimo još jednu egzotičnu intervenciju. Šta sam namerno izbacio iz starog sistema Ovo je možda čak važnije od onoga što je ostalo. Stari sistem je imao dosta agresivnija podešavanja. Neka su imala smisla u određenom kontekstu, neka su verovatno bila ostavljena iz ranijih eksperimenata, a neka su jednostavno bila tipični Linux low latency recepti. Sada ih ne prenosim automatski. Na primer: net.ipv4.tcp_low_latency = 1 nije audio tweak. Isto važi za ogromne TCP buffere, razne RPS/XPS kombinacije, usbfs_memory_mb, nrpacks, implicit_fb, forsiranje HPET-a i slične stvari. Naročito nisam preneo stari: vm.dirty_bytes = 335544320 vm.dirty_background_bytes = 167772160 samo zato što je ranije bio podešen. Kod novog sistema svaka takva stvar mora da ima razlog. Ako nema jasnog mehanizma koji povezuje podešavanje sa konkretnim problemom, ne ubacujem ga u image. To je i razlog zbog kog nisam krenuo da ubacujem isolcpus, nohz_full, rcu_nocbs, PREEMPT_RT, pcie_aspm=off i još dvadeset stvari samo da bi konfiguracija izgledala "realtime". Na četiri jezgra svaka takva intervencija ima cenu. Nije poenta da napravimo sistem koji je realtime na papiru, a onda pola mašine sedi u ćošku i čeka. Kako je proveravan konkretan audio lanac Nije ostalo samo na konfiguracionim fajlovima. Proveravan je sam USB uređaj: Amanero Combo384 16d0:071a USB 2.0 High Speed Proverena je USB topologija. Amanero je na bus 1, port 3, na xHCI kontroleru, zajedno sa ostalim USB uređajima. Proveren je snd-usb-audio modul i njegovi stvarni runtime parametri. Proveren je PipeWire node. Proveren je ALSA uređaj. Proveren je stvarni PCM status dok playback radi. Tokom reprodukcije ALSA pokazuje: state: RUNNING i konkretan owner PID procesa koji drži uređaj. Provereni su i hw_params i sw_params. Playback trenutno radi sa 48 kHz, S32_LE, stereo, periodom 512 i bufferom 32768. To je mnogo korisnije od još jednog posta sa screenshotom gde piše "Low Latency: ON". Šta je cilj ove automatizacije Najvažnije je da sada mogu da razlikujem tri stvari. Prvo, ono što je stvarno deo sistema. Drugo, ono što je samo staging. Treće, ono što je backup ili test. root-mx25 predstavlja stanje filesystema iz kog pravim image. iso-work predstavlja staging za konkretan ISO. kernel-backups i boot-backups čuvaju prethodna stanja. Skripte određuju kako se od toga dolazi do konačnog ISO-a. To znači da mogu da promenim jednu stvar, napravim ISO, testiram ga, vratim backup ako treba i ponovo napravim image bez ručnog rekonstrisanja celog postupka. Kako će se dalje raditi Od sada neću više kačiti nasumične izmene po sistemu. Ideja je da svaki novi tweak prvo bude: stanje ↓ hipoteza ↓ test ↓ meren rezultat ↓ odluka Ako nešto nema merljiv efekat ili postoji samo kao "audiofilski savet sa foruma", ostaje van image-a. Za svaki ozbiljniji problem prvo gledam konkretan lanac: player ↓ ALSA ↓ snd-usb-audio ↓ USB isochronous transfer ↓ xHCI IRQ ↓ scheduler a ne menjam deset parametara odjednom. Ako se pojavi xrun, klik, USB reset ili neki drugi problem, tražiću uzrok u tom lancu umesto da naslepo menjam scheduler. Šta kačim dalje Kao i do sada, krajnji rezultat za korisnike ostaje diya.iso. ISO ću i dalje postavljati na isto mesto gde je do sada postavljan, sa informacijama o verziji, veličini i MD5 kontroli, tako da se način preuzimanja za korisnike ne menja. Dakle, kada je nova verzija gotova, glavna stvar je i dalje: diya.iso GitHub uvodim kao razvojni deo projekta. Tamo mogu da budu javno dostupne build skripte i konfiguracije, pre svega: build.sh update-kernel.sh ovo.sh qemu.sh kao i dokumentacija i konfiguracioni fajlovi koji su potrebni da se vidi kako je sistem napravljen. Neću tamo kačiti kompletan root-mx25, iso-work, kernel-backups, boot-backups i ostale radne fajlove. To su lokalni build environment, staging i backup. Drugim rečima: GitHub ↓ build skripte + konfiguracija + dokumentacija ↓ diya.iso ↓ korisnik skida i testira Ako neko hoće da vidi kako se sistem pravi, može da pogleda skripte. Ako hoće samo da proba sistem, skine diya.iso. albumplayer Album Player для Linux ALBUMPLAYER.RU je ugrađen u distribuciju kao pre zadnja verzija. Kačim uskoro ISO.....

to je to

radim remiks ovoga sad... Edgar Fose seo i uradio pratnju

ovo je sad neprolazni klasik u odnosu na danasnji AI šund

Intelligence on a Payment Plan MEDIUM.COM

Superinteligencija ne može da živi u chatu – Mikorist MIKORIST.COM Par dana sam radio nešto sasvim obično. Android kernel. Fajlovi, boot image, ramdisk, BusyBox, ADB, DTB, malo kompajliranja i mnogo gledanja u terminal. AI je b Ovde pišem o ličnom primeru sa AI. Radio sam običan android kernel . Nije mogao da se seti šta smo juče radili u 17h. I tu dolazimo do kenjatora Sam Altmana lično...... On priča o AGI-ju, superinteligenciji i sistemima koji će raditi sve više stvari samostalno. Več sad. Dobro. Ali onda dolazi najobičnije inženjersko pitanje: Gde je taj sistem? U chatu? U API pozivu? U kontekstu od nekoliko hiljada ili nekoliko miliona tokena? Ili negde iza toga postoji potpuno drugačija infrastruktura koju mi kao korisnici uopšte ne vidimo? Ako postoji, onda je upravo to zanimljiva stvar. Jer chatbot nije superinteligencija. Chatbot je prozor. Ne znam šta je iza tog prozora. Ali znam da kroz ovaj prozor ne možeš da vodiš kontinuitet ozbiljnog rada. I još traže pare.....

Hahaha, da. Tablet sve vidi i čuje na obe kamere i mikrofonu.... Kad čovek krene da čačka Android na tom nivou, odjednom shvati da telefon nije baš "operativni sistem sa par aplikacija", nego mali grad sa pola stanovništva koje niko nije pitao da se doseli. I ono što je najgore, veliki deo toga nije ni klasičan malware u fazonu "virus". Mnogo je perfidnije. Sistem ima servise, framework komponente, vendor dodatke, telemetriju, proprietary biblioteke, reklamne SDK-ove, kineske servise koji se podignu pre nego što korisnik uopšte vidi launcher. Pa onda aplikacija dobije dozvolu, servis dobije dozvolu, sistemski paket dobije pristup, a sve zajedno izgleda kao normalan Android. Kad krenemo da gledamo sve programe fabričke onda se lepo vidi koliko toga zapravo nije potrebno da bi tablet radio. Nije samo "stavio sam drugi ROM da tablet bude brži". U suštini rastavljaš ceo lanac: bootloader * kernel* vendor * Android framework * system apps * Google/third party servisi * aplikacije I na svakom nivou može da postoji nešto što služi nečemu što korisnik nikada nije tražio. Samo gledaš šta se izvršava, šta otvara socket, šta pravi DNS upite, koji proces ima pristup čemu i kome telefon pokušava da se javi. strace, logcat, dumpsys, ps, /proc, iptables/nftables, DNS logovi i malo strpljenja. I onda dobiješ ono čuveno: "Zašto moj tablet priča sa ovim serverom u Kini?" A tablet ćuti. Kao svaki dobar osumnjičeni. proces ko ga je pokrenuo koje dozvole ima koje DNS upite pravi na koje IP adrese ide šta šalje da li je Google / reklama / analytics / nešto treće I tu stvari postanu baš zanimljive. Znaju gde si kupovao skim si u krevetu šta pričaš i sve ide kroz AI obradu i onda cepaju temu reklame... ako im treba nešto za partiju to ide posebno u CK

Ovaj tablet je star oko 11 godina. Umesto da završi u fioci, rešio sam da vidim koliko još života može da se izvuče iz njega. Danas radi kao IP kamera, kojoj mogu da pristupim preko MikroTik VPN-a sa telefona ili računara, a istovremeno služi i kao mrežni sat. Kamera nije izložena direktno internetu. Tablet je na lokalnoj mreži, MikroTik je VPN kapija, a sa druge strane mogu da se povežem praktično odakle god imam internet. I tu bi priča mogla da se završi kao sasvim pristojan projekat reciklaže starog hardvera. Samo što nije. Zbog problema sa kamerom i starim Androidom završio sam u APK-u, ADB-u, MTKClient-u, eMMC-u, GPT-u i ručnom upisu na 0x00000000. Napravljen je kompletan backup svih particija, tako da sada postoji i način da se uvek ceo uređaj vrati u trenutno funkcionalno stanje. Ukratko, od tableta starog 11 godina napravio sam kameru, sat i mrežni uređaj, a usput mu uradio praktično mali servisni remont na nivou firmware-a. Nije loše za uređaj koji je trebalo samo da pokaže koliko još može da izdrži. Hahaha. Tablet ne mora da bude javno dostupan na internetu. Na njemu radi IP Webcam i kamera je dostupna preko njegove lokalne IP adrese. MikroTik je ulazna tačka. Kada se telefon ili računar poveže na MikroTik preko VPN-a, uređaj praktično dobija pristup mreži u kojoj se nalazi tablet. Zato telefon može da otvori kameru kao da je kod kuće: telefon ↓ VPN ↓ MikroTik ↓ tablet ↓ IP Webcam ↓ kamera A isto važi i za laptop ili bilo koji drugi uređaj koji ima VPN klijent: Laptop ── VPN ──┐ │ Telefon ── VPN ─┼── MikroTik ── Tablet ── Kamera │ PC ─────── VPN ─┘ Najlepši deo cele priče je što kameru ne izlažeš direktno internetu. Nema potrebe da otvaraš port za IP Webcam prema celom svetu. VPN pravi privatni put do tvoje mreže, a onda kamera ostaje običan uređaj unutar LAN-a. Gomila fajlova i podešavanja NA kraju je špijunska sorava isapla. Gledaš u sat koji je istovremeno i nadzorna kamera. WireGuard VPN-a na MikroTiku. Kada se telefon poveže na WireGuard, ponaša se kao da je na kućnoj mreži, pa direktno pristupa kameri na tabletu. Nema javnog otvaranja porta za samu kameru. Znači: telefon → WireGuard → MikroTik → tablet → kamera. Tablet tako može da bude dostupan spolja, a da sama kamera ostane iza rutera. Pet dana posla.... Da na kraju napraviš infrastrukturu za oporavak uređaja vrednog verovatno manje pakovanje grisina.

Prednjače.... jbga Nego........ Realno, programeri su psihički pukli sa AI. Masa programera po Americi, Evropi i svugde naterana je od poslodavaca da koriste AI agente koji greše i brljaju. Dolaziš u situaciju da pojma nemaju šta je promenjeno i šta se uopšte debaguje. Jednom rečju, kad krenu da se ruše avioni, kamioni i sve zbog softvera, neće znati ko je kriv. Čovek će reći da je AI zajebao, a AI da je čovek, i jebiga. A na sudu se AI ne može pojaviti. Hihihi. Horor. Sećam se kad su svi govorili „naučite da kodirate“. Nikad nisam mislio da ćemo doći do ovoga. Da, samo naučite da programirate i to je to. A sad jok. Ama prsavela. Sad će da bude samo „naučite da pišete promptove za AI“. Hahahaha. Ono pred ukidanje čoveka. U suštini to je cilj NSP i AI Zveri – da se čovek izbaci iz svake odluke i da sve mašine odlučuju. Kao u Star Treku, ako se sećate Borga. Hahaha. To je to. Resistance is futile.

hahahahahah to je to

reprogramirao sam tablet u pametan sat. samo to mu je funkcija. 0-24 pokazuje vreme . na punjaču stalno. vreme i najava vremena...neka starudija iz 2015 diže se posle rebuta direktno u sat sad. verovali ili ne 2 dana zanimacije da se počisti sve. jbt zastareli android 5

Narodnjak prebaciš u džez. Suno za četiri sekunde napravi celu pesmu, aranžman i orkestar. 2026. godina. Ovo više nije ni mnogo smešno.

Inspiracija su bile teme zadnje na forumu

Jbt koji vokal. Ko Svetlana Stević +Divna zajedno

Baš nas briga sve dok je zabavno .

Moj AI nema jedan prompt. Ima operativni sistem. – Mikorist MIKORIST.COM Ja prvo moram da objasnim kako uopšte koristim AI. Zapravo, izgleda potpuno drugačije od onoga kako većina ljudi zamišlja da radi. Kada ljudi kažu "napravi

Ako me jednog dana ne bude na forumu... ...nemojte odmah da pomislite da me je banovao moderator. Možda me je banovao moj AI. Kaže: "Odgovor odbijen. Korisnik nije prošao Anti-miris.md."