Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Právě vyšlo Sane software manifesto verze v0.8. Manifest se zabývá tím, jak psát příčetný software s ohledem na práva uživatelů, ochranu soukromí, svobodu, bezpečnost a dlouhodobou udržitelnost. Před vydáním verze v1.0 je ideální čas k zasílání komentářů a poznámek do e-mailové konference.
Tiskni
Sdílej:
8.10.2019 12:17
xkucf03 | skóre: 49
| blog: xkucf03
Když si dáš na svůj web svoji fotku, adresu, telefonní číslo… tak to taky může kdokoli číst nebo „těžit“. Je to veřejná informace, proto ji tam dáváš.
Pokud má být něco neveřejná informace určená jen nějak definované skupině příjemců, tak tam je správným řešením kryptografie. A ne se spoléhat na to, že nějaká firma typu Facebook bude slušná a nebude prodávat tvoje data. Ostatně třeba při přístupu do banky se taky nespoléháš na to, že budou všichni dodržovat telekomunikační tajemství, ale raději použiješ kryptografii, ne?
Ostatně třeba při přístupu do banky se taky nespoléháš na to, že budou všichni dodržovat telekomunikační tajemství, ale raději použiješ kryptografii, ne?Pro přístup do banky používáš kryptografii úplně stejně jako pro přístup na Fakezoob a úplně stejně také bance důvěřuješ, že nebude zneužívat informace o tom, kde nakupuješ a zakolik etc. Jediný rozdíl je, že banky mají víceméně slušnou reputaci (víceméně).
9.10.2019 11:10
Fluttershy, yay! | skóre: 93
| blog:
Jediný rozdíl je, že banky mají víceméně slušnou reputaci (víceméně).Ehm. Wells Fargo isn't the only bank with fake accounts, regulators say
"Když se ten Hitler neosvědčí, budeme příště volit někoho jiného."Problem v tomhle vyroku je v tom, ze Hitler volby zrusil a tim znemoznil korekci situace - volit nekoho jineho uz nebylo mozne Ty to ale porovnas s mym vyrokem, ale ja nevidim, jak mi muze MS (po zblazneni) znemoznit si git repozitar vzit a hostovat jej nekde jinde. Ty vyroky jsou porovnatelne jen velmi povrchne.
8.10.2019 11:22
xkucf03 | skóre: 49
| blog: xkucf03
ale ja nevidim, jak mi muze MS (po zblazneni) znemoznit si git repozitar vzit a hostovat jej nekde jinde
Už se to děje – říká se tomu síťový efekt a vendor lock-in. Je to jako když někdo kouří nebo bere drogy a tvrdí ti, že může kdykoli přestat, když bude chtít (jenže on nechce, protože je závislý).
Proto je žádoucí, aby ti, kdo mají dostatek síly s tou závislostí skončit, s ní skončili, a pomohli tak i ostatním.
Jestli chceš pomáhat nebo jestli se chceš jen vézt a jít tou nejsnazší cestou, je tvoje věc a samozřejmě tě k tomu nemůže nikdo nutit.
9.10.2019 14:29
Fluttershy, yay! | skóre: 93
| blog:
Winston Churchill jako premiér britské vlády přišel na interpelaci do sněmovny v povznesené náladě. Poslankyně Philipsová, která jej neměla příliš v lásce, předstoupila před jeho křeslo a důrazně pronesla: "Pane předsedo, vy jste opilý. Vy jste hrozně opilý. Pane předsedo vy jste hrozně moc opilý." Churchill se s pomocí sněmovního butlera postavil a odpověděl. "Paní poslankyně, vy jste ošklivá. Paní poslankyně vy jste moc ošklivá. Paní poslankyně vy jste strašně moc ošklivá!" A mávaje svým velkým doutníkem, dodal se smíchem: "Já se z toho ale do rána vyspím!"
9.10.2019 17:42
Fluttershy, yay! | skóre: 93
| blog:
8.10.2019 12:09
xkucf03 | skóre: 49
| blog: xkucf03
A prave proto me ta centralizace desi, protoze sabotaz githubu muze dynamiku opensource komunity vratit o dekadu zpatky.
Tomu se říká uváznout v lokálním maximu. První krok je si uvědomit, že ten problém existuje – spousta lidí to ani netuší a vesele používají něco, co je dlouhodobě poškozuje. Ty si jsi aspoň vědom toho, že tu nějaký problém a nebezpečí je. Proto je potřeba o tom mluvit a rozšířit to povědomí i mezi ostatní. Psal jsem o tom i v nedávném článku (čtvrtý bod odshora).
8.10.2019 12:03
xkucf03 | skóre: 49
| blog: xkucf03
Gnome si netroufám hodnotit, nepoužívám ho.
U Firefoxu je to dané víceméně tím, že dnešní webové technologie jako takové jsou nepříčetné a vyžadují nesmírnou komplexitu. Takže pokud je chce někdo implementovat, zákonitě to vede na komplexní software. Řešitelné by to bylo skrze modularitu a možnost si z toho vybrat jen některé moduly, které člověk chce používat.
Linux by příčetný být mohl.
8.10.2019 12:19
xkucf03 | skóre: 49
| blog: xkucf03
Ale změnit to je jen formalita, nic tě to nestojí.
A pokud někdo není schopný říct, zda jsou dvě verze kompatibilní nebo ne, tak je to sice trochu smutné, ale může vždy povyšovat major verzi a ten požadavek splní.
8.10.2019 21:21
xkucf03 | skóre: 49
| blog: xkucf03
Vyzadovani semantickeho verzovani u uzivatelskeho software povazuji za blbost - co vubec ma znamenat kompatibilita dvou verzi v UI? Je posunuti buttonu o 10px nekompatibilni zmena?
Nekompatibilní změna je třeba odebrání funkce nebo zásadní překopání GUI, které se pak uživatel musí znovu učit. Nebo když mi ve www prohlížeči přestanou fungovat pluginy, které do té doby fungovaly, že…
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
:p 
Nekompatibilní změna je třeba odebrání funkce nebo zásadní překopání GUI, které se pak uživatel musí znovu učit.To je ale trochu nepresna definice, ne? Zmena UI muze byt cokoliv od zmenu ID elementu (rozbije selenium testy), posunuti o 10px (pro autisty breaking change), zmenu defaultni klavesove zkratky, prepracovani settings dialogu, zmenu ikonek ... az po kompletni prekopani filozofie GUI. Co je pro tebe "kompatibilni" zmena nemusi byt pro jine a naopak.
Nebo když mi ve www prohlížeči přestanou fungovat pluginy, které do té doby fungovaly, že…Pred verzi 57 se stavalo prakticky v kazde verzi, ze se dost pluginu rozbilo. V 58 a vys je to lepsi, ale presto se najdou problemy. Ale tak v pripade prohlizecu (FF, Chrome atp.) je to stejne jedno, jelikoz jsou to ted zarne priklady spravne pouziteho semver.
8.10.2019 21:22
xxx | skóre: 42
| blog: Na Kafíčko
8.10.2019 21:43
xxx | skóre: 42
| blog: Na Kafíčko
8.10.2019 22:11
xxx | skóre: 42
| blog: Na Kafíčko
9.10.2019 11:31
xxx | skóre: 42
| blog: Na Kafíčko
. Tak to jo. S takovymhle pristupem funguje uplne cokoliv.
9.10.2019 12:12
Gilhad | skóre: 20
| blog: gilhadoviny
$ cat README
finishing 1.2.3
working on new version
1.2.4-work
Added data.1.txt to 1.2.4-work-1-gd43a42b
Added data.2.txt to 1.2.4-work-2-gfe1a017
Added data.3.txt to 1.2.4-work-3-gcab72e4
Added data.4.txt to 1.2.4-work-4-g27032be
Added data.5.txt to 1.2.4-work-5-gde61aa0
Added data.6.txt to 1.2.4-work-6-g93d9b97
Added data.7.txt to 1.2.4-work-7-g5f17261
Added data.8.txt to 1.2.4-work-8-ge61e9e7
Added data.9.txt to 1.2.4-work-9-g57464e7
Added data.10.txt to 1.2.4-work-10-g05431e9
Added data.11.txt to 1.2.4-work-11-g3389222
Added data.12.txt to 1.2.4-work-12-ga4ff712
Added data.13.txt to 1.2.4-work-13-gc29a299
Added data.14.txt to 1.2.4-work-14-g6cf0587
Added data.15.txt to 1.2.4-work-15-g88a8886
Added data.16.txt to 1.2.4-work-16-gb889057
Added data.17.txt to 1.2.4-work-17-gfeb73ca
Added data.18.txt to 1.2.4-work-18-g6d522b6
Added data.19.txt to 1.2.4-work-19-gce37121
Added data.20.txt to 1.2.4-work-20-g8c3b68b
finishing 1.2.4
$ gl
* f932384 1.2.4 final (HEAD -> master, 1.2.4)
* 5245c21 1.2.4-work-20-g8c3b68b
* 8c3b68b 1.2.4-work-19-gce37121
* ce37121 1.2.4-work-18-g6d522b6
* 6d522b6 1.2.4-work-17-gfeb73ca
* feb73ca 1.2.4-work-16-gb889057
* b889057 1.2.4-work-15-g88a8886
* 88a8886 1.2.4-work-14-g6cf0587
* 6cf0587 1.2.4-work-13-gc29a299
* c29a299 1.2.4-work-12-ga4ff712
* a4ff712 1.2.4-work-11-g3389222
* 3389222 1.2.4-work-10-g05431e9
* 05431e9 1.2.4-work-9-g57464e7
* 57464e7 1.2.4-work-8-ge61e9e7
* e61e9e7 1.2.4-work-7-g5f17261
* 5f17261 1.2.4-work-6-g93d9b97
* 93d9b97 1.2.4-work-5-gde61aa0
* de61aa0 1.2.4-work-4-g27032be
* 27032be 1.2.4-work-3-gcab72e4
* cab72e4 1.2.4-work-2-gfe1a017
* fe1a017 1.2.4-work-1-gd43a42b
* d43a42b 1.2.4-work
* 1ffc839 New version is Work In Progress (1.2.4-work)
* 87399b8 1.2.3 final (1.2.3)
$ git diff fe1a017^..fe1a017
diff --git a/README b/README
index 0ca9559..98a4bc1 100644
--- a/README
+++ b/README
@@ -2,3 +2,4 @@ finishing 1.2.3
working on new version
1.2.4-work
+Added data.1.txt to 1.2.4-work-1-gd43a42b
diff --git a/data.1.txt b/data.1.txt
new file mode 100644
index 0000000..0624848
--- /dev/null
+++ b/data.1.txt
@@ -0,0 +1 @@
+1 1.2.4-work-1-gd43a42b
#!/bin/bash
# vim: fileencoding=utf-8:nomodified:nowrap:textwidth=0:foldmethod=marker:foldcolumn=4:syntax=sh:filetype=sh:ruler:showcmd:lcs=tab\:|- list
git init
# go for release 4)
echo "finishing 1.2.3" >>README
git add -A
git commit -am "1.2.3 final"
git tag -m "1.2.3" "1.2.3"
# start work on new version 1)
echo >>README
echo "working on new version" >>README
git commit -am "New version is Work In Progress"
git tag -m "1.2.4-work" "1.2.4-work"
# cokoli 2)
git describe >>README
git commit -am `git describe`
# pracujeme 3)
for i in `seq 1 20`; do
echo -n "$i ">data.$i.txt
git describe>>data.$i.txt
echo "Added data.$i.txt to " `git describe` >>README
git add -A
git commit -am `git describe`
done
# go for release 4)
echo "finishing 1.2.4" >>README
git add -A
git commit -am "1.2.4 final"
git tag -m "1.2.4" "1.2.4"
# start work on new version 1)
# ....................
(ale je fakt, ze by SemVer IMHO MEL mit moznost pro "nejaky bordel po verzi 1.2.3, ktery nezarucuje vubec nic", aby se nemusely delat takovehle skoky tam a zpet )Nerad bych se pletl, ale mám za to, že má.
Git se dá používat zhruba nekonečno různými způsoby, takže bych řekl, že chyba není ani v SemVer, ani v Gitu… :-)
Tím neříkám, že nemůžou nastat extrémní případy, kdy se můžeš dostat do nějakého konfliktu, který se musí řešit kompromisem… to se ale může stát s čímkoli a není to důvod danou technologii nebo metodiku zavrhnout.
Ono s tím Gitem se taky někdy stane, že rozejdou představy vývojářů a vedení projektu – když chce management dělat ve verzování a plánování moc velké kotrmelce, tak to nemusí ve VCS vypadat hezky, ale takový už je život. Typicky je to dané tím, že nebyla dopředu dohodnutá pravidla, co se smí a co nesmí, a lidé do toho vkládali nějaké svoje nevyslovené představy, které se samozřejmě mohou rozcházet. V takových chvílích právě pomáhají pravidla typu SemVer, kde je celkem jasně popsané, co se má v jaké situaci dělat.
)
Takze jestli tomu chce nekdo rikat, ze to funguje... Ja to tak rozhodne nevidim.
Takze jestli tomu chce nekdo rikat, ze to funguje... Ja to tak rozhodne nevidim.Pracujeme s tím co máme. Uvedeš-li lepší řešení, bude to super. Ale taky by si mohl skončit jako xkucf03 :-P
cokoliv neotagovaneho nepovazujes za verzi … tagujes kazdy commit
Tohle už jsem tu v diskusi někde viděl. Podle mého je to nepochopení účelu. Smysl toho sémantického verzování vidím tam, kde máš vztah mezi dvěma subjekty: typicky dodavatel (vývojář) a zákazník (uživatel). Nebo aspoň dva týmy v rámci větší organizace, které spolu moc nemluví. V takovém vztahu je potřeba správně komunikovat, v čem se nová verze liší a zda je kompatibilní – a k tomu slouží jako nástroj to sémantické verzování.
Pokud mám ale vše v rámci jednoho týmu a jen si sdílíme kód mezi sebou (v rámci spolupráce mezi jednotlivými vývojáři), tak bych ani nemluvit o vydání (release). V rámci vývoje se jen sypou jednotlivé změny (commity) do příslušné větve, případně se do ní začleňují změny z větví jednotlivých požadavků (feature branch). CI může testovat každou takovou změnu, a když najde chybu, tak ti nahlásí, že to bylo např. v 204f6466c03b a ty už si to dohledáš – je to jednoznačný identifikátor – a nepotřebuješ tam dávat ani žádné štítky (tagy). A až ve chvíli, kdy máš pocit, že je to hotové, tak to tím štítkem označíš a předáš to týmu testerů, a ten ověří shodu se zadáním/specifikací. Pokud to projde, tak se dá verze označená tímto štítkem poslat k zákazníkům/uživatelům, a pokud to neprojde, tak se to vrací do vývoje a dáš si ještě jedno kolečko.
Tzn. nemá cenu do toho zatahovat víc byrokracie, než je nutné – ta byrokracie má smysl ve chvíli, kdy jde o skutečné vydání, které poskytuješ nějakému jinému subjektu.
Tak jasně, můžeš si třeba uzavírat smlouvy s manželkou o tom, kdo bude kdy vynášet koš. Když tě to baví, tak prosím, ale přeci jen důležitější je mít smlouvu s firmou (tzn. tím jiným subjektem), která vám vyváží popelnici.
Maj.Min (případně Maj.Min-rcX pro pre-release verzi) a nazdar. To musí přece stačit každému
... kde treba u node js projektu byva(lo) normalni definovat zavislosti ve smyslu "nacti verzi 1.3 nebo vyssi v ramci 1 major verze", protoze prece v ramci 1.X musi byt vsechno kompatibilni.Nikdo neřekl, že musí. A v případě node js výraz "muset" je vysloveně vtip.
Nemusim snad dodavat, ze to casto konci katastrofalne a dnes je doporuceno pouzivat fixni verze (takze semanticke verzovani az tak semanticke neni).O žádné takovém doporučení nevím. Přijde mi problém spíše v tom, že ten semver bojkotuješ
Jako proč ne, pokud se ti to "příčí", definuj si verze jak je libo. Ale ani náhodou to není obecná pravda, a mnoha programátorům semver naopak otevírá oči (jsem propagátor, takže popisuju co jsem zažil).
Nikdo neřekl, že musí. A v případě node js výraz "muset" je vysloveně vtip."Muset" je zavadejici. Problem je, ze programatori tu adherenci k semver ocekavaji a proto takto blbe zavislosti definuji.
O žádné takovém doporučení nevím.NPM doporucuje commitovat package-lock.json do repozitare. Vysledkem je, ze se pouzivaji fixni verze i kdyz je to v kombinaci s package.json takove zmatene.
Jako proč ne, pokud se ti to "příčí", definuj si verze jak je libo.Jo, verzuji tak, jak je to vhodne pro moje projekty. Pro knihovny pouzivam volnejsi variantu semver (male breaking change nemeni major verzi), pro end-user projekty semver nema zadny smysl.
Jenže takhle to chápat nelze. Já když vydám balíček 1.2.3, a následně vydám balíček 1.2.4, tak tím dávám najevo, že by to nemělo nic rozbít, protože release. To ale samozřejmě neznamená, že to nic nerozbije. Jsme ve světě javascriptu, tam nejsou žádné záruky. Je to jen informace. Nezaručená, jako cokoliv jiného v tomto jazyce. A naopak. Takový Elm je schopen požadované záruky poskytnout. (On je dokonce schopen správnou verzi generovat, ale to už je jiný příběh. To byste to museli vidět.) To, že je Javascript debilní jazyk, který nic nezaručuje, neznamená, že je ten koncept špatně.Nikdo neřekl, že musí. A v případě node js výraz "muset" je vysloveně vtip."Muset" je zavadejici. Problem je, ze programatori tu adherenci k semver ocekavaji a proto takto blbe zavislosti definuji.
Nemohu souhlasit. Je to naprosto logicé. package.json je obecné očekávání, a package-lock.json je zkontrolovaná realita. Je to všechno poplatné jazyku. S ideou semver to nesouvisí. Nejedná se o doporučení. Jedná se o (se semver nesouvisející) požadavek, že chci mít stejný stav buildu jako kolega a ne, že se mu package resolver špatně vyspí, a vygeneruje mu jiné verze balíčků než mě. Opravdu se obávám, že se tu navážíš do Semver velice, velice nespravedlivě. Samozřejmě mě zajímá (bez ironie) jakákoliv alternativa. Která by fungovala třeba i jen jinak, ale zajímavěji. Co se zatím pohybuji v oboru, tak semver vyčuhuje z všeobecného moře anarchieO žádné takovém doporučení nevím.NPM doporucuje commitovat package-lock.json do repozitare. Vysledkem je, ze se pouzivaji fixni verze i kdyz je to v kombinaci s package.json takove zmatene.
Verzování datumem tomu budiž zářným příkladem.
Samozřejmě mě zajímá (bez ironie) jakákoliv alternativa. Která by fungovala třeba i jen jinak, ale zajímavěji. Co se zatím pohybuji v oboru, tak semver vyčuhuje z všeobecného moře anarchieAlternativa je cist release notes a vzdat se toho planeho idealu, ze do tri cislic oddelenych teckou dokazes nacpat dostatecnou informaci o tom, co dana verze obsahuje.
Jen prosim neevangelizovat jak tady Franta, pro nehoz software nepouzivajici semver je automaticky "insane".To nemohu slíbit. Protože s ním defakto, minimálně v tomto, souhlasím.
Tak to je dobrej vtip. Autor jednoho z nejvíce insane SW co jsem za poslední dobu viděl - Relational pipes (distribuce, instalace) - má potřebu všem vysvětlit, co je sane SW. Nová doba! Host vyhazuje vrchního...
8.10.2019 11:59
xkucf03 | skóre: 49
| blog: xkucf03
Ta stránka, kterou odkazuješ, začíná slovy:
This is the first public release of Relational pipes for brave and courageous!
:-)
Nejpozději od verze 1.0 budou běžné distribuční balíčky.
To je tak, když někdo "insane" řadí release verze odzhora dolů. Ale na věci to nic nemění, protože u poslední verze je to ještě větší peklo (viz ten sed)...
Zásadní problém je v tom, že ten manifest je z velké části manifest "enterprise fetišismu" jak tady někdo trefně poznamenal. A se stejným enterprise fetišismem (u člověka co 10 let programoval pro banky v Javě to není překvapivé) se stavíš i k těm relational pipes. Ale uživatelský SW se takhle opravdu dělat nedá, uživatele opravdu nezajímá nějaká filozofie projektu, krása kódu ("readability is preferred to performance" abych citoval ten pamflet), nebo zda má program unit testy či reprodukovatelné buildy. Uživatel chce SW, který rychle a jednoduše řeší přesně jeho problém. Čímž nechci tvrdit, že uživatelský SW = můžu prasit jak chci, ale že priority jsou prostě jinde.
Kolik lidí tu věc asi vyzkouší (a to teď vůbec nehodnotím smysluplnost celýho toho projektu, která už je sama o sobě diskutabilní), když si pro instalaci musim nainstalovat obskurní Mercurial, a udělat cut&paste 50 řádkového scriptu pro Debian, který to snad skompiluje?!
8.10.2019 17:08
xkucf03 | skóre: 49
| blog: xkucf03
Ale na věci to nic nemění, protože u poslední verze je to ještě větší peklo
I ta poslední verze je pořád určená pro vývojáře:
We are pleased to introduce you the new development version of Relational pipes.
A na úvodní stránce projektu Relational pipes se upřímně píše:
The main ideas and the roadmap are quite clear, but many things will change (including the format internals and interfaces of the libraries and tools). Because we understand how important the API and ABI stability is, we are not ready to publish the version 1.0 yet.
On the other hand, the already published tools (tagged as v0.x in v_0 branch) should work quite well (should compile, should run, should not segfault often, should not wipe your hard drive or kill your cat), so they might be useful for someone who likes our ideas and who is prepared to update own programs and scripts when the new version is ready.
Má to nestabilní API a tím pádem to není určené pro produkční použití. Cílem těchto verzí je ověřit určité koncepty, odladit ten formát, API, syntaxi CLI parametrů atd. Protože jakmile vyjde verze 1.0, už tyto věci nebude možné měnit, protože by šlo o zpětně nekompatibilní změnu (musela by vyjít verze 2.0 a uživatelé by na ni museli pracně přecházet).
A se stejným enterprise fetišismem (u člověka co 10 let programoval pro banky v Javě to není překvapivé)
Jestli ti jako „enterprise fetišismus“ přijde to, že se nebudou dělat prasárny tohoto typu, nebo že máš zpřístupnit verzovací systém a ne jen pouhé snapshoty vydaných verzí, nebo že nemáš míchat politiku do vývoje softwaru, nebo že se má dodržovat zpětná kompatibilita (a když už ji porušíš, tak to máš ostatním aspoň říct), pak ano, je to „enterprise fetišismus“ :-)
Uživatel chce SW, který rychle a jednoduše řeší přesně jeho problém.
Tohle je krátkozraký pohled. Ten manifest je uveden slovy:
In respect to user freedoms, privacy, liberty and software quality we create software according to the following guidelines. Developing Sane software is not easy, however we believe that this is the right way because this software is written once but used many times and maintained for years or decades.
Zdaleka ne každý software to musí splňovat. Je úplně v pořádku napsat nějakou jednorázovou utilitu nebo skript a někde je jen tak pohodit na webu – i to může být užitečné. Ale ten manifest cílí na trochu jiný druh softwaru (zralejší, dlouhodobě udržovaný).
Kolik lidí tu věc asi vyzkouší (a to teď vůbec nehodnotím smysluplnost celýho toho projektu, která už je sama o sobě diskutabilní), když si pro instalaci musim nainstalovat obskurní Mercurial, a udělat cut&paste 50 řádkového scriptu pro Debian, který to snad skompiluje?!
Jak jsem psal, ty současné verze (v0.*) jsou určené pro vývojáře. Klasické balíčky budou. Ale v tuhle chvíli pro mne má přínos ten, kdo je schopný si ten skript přečíst a pochopit ho, kdo se podívá do zdrojáku a upozorní na nějakou chybu. Asi udělám i nějaké Snap nebo Flatpak balíčky, ale zatím se mi do toho nechce moc tahat uživatele, protože ti by byli leda zklamaní, až se změní API (což se ještě měnit bude). Sám to chci taky ještě chvíli používat pro vlastní potřebu, než to odladím a budu na to moci dát nálepku 1.0 (pak už se spousta věcí měnit nedá).
A ještě k té modularitě: tahle aplikace je i jako celek poměrně malá, ale pointa je v tom, že když tě nezajímá třeba XML a SQL, tak si nebudeš tyhle moduly (a jejich závislosti) vůbec stahovat a nebude do toho vstupovat jejich kód. Díky tomu ten kód, který kompiluješ a kterému bys měl věřit, osekáš jen na to minimum, které skutečně potřebuješ. Existuje spousta programů nebo knihoven, na kterých se mi líbí určitá funkcionalita, ale nelze ji z toho vypreparovat a dohromady je to velký moloch tvořený spoustou řádků kódu, který mi za to nestojí.
Pak jsem se taky setkal s projektem, kde část funkcionality byla zabudovaná v jádře a část funkcionality (toho samého typu) byla bokem. Nebyl jsem u toho, když to vznikalo, asi jim to tehdy přišlo jako dobrý nápad a „jednodušší“ řešení, ale byl jsem u toho, když s tím měli problémy a rozdíly mezi interními a externími konektory, kde se to chovalo jinak, UI na to nebylo připravené… a u změnových požadavků, které z pohledu byznysu vypadaly úplně přímočaře a jednoduše, ti vývojáři přicházeli na to, že to buď nejde nebo by museli překopat velkou část toho systému. Tohle je neštěstí a technologický dluh, kostlivec ve skříni – některé věci je prostě lepší dělat správně a čistě od samého začátku.
Když to tak čtu, tak na to se opravdu nedá už říct nic jiného než ono známé: "je to marný, je to marný, je to marný"...
Přes rok bastlíš SW aniž bys o uživatele byť jenom stál, natož nějaké měl (tudíž o nějakých reálných zkušenostech/potřebách uživatelů nevíš nic), ale už vyrábíš manifesty, jak se má dělat SW na desítky let a strachuješ se o stabilitu API, aby náhodou v budoucnu (oba) uživatelé nemuseli přecházet z verze 1.0 na 2.0. Pokuď budeš k tomu projektu přistupovat nadále jako k vývoji enterprise bankovního systému, nebudou tě ale za 10 let žádný problémy s API trápit - vyvíjet SW pro tři uživatele a psát si sám se sebou v mailing listu 10 let nevydrží ani ten největší fundamentalista.
Protože mi vadí, když někdo, jehož projekty jsou ukázkovým příkladem "insane" SW poučuje ostatní jak to mají dělat aniž by to fungovalo alespoň u toho jeho SW. Ale jinak ano, že by to mělo nějaký smysl si iluze nedělám...
viz ten sedTeď jsem na to kouknul a to opravdu vypadá divoce. Ad-hoc patchovat sedem zdrojáky a CMake skripty fakt není dobrej nápad. Navíc tyhle problémy by se měly řešit právě buď v tom CMaku a/nebo preprocesorem. Nicméně teď když Franta narazil na problémy s verzováním C++ a závislostí na různých systémech, třeba mi bude věřit, že linuxové balíčkovací systémy nejsou v oblasti dependencí spása lidstva
9.10.2019 09:40
xkucf03 | skóre: 49
| blog: xkucf03
Ad-hoc patchovat sedem zdrojáky a CMake skripty fakt není dobrej nápad.
Jasně, že není. Taky je to tam jen jako provizorní řešení v té vývojové verzi, nechci to tam mít trvale, proto jsem to ani nezabudovával do toho CMaku nebo do zdrojáků formou nějakých ifdefů.
9.10.2019 09:55
xkucf03 | skóre: 49
| blog: xkucf03
P.S. A je to tam jako komentář ve smyslu: sice to chcete přeložit na nepodporované platformě, ale když si to takhle ohackujete, tak by to mohlo fungovat. A je tam rovnou návod, jak to udělat – místo toho, aby si na to každý musel přijít sám metodou pokus omyl. Já kolikrát zkouším zkompilovat nějaký kód na jiné platformě, než autor předpokládal, a je potřeba na pár místech změnit zdroják nebo nějaké skripty – akorát většinou k tomu ten návod chybí.
Přijde mi, že tu lidi hledají ve všem chyby za každou cenu. Kdybych tam napsal, že je podporovaná jen jedna konkrétní verze Debianu a neradil, jak to lze rozjet i jinde, tak byste neměli co komentovat :-) (ale přínos pro někoho, kdo si to chce opravdu přeložit a vyzkoušet a ne se jen předvádět v diskusích, by byl nižší)
9.10.2019 10:06
xkucf03 | skóre: 49
| blog: xkucf03
P.P.S. A tohle je taky výhoda toho modulárního návrhu – na platformě, kde příslušné API nebo knihovna chybí, prostě daný modul nebude k dispozici, zatímco ten zbytek používat půjde. Což mi přijde daleko lepší, než mít monolitickou aplikaci, která nepůjde1 používat buď vůbec, nebo bude zahnojená hromadou ifdefů v kódu a různými dalšími výjimkami ve skriptech.
[1] kvůli nesplněné nepodstatné závislosti ovlivňující jen část funkcionality
A tohle je taky výhoda toho modulárního návrhu – na platformě, kde příslušné API nebo knihovna chybí, prostě daný modul nebude k dispozici, zatímco ten zbytek používat půjde.To je otázka. Na jednu stranu to je výhoda, flipside ale je, že se pak na tom programu nedá záviset jako na celku, protože kterákoli součást může chybět, čímž se ten problém s chybějící závislostí na nějakém distru neřeší, pouze se propaguje dál stromem závislostí...
Což mi přijde daleko lepší, než mít monolitickou aplikaci, která nepůjde používat buď vůbec, nebo bude zahnojená hromadou ifdefů v kódu a různými dalšími výjimkami ve skriptech.
Když budeš chtít podporovat víc než jen jednu verzi Debianu, to zahnojení zdrojáků tam mít budeš stejně
Obecně bych se v build instrukcích co možná nejvíc vyvaroval nějakých shell skriptů apod. - to tam prsotě obecně IMO nechceš.
No ale nic, tak já toho nechám, abych nehledal zbytečně chyby
9.10.2019 13:10
Gilhad | skóre: 20
| blog: gilhadoviny
9.10.2019 15:53
xkucf03 | skóre: 49
| blog: xkucf03
Ten tvůj přístup právě vede na velké monolitické bloatware balíky.
Pro mě jako uživatele je striktně lepší, když vím, že "nástroj XY podporuje skriptování v Guile"
Jde o to, že ten nástroj může podporovat i skriptování v Pythonu, AWKu, SQL, Perlu… a desítky různých vstupních a výstupních formátů, z nichž každý může mít nějaké další závislosti. A pak se dostáváš do situace, kdy chceš třeba transformovat formát X na formát Y pomocí transformace Z, ale musíš si k tomu nainstalovat ještě Python, AWK, SQL, Perl, Guile, knihovny pro XML, ASN.1 a další závislosti, i když tě nic z toho nezajímá a akorát to zvyšuje komplexitu.
flipside ale je, že se pak na tom programu nedá záviset jako na celku, protože kterákoli součást může chybět
Řešení je úplně jednoduché – vyjmenuješ závislosti (moduly), které používáš.
Kdybys např. psal skript, který pomocí relačních rour transformuje CSV na XML a filtruje ho pomocí SQL, tak si dáš do závislostí právě tři balíčky: relpipe-in-csv, relpipe-tr-sql a relpipe-out-xml. A nemusíš do toho zatahovat ty další moduly a jejich závislosti (což může být spousta různých knihoven, které nepotřebuješ a nechceš instalovat).
Jde o to, že ten nástroj může podporovat i skriptování v Pythonu, AWKu, SQL, Perlu…A proč vlastně neuděláš spíš moduly/bindingy do Pythonu, Perlu atd.? Třeba
relpipe-tr-python by pak mohl být jen skript, ne?
9.10.2019 16:35
Gilhad | skóre: 20
| blog: gilhadoviny
9.10.2019 18:26
xkucf03 | skóre: 49
| blog: xkucf03
I tak by ale IMO bylo na místě se nad tím zamyslet, protože rozporcovat relativně ne až tak složitý prográmek do 28 balíčků mi rozhodně sane nepřijde. (Netvrdil tu někde Franta, že nemá rád komplexitu??)
Z hlediska kódu je to trochu extrém, protože jednotlivé moduly mají řádově jen stovky řádků, což je hodně málo. Z hlediska závislostí na dalších knihovnách to ale smysl dává (každá ta knihovna jsou pak klidně desítky nebo stovky tisíc řádků kódu, možná i víc, které vstupují do hry).
Jako uživatel si pak můžu říct: chci dělat to a to (např. transformovat X na Y pomocí Z), tak si vyberu jen potřebné moduly, vidím, že to má třeba jen tisíc řádek dohromady, což mám za chvilku přečtené. Takže i když budu paranoidní a nebudu chtít spouštět žádný kód (od méně známého autora), který jsem nečetl, tak to pořád můžu používat. A to v případě bloatwaru a monolitů právě neplatí – těm musíš buď věřit nebo strávit čtením zdrojáků týdny, měsíce atd.
cli, filesystem, fstab a csv do zvlášť binárek, balíčků, a dokonce repositáře?
10.10.2019 00:25
xkucf03 | skóre: 49
| blog: xkucf03
Protože nechci a nemůžu předjímat, jak bude který modul komplexní a jaké bude mít závislosti. Tohle se může v čase měnit. Zrovna ten relpipe-in-filesystem by závisel svého času na experimentálním C++ API, které nemusí být dostupné všude. Na druhé straně relpipe-in-csv dneska závisí jen na standardní knihovně a parsování CSV jsem si napsal sám, ale teoreticky se může stát, že svoji implementaci zavrhnu a místo toho budu chtít volat nějakou knihovnu. To by pak v budoucnu znamenalo buď vyčlenit CSV ze společného modulu do samostatného (tzn. nekompatibilní změnu), nebo naopak všem vnutit závislosti na té CSV knihovně, i když o to vůbec nestojí. To jsou tedy pragmatické důvody.1 A pak je to otázka čistoty návrhu a jednotnosti – všechno je na jedné úrovni vedle sebe, je to plochá struktura, nenastává tam to, že by někde bylo schovaných pět nástrojů a jinde byly po jednom. Všude jsou po jednom.
[1] viz také poslední odstavec #50 – a mimochodem, tahle zkušenost byla relativně nedávná – v té době jsem měl ty relační roury už dávno takhle rozvržené
Protože nechci a nemůžu předjímat, jak bude který modul komplexní a jaké bude mít závislosti.Nic ve zlém, ale přijde mi, že to moc řešíš (protože tě to evidentně baví). Technicky řešíš problém, který neexistuje. Standardní řešení je při kompilaci nechat zkompilovat vše, co je k dispozici, nebo vše, co potřebuješ, a můžeš to vesele používat. Pragmaticky, samostatnou kompilaci modulů má smysl řešit až v momentě, kdy to začne být reálně potřeba, kdy to začne být problém. Dovolím si soudit, že to v dohledné době jen tak nebude. Toto ma jednoznačně znaky overengineeringu a paralýzy analyzou. Ušetřený čas by šel věnovat rozvoji samotne aplikace. Ale chápu, že tě to baví... je to trochu něco jako s tím svobodným CADem, který jste tu vyvíjeli. Spousta času věnována dokonalé architektuře vám umožnila eliminovat spoustu chyb v samotné implementaci.
10.10.2019 12:12
xxx | skóre: 42
| blog: Na Kafíčko
10.10.2019 14:01
xkucf03 | skóre: 49
| blog: xkucf03
Nepouzivejte libfoo z vasi distribuce, protoze nelze zarucit, ze bude obsahovat veskerou funkcnost.
Pokud se to děje, tak je to právě způsobené to chybějící modulárností, viz #94.
Když je ta knihovna/program monolitický moloch, tak se může stát, že z něj někdo při kompilaci vyhází (povypíná) různé funkce, a ve výsledku pak nikdo neví, co od toho může čekat. Pokud by to mělo příčetné závislosti a bylo to strukturované modulárně, tak pak stačí k jednoznačné identifikaci název a číslo verze – a na základě toho už víš, co bude uvnitř. Pokud v nějaké distribuci nejsou některé závislosti k dispozici nebo je tam distributor nechce mít, tak prostě nezahrne dané moduly, které na nich závisejí. Pak všichni ví, na čem jsou, a když nějaký program na takovém modulu bude záviset, bude na první pohled vidět, že na dané distribuci nebude fungovat (dokud se tam ta závislost nedoplní), místo toho, aby to nějak záhadně padalo za běhu nebo nešlo přeložit.
10.10.2019 14:17
xkucf03 | skóre: 49
| blog: xkucf03
Když je ta knihovna/program monolitický moloch, tak se může stát, že z něj někdo při kompilaci vyhází (povypíná) různé funkce, a ve výsledku pak nikdo neví, co od toho může čekat.Konfigurační nastavení / fearures / atd. nijak nesouvisí s monolitičností. Tys např. pracoval s libhidapi ne? Takže bys mohl vědět, že libhidapi má na Linuxu dvě varianty podle použitého backendu: hidraw a libusb. V Debianu to rozpadli do dvou balíčků, zatímco třeba Arch má jednu verzi s libusb backendem. Přitom na té volbě záleží - ovlivňuje to např. použité udev rules. Na jednom projektu aktuálně tohle řešim - existuje jediný rozumný důvod, proč bych si neměl libhidapi prostě přilinkovat staticky? Ta knihovna má na disku 90 kilo-fucking-bytes a případné bezpečnostní problémy se budou muset řešit explicitně tak jako tak, protože ten SW se dodává i na Windows a Mac.
Pak všichni ví, na čem jsouTo je jedna možnost, druhá je, že všichni pak musí dělat šílené množinové a grafové operace, aby vůbec zjistili, jak na tom jsou, jenom proto, aby z toho nakonec vyplynulo, že ta věc na jejich systému stejně nefunguje, protože autor to testoval na jiném a tam jsou věci o trochu jinak... Kde vlastně máš uvedené dependence těch jednotlivých relpipes modulů?
10.10.2019 15:44
xkucf03 | skóre: 49
| blog: xkucf03
Konfigurační nastavení / fearures / atd. nijak nesouvisí s monolitičností.
Pokud to neovlivňuje rozhraní (kontrakt) navenek, tak je to v pořádku. Můžeš např. dát na výběr mezi různými šifrovacími knihovnami, možná algoritmy, kde jeden je třeba náročnější na paměť a druhý na CPU, ale jinak dávají stejný výsledek (i když tohle by se asi mělo řešit spíš parametrem za běhu než při kompilaci). Ale pokud se mění rozhraní resp. množina poskytovaných funkcí, tak by to měly být dva různě pojmenované moduly.
Jinak o tomhle jsme se nedávno bavili na IRC. Pokud to chceš linkovat staticky, tak ten problém ani neexistuje. Balíčkem je v tom případě zdroják – a ten je vždy stejný (a jednoznačně identifikovaný názvem modulu/balíčku a verzí). A případné kompilační parametry tam vstupují v rámci kompilace té aplikace, která na tomto balíčku závisí (a ta si řekne, jak to chce zkompilovat a to taky dostane).
Kde vlastně máš uvedené dependence těch jednotlivých relpipes modulů?
Zatím jen v CMakeLists.txt a je jich málo (v tom návodu je to popsané, co si máš nainstalovat). V té produkční verzi to budou normální distribuční balíčky, které to mají ve svých metadatech + to bude v dokumentaci.
apt install g++ make cmake mercurial pkg-config apt install libxerces-c-dev # needed only for relpipe-in-xml module apt install guile-2.2-dev # needed only for relpipe-tr-guile module; guile-2.0-dev also works but requires a patch (see below) apt install gawk # needed only for relpipe-tr-awk module apt install libxml++2.6-dev # needed only for relpipe-in-xmltable module apt install libsqlite3-dev # needed only for relpipe-tr-sql module
Takže si nainstaluješ jen ty knihovny, které jsou potřeba pro moduly, které chceš používat.
10.10.2019 16:46
xxx | skóre: 42
| blog: Na Kafíčko
Na to bude samozřejmě vlastní package manager pro relational-pipes, takže s tím nebude žádný problém...
10.10.2019 17:03
xkucf03 | skóre: 49
| blog: xkucf03
Můžu požádat o zdroj této dezinformace?
Ve skutečnosti to budou normální balíčky pro danou distribuci (případně i něco napříč distribucemi, co už existuje, jako Snap nebo Flatpak).
10.10.2019 17:00
xkucf03 | skóre: 49
| blog: xkucf03
Jaké peklo zase? Podívej se na unix a nástroje pro zpracování textu:
Když budeš chtít např. zpracovávat text pomocí awk, nemusíš si instalovat sed, ani grep, ani cut, ani perl. A když budeš chtít používat jen grep a cut, tak nemusíš instalovat awk, sed ani perl.
Ano, je to 2^5 kombinací (to jsem vybral namátkou jen pár příkazů). Ale je to v pořádku – prostě si jako závislost deklaruješ to, co reálně používáš.
Ty relační roury jsou totéž, akorát místo s textem pracují s určitým binárním formátem. Je chyba se na to dívat jako na jeden program/balík. Fakt, že to má společnou webovou stránku a drží to společné konvence, ještě neznamená, že má být uživatel nucen si to nainstalovat všechno najednou.
10.10.2019 17:13
xxx | skóre: 42
| blog: Na Kafíčko
10.10.2019 17:45
xkucf03 | skóre: 49
| blog: xkucf03
Když už tady trollíme, tak aspoň pořádně:
$ apt show grep gawk sed perl coreutils | sed 's/^ /+/g' | relpipe-in-recfile | relpipe-tr-cut '.*' Package Version Provides Homepage | relpipe-out-tabular WARNING: apt does not have a stable CLI interface. Use with caution in scripts. recfile: ╭──────────────────┬──────────────────────┬───────────────────┬───────────────────────────────────╮ │ Package (string) │ Version (string) │ Provides (string) │ Homepage (string) │ ├──────────────────┼──────────────────────┼───────────────────┼───────────────────────────────────┤ │ grep │ 3.1-2build1 │ rgrep │ http://www.gnu.org/software/grep/ │ │ gawk │ 1:4.1.4+dfsg-1build1 │ awk │ http://www.gnu.org/software/gawk/ │ │ sed │ 4.4-2 │ │ https://www.gnu.org/software/sed/ │ │ perl │ 5.26.1-6ubuntu0.3 │ │ http://dev.perl.org/perl5/ │ │ coreutils │ 8.28-1ubuntu1 │ │ http://gnu.org/software/coreutils │ ╰──────────────────┴──────────────────────┴───────────────────┴───────────────────────────────────╯ Record count: 5
A mimochodem to varování je ostuda Debianu – takový balíčkovací systém Guixu data ve strojově čitelné formě poskytuje (rovnou v tom formátu recfile).
Nebo nekoho, jehoz SW mel vzdy jedineho zakaznika, kterym byl admin co to nainstaluje v bance.
Tam je to právě jedno – když je zákazník jen jeden, tak se mu dá dodávat monolit udělaný jemu na míru. Když je zákazníků/uživatelů víc, tak se právě hodí ta modulární architektura, protože každý chce něco jiného (resp. řeší se to jak konfigurovatelností tak modulárností).
Pokuď každou zcela konstruktivní připomínku budeš považovat za trollení, tak se moc daleko nedostaneš i když to neodporuje Manifestu příčetného softwaru... Představa, že pro ten tvůj bazmek někdo bude vyrábět padesát balíčků (viz coreutils) je úplně mimo realitu stejně tak jako že to někdo bude chtít v padesáti balíčcích používat.
Mimochodem, místo sepisování manifestů bych se na tvém místě radši věnoval těm rozbitejm tabulkám co z toho bazmeku lezou...
10.10.2019 14:14
xkucf03 | skóre: 49
| blog: xkucf03
Nic ve zlém, ale přijde mi, že to moc řešíš (protože tě to evidentně baví). Technicky řešíš problém, který neexistuje.
Vychází to ze zkušenosti (stejně jako ten manifest) s profesionálním vývojem softwaru za posledních cca 14 let. Kolikrát se mi stalo, že jsem se nechal „ukecat“ k nějakému kompromisu a později se ukázalo, že to byla chyba a že bychom si ušetřili spoustu práce, kdybychom to už na začátku udělali pořádně.
Jinak samozřejmě souhlasím, že investovat úsilí do něčeho, co dost možná nebude potřeba, je taky špatně. Není na to nějaký jednoznačný recept a algoritmické řešení. Je potřeba zvažovat, kolik úsilí mne to bude stát navíc, zda je to jednorázová investice nebo opakovaná, kolik kódu musím napsat, kolik bych ho případně musel zahazovat a přepisovat atd. Nemám problém s nedokonalým kódem uvnitř komponent – ten jde totiž v případě potřeby snadno inkrementálně vylepšovat nebo zrychlovat. Ale v případě návrhu a rozhraní má člověk daleko víc svázané ruce (zpětná kompatibilita) a měnit to dodatečně je výrazně těžší, než změnit kód uvnitř metody/funkce/procedury/komponenty.
Vychází to ze zkušenosti (stejně jako ten manifest) s profesionálním vývojem softwaru za posledních cca 14 let. Kolikrát se mi stalo, že jsem se nechal „ukecat“ k nějakému kompromisu a později se ukázalo, že to byla chyba a že bychom si ušetřili spoustu práce, kdybychom to už na začátku udělali pořádně.To se mi taky mockrat stalo. Ale take se mi nejednou stalo, ze jsem si vymyslel super abstrakci, ktera vypadala genialne s tim, ze bude mit spoustu vyuziti a usetri spoustu prace. Nakonec to dopadlo tak, ze vyuziti bylo jedine, vsude to zavezelo a nakonec to zdrzovalo vyvoj...
Není na to nějaký jednoznačný recept a algoritmické řešení. Je potřeba zvažovat, kolik úsilí mne to bude stát navíc, zda je to jednorázová investice nebo opakovaná, kolik kódu musím napsat, kolik bych ho případně musel zahazovat a přepisovat atd.Paralyza analyzou, ... ten recept se jmenuje KISS, tj. Keep It Simple, Stupid! Vsimni si, kolikrat v tom tvem manifestu, je tento zakladni (nejen unixovy) pristup zminen.
Ale v případě návrhu a rozhraní má člověk daleko víc svázané ruce (zpětná kompatibilita) a měnit to dodatečně je výrazně těžší, než změnit kód uvnitř metody/funkce/procedury/komponenty.Musi to byt hrozne, kdyz se desis takovych problemu u projektu, na kterem pracuje jeden vyvojar (a ktery ma priblizne stejne mnozstvi uzivatelu). Myslis, ze takove starosti meli i Thompson a Ritchie v sedesatem devatem? Ti panove, co opravdu sedeli, za zelenymi CRT monitory. Na projekt, ktery je svym rozsahem na urovni mensi bakalarky, kolem toho delas silenou vedu... ale kdyz te bavi delat z toho vedu, proc ne...
10.10.2019 16:21
xkucf03 | skóre: 49
| blog: xkucf03
To se mi taky mockrat stalo. Ale take se mi nejednou stalo, ze jsem si vymyslel super abstrakci, ktera vypadala genialne s tim, ze bude mit spoustu vyuziti a usetri spoustu prace. Nakonec to dopadlo tak, ze vyuziti bylo jedine, vsude to zavezelo a nakonec to zdrzovalo vyvoj...
Ano, lidi dělají chyby v obou směrech/extrémech. Vždyť tam sám píšu:
Jinak samozřejmě souhlasím, že investovat úsilí do něčeho, co dost možná nebude potřeba, je taky špatně.
Neříkáš nic nového a asi ani nejsme ve sporu.
Paralyza analyzou, ...
Jakou analýzou? Když říkám, že máš něco zvážit, tak o to neznamená, že si to musíš dávat do tabulek, vykreslovat do do grafů a měsíc nad tím bádat. Zvážit = zamyslet se nad tím. To můžeš udělat během pěti minut, kdy si vaříš kafe v kuchyňce.
Na projekt, ktery je svym rozsahem na urovni mensi bakalarky
Já ten malý počet řádek považuji za výhodu – čím méně kódu bude, tím líp. S poměrem množství kódu ku množství funkcí jsem spokojený. Snažím se tam používat co nejvíc existujících věcí a začlenit to do stávajícího ekosystému. Např. skládat data z různých zdrojů pomocí Bashe (případně jiného shellu) se mi dost líbí a nemusel jsem kvůli tomu napsat ani řádku kódu:
( relpipe-in-fstab ; find /etc/ssh/ -print0 | relpipe-in-filesystem ) | relpipe-out-tabular
Co dělají ty závorky, středníky a svislítka už vymysleli a naprogramovali jiní přede mnou a já to můžu jen použít bez další práce.
Ohledně rychlosti vývoje: s tím už tak spokojený nejsem, uznávám, že se to dost vleče – nevěnoval jsem tomu tolik času, kolik bych měl, řešil jsem jiné věci (je to vidět i na historii v Mercurialu, jsou tam dlouhé proluky). Ale když už si k tomu sednu, tak to jde celkem rychle. Brzo si na to zase najdu čas a vydám další verzi.
Myslis, ze takove starosti meli i Thompson a Ritchie v sedesatem devatem? Ti panove, co opravdu sedeli, za zelenymi CRT monitory.
Unix je právě skvělým příkladem té modulární architektury. Jsou to malé jednoduché a jednoúčelové příkazy (které v tomto kontextu nazývám moduly) a mají jasně definované rozhraní – parametry, vstup a výstup. A kdyby autoři toto rozhraní (kontrakt) rozbíjeli zpětně nekompatibilními změnami, tak by to ke spokojenosti uživatelů a úspěchu fakt nepřispělo.
Souhlasis, ale neprijde mi, ze by sis to uvedomoval. Opravdu si myslis, ze ty nerelacni roury se jako celek drzi principu KISS?Ano, lidi dělají chyby v obou směrech/extrémech. Vždyť tam sám píšu:Jinak samozřejmě souhlasím, že investovat úsilí do něčeho, co dost možná nebude potřeba, je taky špatně.
Já ten malý počet řádek považuji za výhodu – čím méně kódu bude, tím líp. S poměrem množství kódu ku množství funkcí jsem spokojený.Na malem poctu radku neni nic spatneho. Kdybys pouzil jiny jazyk (Python?), kazdy ten modul by se mohl zcvrknout na par jednotek, mozna desitek radek a udelalo by to stejnou paradu. Mirim spis k tomu, zda je opravdu potreba pro projekt tohoto typu mit 30 samostatnych projektu, 30 samostatnych repozitaru, mailing list, kryptograficky zabezpecenou emailovou adresu, na kterou se hlasi bezpecnostni chyby? A spoustu dalsich dulezitych a pricetnych veci.
Ohledně rychlosti vývoje: s tím už tak spokojený nejsem, uznávám, že se to dost vleče – nevěnoval jsem tomu tolik času, kolik bych měl, řešil jsem jiné věci (je to vidět i na historii v Mercurialu, jsou tam dlouhé proluky). Ale když už si k tomu sednu, tak to jde celkem rychle. Brzo si na to zase najdu čas a vydám další verzi.Nedelas nic sloziteho, takze neni duvod, aby to slo nejak pomalu. Akorat bych rekl, ze ostre vic nez 50% casu ti zabralo sepisovani webovych stranek, manifestu, atp.
Unix je právě skvělým příkladem té modulární architektury.Naprosto nepochopils, co jsem ti myslel. Unix ma taky sve rozhrani a to se v prubehu jeho vyvoje, (prekvapive) taky vyvijelo. Nebo si myslis, ze vymysleli vsechno z ciste vody a od te doby na to nesahli? Co kdyby nahodou Ken novym systemovym volanim rozbil Dennisovi nejakou utilitu...?
7.10.2019 13:51
xxx | skóre: 42
| blog: Na Kafíčko
8.10.2019 11:55
xkucf03 | skóre: 49
| blog: xkucf03
ze je to strasne dlouhe, u rady veci chybi argumenty
Tohle jde proti sobě – když přibudou argumenty, tak to bude ještě delší. O každém tom bodu by se dal napsat článek, dohromady by to vydalo na knihu, ale všechno v tom manifestu vysvětlovat do detailů nejde. Jsem si vědom toho, že je to „dlouhé“ a není to finální verze – jeden z cílů je to ještě pročistit, některé věci přesunout do poznámek (ty jsou teď jen ve zdrojáku a ve výstupních formátech jsou skryté). Taky tam chci dát volitelné vizuální odlišení striktních požadavků od doporučení a informací. Zatím si to můžeš zobrazit ručním přidáním CSS stylu:
li.requirement { color: red; }
li.recommendation { color: blue; }
li.information { color: green; }
Tyto ideje by mely byt obecne platne a nadcasove, ma-li mit neco takoveho smysl. … v mnoha zabredava do technickych detailu, ktere mozna za pet deset let budou uplne smesne.
Pokud tam jsou uvedené konkrétní technologie, jsou uvedené jako příklad, aby bylo zřejmé, o čem je řeč a nebyly to jen abstraktní pojmy. Za těch pět let klidně může vyjít verze 1.1, která ponese tu samou myšlenku, ale bude obsahovat jiné příklady, aby to bylo srozumitelné v kontextu té doby. Kromě toho je to psané stylem:
should be provided in RSS/Atom or other machine readable format
to have an e-mail address (but not at particular domain), or use similar decentralized technology which has open standard and free software implementations
Nebo jestli máš pocit, že to je někde moc fixované na konkrétní technologii (a není to jen příklad), tak dej vědět. Ostatně smyslem té verze v0.8 je vychytat podobné chyby.
Zajimalo by me, kolik realne pouzivaneho software vsechna prikazani splnuje.
Bude to hodně projektů pod GNU/FSF nebo pod Apache Foundation, pak i spousta jiných nezávislých projektů.
V zásadě to jsou takové základní dobré praktiky, až je mi trochu trapné je takhle explicitně vypisovat… ale když se pak podívám, čeho jsou někteří lidé schopní, tak vidím, že to explicitně říkat a opakovat potřeba je.
8.10.2019 12:06
xxx | skóre: 42
| blog: Na Kafíčko
8.10.2019 12:12
xkucf03 | skóre: 49
| blog: xkucf03
Ta je právě jedna z nejdůležitějších. S čím tam máš problém? Co ti přijde nesplnitelné?
8.10.2019 12:23
xxx | skóre: 42
| blog: Na Kafíčko
8.10.2019 12:40
xkucf03 | skóre: 49
| blog: xkucf03
Nic z toho neni nesplnitelne, ale spis co ti prijde dulezite? Vzdyt je tam vsude should, takze pokud ho chapu jako v RFC, tak vlastne nevim co si z te kapitoly mam odnest.
Manifest je něco jiného než norma nebo licence. Je to soubor myšlenek, které tě mohou inspirovat a ke kterým se můžeš přihlásit. Pro uživatele a přispěvatele je to pak jisté vodítko a když někde uvidí to logo, tak budou vědět, co tak asi mohou čekat (např. že je to nebude nutit k registraci u poskytovatele nějaké proprietární služby).
Je fakt dulezita domena druheho radu?
K té doméně je tam ještě poznámka (poznámky se zatím do XHTML výstupu negenerují):
But do not buy an internet domain if you are not prepared to mainain it for decades – rather use third level domain under some reliable second level domain maintained by a credible group or person – think of that every expired domain helps spammers and scammers and hurts the users.
Mít stabilní a nezávislou adresu je podle mého důležité. Vázat se na nějakého poskytovatele hostingu je podle mého chyba. Je to podobné, jako když má podnikatel e-mail na Seznamu nebo GMailu. Tam je taky normální a správné mít vlastní doménu a být nezávislý na aktuálním poskytovateli služeb.
Čase se třeba rozšíří nějaká P2P a na kryptografii založená náhrada DNS (resp. ony různé alternativní TLD existují už teď) a budeme používat jiné adresy. Pak bude na místě ten manifest v tomhle aktualizovat, ale ty myšlenky za tím zůstávají pořád stejné. Aktuálně to ale platí tak, jak je to tam napsané – a pěkných pár let to ještě vydrží.
Nebo jako nesmim nutit uzivatele nekam registrovat? Nekam, nebo vubec nikam?
Týká se to proprietárních centralizovaných sociálních sítí a služeb. Což třeba ten e-mail (nebo Jabber) není, protože tam existuje spousta poskytovatelů a uživatel si může vybrat kteréhokoli z nich, a pracuje to na otevřených standardech, ke kterým existuje řada svobodných implementací.
Musim provozovat mailing list?
Nemusíš – jednak je tam should a jednak:
A mailing list (e-mail conference) or other equivalently open and decentralized technology should be used for the many-to-many communication.
vyzadujes bezpecny kanal pro bezpecnostni reporty, ale uz nikde nevyzadujes, aby se nima vubec nekdo zabyval
Ve starší verzi tam bylo ještě pravidlo:
every security incident must be clearly documented and investigated – don't obscure it
což jsem pak vypustil. Navrhuješ to tam vrátit?
8.10.2019 14:28
xxx | skóre: 42
| blog: Na Kafíčko
Tohle jde proti sobě – když přibudou argumenty, tak to bude ještě delšíNejde. Dlouhe je to ve smyslu, ze tech prikazani je moc a misto obecnych principu resi detaily. Komentare jsou dulezite, ale nemusi byt nedilnou soucasti toho manifestu. Srovnej treba s Agile Manifesto.
Pokud tam jsou uvedené konkrétní technologie, jsou uvedené jako příklad, aby bylo zřejmé, o čem je řeč a nebyly to jen abstraktní pojmy. Za těch pět let klidně může vyjít verze 1.1,Lpis moc na konkretnich detailech, u takovych textu je potreba umet abstrahovat a vystihnout myslenku.
Bude to hodně projektů pod GNU/FSF nebo pod Apache Foundation, pak i spousta jiných nezávislých projektů.A dival ses kolik z toho opravdu plni VSECHNA prikazani vcetne pozadavku na kvality kodu, testovatelnost, strojovou citelnost popisu rozhrani, ...?
ale když se pak podívám, čeho jsou někteří lidé schopní, tak vidím, že to explicitně říkat a opakovat potřeba je.A jsi si jisty, ze takto podany manifest je dobre reseni? Vazne kazdy "pricetny" projekt musi plnit vsechna tva prikazani? Ten manifest ani v nejmensim nerozlisuje velikost a specifika projektu, velikost a specifika vyvojoveho tymu, velikost a specifika skupiny uzivatelu. Mozna proto to rade lidi prijde jako korporatni fetisismus...
Tento dokument je spis takove "desatero" plne zakazu a prikazu, ktery musi "pricetny" program splnovat a ktere seslal Buh prostrednictvim Frantiska Kucery na vsechny programatory.Bingo. Třena taový RMS je také prorok. Ale RMS si to může dovolit (do nějaké rozumné míry), protože je autorem/spoluautorem velkého množství věcí v GNU. Ultimátně ten kód v GNU a jeho užitečnost pro praktická použití je to důležité, protože to dává té ideologii něco jako 'reprezentaci v reálném světě' abych tak řekl...
8.10.2019 11:37
xkucf03 | skóre: 49
| blog: xkucf03
Se Suckless máme společný ten odpor ke komplexitě1. Ale je potřeba najít správnou míru. Suckless je extrémismus2, který vede k nepoužitelnosti softwaru a obecně počítačů pro většinu lidí. Cílem Sane software manifesto je zachovat funkcionalitu a komfort na srovnatelné úrovni s tím, co je dnes běžné, ale dělat to příčetným způsobem a předejít těm nejhorším chybám.
[1] komplexita je problém, který podkopává bezpečnost, spolehlivost, udržovatelnost… a minimálně pod ten první odstavec jejich manifestu bych se mohl podepsat
[2] ne až tak z pohledu jejich manifestu, ale z pohledu jejich reálných výsledků
8.10.2019 15:01
Gilhad | skóre: 20
| blog: gilhadoviny
9.10.2019 15:18
Fluttershy, yay! | skóre: 93
| blog:
Přečetl jsem manifesto Františka Kučery, zuřil jsem tak moc, že štěňátka kňučely, mít libky offline někde na disku, manifest hoří v kulatém ohnisku, lokalizace v samostatném balíku, tady ti na to seru, do svého kbelíku, ještě mi pověz o těch gramatikách konfiguráků, ať se ti můžu vysmát fakt do pidičůráků, radši se vyser na termínů slovníček, a pořiď si nějaký teploučký deníček, můžeš si tam zapisovat, učinit jej kronikou, jak jsi koketoval s Kokešovou Monikou, celé to vzešlo z trollhnízďácké farmy na Toru, to už je vidět, že ti dochází šťáva ve tvém motoru, odlož na chvíli relační rouru, už ji máš obtisklou na pinďouru.Konstruktivně: Nehraj si na manifesty, should/might/must a nějaké sane with exception (co to jako je, ty vole?). Uprav to do míň rigidní formy, oprav si ty body začínající spojkou, ať se líp čte, a prezentuj to prostě jako "best practices", kterejch se je dobrý držet, pokud to jde. Pokud to občas doplníš nějakou názornou ukázkou z praxe, třeba javascriptovou demencí s nedeterministickym build systémem, nebo softverem, kterej to naopak řeší dobře, tak to třeba bude stát i za odkaz. Takto ti na to seru do kbelíku!! Sračka je totiž reálný problém. To co tam řešíš ty potká hrstku projektů a je logičtější to řešit až se to aspoň výhledově objeví, ne preventivně každému kbelíku dávat zlaté lemování, kdyby se do něj náhodou chtěl vykadit pan ředitel.
26.10.2019 18:07
xkucf03 | skóre: 49
| blog: xkucf03
Tohle vypadá na zajímavé čtení: Bruce Schneier: Click Here to Kill Everybody.
THE COMPLEXITY OF COMPUTERIZED SYSTEMS MEANS ATTACK IS EASIER THAN DEFENSE
Complexity is the worst enemy of security. The more complex a system is, the less secure it is.DISCONNECT SYSTEMS
We need to start disconnecting systems. If we cannot secure complex systems to the extent required by their real-world capabilities, then we must not build a world where everything is computerized and interconnected. It’s part of what I meant when I talked about engineering security by design at the beginning of this chapter: if we’re building a system and the only way to secure it is by not connecting it, that should be considered a valid option.