Názory k článku
AlpineBSD je operační systém s důrazem na software bez AI
-
To je ale tím, že nevím jestli většina ale ano, velká část lidí věci často jen naprasí. LLM píší dost průměrný kód a často mě překvapuje, jak ošklivý i od vlajkových modelů je. Tedy alespoň z mého pohledu. Na druhou stranu často mě překvapuje, jak ošklivý je od lidí, které jinak považuju za dost schopné. Vyjde to tak nastejno.
-
ano, a pak na revizi kódu hodit další revizi a nad to další. Nedávno se Anthropic pochlubil, že mají snad 8 úrovní než to jde člověku. To pak už ty ceny jsou dost vysoko.
Ty revize nejsou bezchybné, ty modely se umí navzájem manipulovat a obelhávat, relativně efektivně se tím dají chytat očividné chyby, ale jak třeba chytat uhnutí od zadání nebo příliš komplexní řešení na jednoduchou funkci? Ty modely nemají dostatečný cit a často se více řídí komentáři než kódem samotným.
-
Většina lidí pokoušejících se dnes programovat by se také měla raději věnovat něčemu, na co stačí jejich schopnosti. Nepovažuji se za kdo ví jakého hackera, ale ještě se mi nestalo, že by LLM vyprodukoval lepší program, než bych napsal já. A to jak v rovině implementační, tak algoritmizační. V obou případech chodí LLM snad vždy s kanónem na vrabce a nepodaří-li se mu to vypálit na první dobrou, zamotá se do toho. Obrovská výhoda LLM je, že to udělá rychle. Také je to použitelné na rešerši - najde některé chyby. Ano, používám LLM, ale spíš jen jako sofistikovaný vyhledávač a prototypér a pak následně na code review.
Tvorba software prodělala během posledních 30-40 let proces neuvěřitelné laicizace a amatérizace. Nechci nikomu upírat právo programovat - stejně, jako se každý může kurýrovat, trénovat a stravovat, jak uzná za vhodné. Ale katastrofa nastává, když takovíto amatéři-nedouci propadnou dojmu, že už umí dost na to, aby se tím mohli živit a prodávat své služby a výtvory za peníze. Opravdu žasnu čím dál více, co všechno dnešní vývojáři nevědí a na co nestačí - s rostoucím datem narození je to obecně horší a horší, přičemž nepozoruji, že by jejich chybějící znalosti a dovednosti byly nahrazeny nějakými jinými. Kdo by se nechal operovat kardiochirurgem - amatérem/samoukem...? Ve světě software dnes naprosto běžný, vlastně standardní jev. Obávám se, že s masivním nasazováním LLM při tvorbě software bude postupně extrémně narůstat zbytečná složitost programů, jak se budou novější modely učit z korpora kódu, v němž bude stále více zastoupen generovaný kód.
-
> V obou případech chodí LLM snad vždy s kanónem na vrabce a nepodaří-li se mu to vypálit na první dobrou, zamotá se do toho.
S tím souhlasím a je potřeba to hlídat. Ale když se to hlídá, tak z toho leze celkem solidní kód (konkrétně mám vyzkoušeno s Opus 5.5).
> Obávám se, že s masivním nasazováním LLM při tvorbě software bude postupně extrémně narůstat zbytečná složitost programů,
To už se bohužel děje.
Na druhé straně si ale myslím, že to dokáže spousty práce ušetřit. Takže nevidím důvod, proč bych se takového nástroje úplně vzdával. Díky tomu mi pak zbývá více času na nejdůležitější části programu. Nebo díky tomu mohu programy více vyladit, aby se uživatelům lépe používaly a lépe vypadaly.
A pak mě ještě napadá, že pokud lidé píší tak dobrý kód, tak proč LLM nachází v poslední době tolik bezpečnostních děr?
-
Já právě netvrdím, že "lidé píší tak dobrý kód". Tvrdím, že někteří lidé píší tak dobrý kód. Průměrný kód je dost mizerný. Proto ani to, co vypadne z LLM, nemůže být kdo ví jaké.
Ano, LLM nachází spoustu chyb. A spousty chyb si nevšimne. Nezavrhují LLM, vždyť to sám při vývoji používám. Ale není radno v tom vidět nějaký všespásný nástroj. Lidé se na to velice rychle začínají až příliš nekriticky spoléhat - a to je velice nebezpečné. Většina lidí neumí ani správně naformulovat prompt a nedokáže rozpoznat chybu či halucinaci. Přitom snad každá odpověď LLM obsahuje nějaké procento nepřesností či halucinací - při nesprávném promptu to může být z větší části halucinace.
-
Jenže v jednom případě jde o mechanickou činnost, zatímco v druhém případě o činnost kreativní, vyžadující invenci. V účetním přirovnání je rozdíl v kvantitě. Asi jako mezi sčítáním a numerickou integrací. Ale mezi sčítáním a Newtonovu formulí je dost zásadní kvalitativní rozdíl, který žádnou kvantitou nelze překonat. Někdo musel přijít na to, že nemusím tupě sčítat tisíce a miliony čísel, že k absolutně přesnému výsledku se dostanu krátkou posloupností početních triků.
LLM při programování postupují šablonovitě, mechanicky. Spousta lidí také - ale jak jsem napsal výše, to proto, že spousta - nejspíš většina - současných vývojářů na to ve skutečnosti nemá mentální předpoklady. Dělají práci, na níž intelektuálně nestačí, a hardware, frameworky a nově LLM to maskuje. Dlouho se tvrdilo, že čas vývojáře je drahý oproti železu. Jenže - když si vynásobíme neefektivně napsaný program miliony mobilů, tak už nám ta zbytečně promrhaná elektrická energie a spotřebovaná RAMka začne naskakovat do nezanedbatelných objemů. Což s LLM dostává zcela nové dimenze. -
L.Stříbrný podporovatel
U mě třeba LLM použije nějakou vlastnost technologie / knihovny / ... o které jsem nevěděl a tím řešení zjednoduší, odchytá corner cases, atp. Tomu se dá říkat lepší kód.
Backendisti u nás ho používají na optimalizaci existujících služeb a mají docela dobré výsledky, takže i pro efektivitu je LLM může být LLM užitečné.
Na druhou stranu ano, kreativní není vůbec.
9. 11. 2026, 23:11 editováno autorem komentáře
-
s rostoucím datem narození je to obecně horší a horší
Není to tak ani zdaleka vždy. Můj učitel programování (programujeme v C#) se doslova na všechno ptá AI a ve výstupu nenajde chybu, kdežto já (asi o 30 let mladší) jsem tu chybu našel (výstup měl jenom dva řádky, proto tam byla jen jedna chyba, jinak by jich tam logicky bylo víc).
Mimochodem, řekl bych, že problém není 100% v nás (mladších generacích), ale částečně i ve výuce (zmíněný učitel programování si myslí, že budeme opisovat kód z tabule a klikat tam, kam kliká on, takže na to samozřejmě všichni kašlou, ale když jsme měli učitele, který nás kód nechal vymyslet, tak bylo alespoň o jednoho, kdo zadání důsledně vypracovával, více (tím myslím sebe)).
-
Samozřejmě, že je chyba i ve školství a nedostatečné kvalifikaci učitelů - který kvalifikovaný odborník by to za těch dnešních podmínek a za ty peníze dělal... Ale když někdo jen pasivně čeká na to, co mu řeknou ve škole, nemůže očekávat, že to odborně někam dotáhne. Jenže na těchto "odborně nedotažených profesionálech" je dnes založeno celé IT. A z jejich práce se učí LLM. Není přece normální, aby ta nejobyčejnější kalkulačka v mém mobilu měla 6,5 MB.
-
Kvalitne napísaná kalkulačka mi vyšla v x86_64 assembly na 11 kB skompilovaná.
https://pastebin.com/SBWTwzqaNekvalitné kalkulačky nenapísané v assembly bývajú väčšie.
-
A tohle je, milé děti, důvod, proč se tyhle věci nemají psát v assembleru:
A quality calculator has one job above all: never give a wrong answer without saying so. This one breaks that in several ways:
Wrong answers with no warning. Add, subtract and integer parsing all wrap around on overflow without any signal. A user gets a plausible-looking wrong number.
It can crash. A large multiply or divide ends in SIGFPE with no message.
It accepts nonsense. abc is 0, 3,5 is 3, 2+3 is 2, and dividing by zero just reprints the old value.
It loses your work. Pressing Enter on an empty line resets the accumulator to 0.
Likely output defect. The probable stray NUL byte after each integer would corrupt piped output. -
@Ink
Ok, moje assembly skills sú naprd. Len to som chcel predrečníkovi straw manom ukázať, že 6,5 mb kalkulačky sú veľké kvôli vrstvám rôznych závislostí.Nedávno som si robil zo srandy program na prehliadanie grafov z garmin .fit súborov pre pc xt s Ega a mal 68kb prosím, napísaný s pre watcom C. Na linux tam už išli rôzne vrstvy a nabalovalo sa to. Ale akosi to nevadilo, lebo teraz počítače nemajú 64O kb RAM.
-
Kvalitně napsaná kalkulačka má kolik MB?
Podobná aplikace v GEOSu na Commodore 64 měla asi tak 3 KB a běžela na CPU taktovaném na 1 MHz. Ta v mobilu toho ani neumí 2000krát víc, ani není 2000krát lepší. Troufám si i tvrdit, že nebyla ani vyvinutá 2000krát rychleji a levněji. Největší rozdíl je prakticky jen v tom, že ta dnešní aplikace zabírá 2000krát více paměti. Ne 20krát. Ne 200krát. Ale 2000krát! A k běhu potřebuje gigahertzový procesor.
Aplikace na internet banking má 130 MB, jak tak koukám. Vůbec by se nevešla na hard disk mého prvního PC.
Jestli tohle někomu připadá normální a v pořádku, tak asi opravdu žiju ve světě bláznů.
-
"Jestli tohle někomu připadá normální a v pořádku, tak asi opravdu žiju ve světě bláznů."
Slovo normalni je definovane jako neco co je normou tzn. je to bezne, caste, obecne prijimane. Tedy ano je to normalni uz proto jak je to slovo definovane. Mit kalkulacku ktera ma 3KB z tohoto pohledu dnes neni normalni.
Jestli je to v poradku je uz vice subjektivni nazor, tam zalezi na tom podle ceho to hodnotite. Moje oblibena kalkulacka RealCalc v mobilu zabira 6.59MB. Za tu co je v GEOSU nebo tu co napsal balkovic vyse bych ji nerad menil. A pri ulozisti 256GB a RAM 8GB zabira relativne mene zdroju nez ta GEOS kalkulacka. A ten mobil me stal mene (cca 6 tisic) nez zaplatili rodice za muj Commodore 64 (cca 10 tisic Kčs) a taky ma ten mobil mensi spotrebu elektriny a je mnohem mensi. Takze za me je to celkem v poradku.
-
Takze za me je to celkem v poradku.
Slovíčkaření na téma normalita považuji za úplně zbytečné - většina snad pochopila (vybral jste si jeden z více možných významů, v tomto kontextu zrovna ten nevhodný).
Jak říkám - tohle je prostě úplně jiné morální/hodnotové nastavení mysli. Mně se zkrátka příčí přístup, že něčím budu úmyslně plýtvat jen proto, že mohu. A - jak už tu naznačil martinpoljak - udivuje mě, že ti, kteří to plýtvání reálně zaplatí, to ještě rádi udělají, protože přece relativně je to lepší, než to bývalo. Ten skrytý astronomický nepoměr je jaksi pod jejich rozlišovací schopnost.
(...a pak mě ta samá banka, co mi cpe 130MB appku, při každé příležitosti buzeruje kvůli uhlíkové stopě.)
-
Aby som pravdu povedal, je to stále zhruba rovnaké :) Ľudia kašlali na best practices a znalosti múdrejších ľudí pred 30-40 rokmi rovnako, ako teraz. Videl som už veci aj z tých čias, čo poviem.
Len teraz je to o to horšie, že tie znalosti sú ľahko dostupné a aj tak sa prasí. Aj rôzne vzdelanie tejto oblasti sa dá získať. Vtedy boli všetci samouci, to ich ospravedlňuje.
-
prakticky to ale není pravda. Zdaleka nejde jen o kód, ale i o jeho záměr, přehlednost, udržovatelnost, strukturu, množství. LLM tam rádi dělají kdejaké funkce navíc, nedrží se striktně zadání atd.
Na co mi je skvělý kód, když jsou schopní implementovat debug funkci tak, že se přidá argument a zpátky se vrátí interní data včetně hesel? Kód je bezchybný, jen selhala logika.
Udržovatelnost kódu v LLM dnes skoro neexistuje (ne za rozumné náklady). S každou další úpravou přibývá množství chyb, které udělá a velmi rychle tím předhoní i průměrné vývojáře. Protože se prostě nebojí dokončit práci z půlky a označit jí za hotovou.
Tím neříkám, že rozumím co AlpineBSD bude dělat. Ještě jsem ani nekoukal, kdo za tím je.
-
> když jsou schopní implementovat debug funkci tak, že se přidá argument a zpátky se vrátí interní data včetně hesel?
me pobavilo ze si AI udelala skript na checkovani dokumentace a commit commentu aby tam nebyly soukrome udaje (mac adresy, jmena , nektere klicove slova) a pak ten skript commitla normalne do toho repa, ktere se melo checkovat i s temi vsemi privatnimi vecmi uvnitr toho skriptu, vsiml jsem si toho az za nejakou chvili.
-
ano, to jsou naprosto běžné podlosti.
V jiném případě, kdy jiný LLM agent měl dělat kontroly na tyhle úniky a měl to vracet zpátky, tak vývojový LLM našel kličku, zrovna mu totiž nefungoval správně vault a potřeboval ten secret token někam uložit, tak ho sice strčil do kódu, ale do komentáře nad to napsal, že to není secret, no a ono mu to prošlo validací!
Nejsem výhradně pro LLM kódu, ale je mu potřeba dávat stejnou péči jako jinému kódu. Stav, kdy kód přestanu kontrolovat, protože ho je hodně, je absurdní. S kódem jde odpovědnost. Ve fyzickém světě také nemohu stavět jeden domek za druhým s rizikem, že to na někoho může spadnout, protože občas třeba zapomenu použít betón, že jo.
Jak to ale uměle zpomalit? Testujeme variantu, kdy kód pořád píše člověk, ale AI mu k tomu dělá nápovědu, oponentůru a radí. Důležitý je ten rozdíl. Omezí se tak přirozeně množství kódu, programátor má čas se nad tím zamyslet, rozhodnout. Dlouhé čtení kódu velmi rychle člověka otupuje.
-
Sice mi to také přijde jako nesmysl, ale generovaný kód jen testovat a kontrolovat je o dost náročnější než ho tvořit; je to mnohem otravnější práce. Něco jiného je dělat celý vývoj ale izolovaně by to byl fakt hnus. Takže platit budete muset, lidé, které vývoj baví ji chtít dělat obecně moc nebudou a dobrovolníků bude pomálu.
-
Josef MarianekBronzový podporovatel
No ja jsem zkousel cursor a dopadlo to docela dobre, ujplne obslehl muj styl vcetne komentaru. Nebylo to teda moc slozite. Pak jsem videl od kolegu zasahy pomoci claude (nekteri na nej plivou, pry je moc kreativcni a nespolehlivy, na rozdil od open ai), a uz jsem to jen zbezne prohledl. Tech zasahu proste bylo moc. Podle me zbyva, a na linux days o tom nekteri mluvili, to nechat LLM i zkontrolovat, tj. otestovat, vcetne agentu co nesou znalosti firmy (pry na to jsou nastroje). Proste se to stane autonomnim procesem.
Pripadne me, ze se dostaneme do situace jako kdyli s asemblerem, kdyz prisly vyssi programnovaci jazyky. Dnes uz malo kdo pise v asembleru a malo kdo se v nem chce hrabat. Mozna se jednou nebude chtit nekomu hrabat v kodu ve vyssim prog. jazyce, lepsi bude promptovat se spolehlivym LLM. Lidi co budou umet vyssi jazyky tim padem bude zase min. I kdyz ja teda razim princip, ze je pptreba mit nad LLM navrch, tj. rozumet technologii co pouziva. Do budoucna nevim, jak to s timto mym pozadavkem bude...
-
> I kdyz ja teda razim princip, ze je pptreba mit nad LLM navrch, tj. rozumet technologii co pouziva.
To tehdy rikali i ti lidi s assemblerem. Tak nejak jim cas nedava za pravdu. I kdyz kdyby nezvniklo Ai, tak bybyla za par let legrace pozorovat nabidku/poptavku po ASM expertech. Myslim ze v porovnani s tim by COBOL "problem" byl uplne zanedbatelny.
Jeste vyse kdosi napsal:
> Nepovažuji se za kdo ví jakého hackera, ale ještě se mi nestalo, že by LLM vyprodukoval lepší program, než bych napsal jáS tim souhlasim. Ale dodal bych podminku: A rychleji? protoze AI sice pise Nkrat horsi kod nez "mi" ale N lezi nekde v 2-10. Ale pise ho 100-1000x rychleji.... Ted je otazka co vydela:( na dlouhej beh to prvni. Ale....
-
prošel jsem, kdo zatím stojí, je to Drew DeVault, což není zrovna začátečník. Vybudovat SourceHut, je dlouhodobý přispěvovatel do alpinelinux, vytvořit sway nebo wlroots (wayland ekosystém), zkusil si i tvorbu programovacího jazyka (Hare). V open source je dlouho a je to schopný vývojář a schopný manažer.
Z tohoto pohledu má šanci, že to uspěje, ale za mě to má velmi málo výhod, jestli hlavní "funkce" má být no AI, je to za mě na rozšíření málo. Už teď to zakládá na NetBSD, což je něco, kde je AI také asi dva roky na blacklistu a mají velmi silný vývojový cyklus, nepříjímam bloatware od AI jen tak.
Subjektivně mám alpinelinux velmi rád, je to příjemný OS, pokud alpineBSD jenom ho zmigruje na NetBSD a zbaví se linuxu, palec nahoru a určitě to budu zkoušet. Nedokážu si představit, ale kdo bude udržovat balíčky, přeci jen busyBox nějaké rozdíly dělá, aspoň, že zachová netbsd libc.
ČLÁNKY DO MAILU