Názory k článku OpenAI má zájem o Chrome, vylepšování budoucí KDE Plasmy 6.4.0 pokračuje

Existuje aspoň jeden jediný případ, kdy dává smysl mít v adresáři 2 soubory s názvem třeba config.ini a Config.ini, přičemž každý má jiný obsah a účel? Case-sensitive v názvech souborů (tříd, namespaců, ...) je zlo.

Case sensitive jmena trid a promennych je naopak velmi dulezite. Trida se jmenuje Config a jedina jeji globalni instance se jmenuje config.
V pripade souboru je to diskutabilnejsi, ale od okamziku, kdy je mozne mit v nazvu mezery a utf znaky je ignorovani velikosti pismen v podstate nemozne. V ascii jeste ano, ale nejake velke A s dvema teckama nahore a ocaskem dole, jak ho prevedes bezpecne na jeho lowecase variantu? Kdyz v dobe psani tveho programu tento znak jeste nebyl definovan a je to treba kombinace nekolika kodu (glyf)?

Trida se jmenuje Config a jedina jeji globalni instance se jmenuje config.

Jenže v různých jazycích se to intepretuje různé a je jiná konvence psaní. V Golangu Config znamená, že je to public funkce (struktura, datový typ) a lze jej použít i z jiného package. A config je private a dostupný jen v package, kde je definován.

Já sám na FS uznávám malá a velká písmena jen pro snadnou čitelnost jmen souborů. Ale pro FS to klidně může být tentýž soubor a budu moc rád, když mě upozorní na to, že soubor "Vyúčtování 2024.odt" už tam jednou je a jmenuje se "VYUCTOVANI_2024­.odt". Tenhle úklid vždy jednou za rok dělám manuálně, takže letos jsem takto smazal 3x skeny stejného dokumenty z 2023. Mám scanner napojený na FreeBSD, takže tam používám pouze ASCII znaky bez znaku space. (FreeBSD je pochopitelně plně Unicode, ale mě se to na anglické klávesnici prostě nechce psát česky.)

27. 4. 2025, 11:56 editováno autorem komentáře

Jeste jsem chtel dodat - unix ma od uplneho zacatku case sensitive file system. Linux je Unix. Takze Linux ma case sensitive file system. Jakykoliv pokus pridat do linuxu case insensitive file system je predem odsouzeny k nekompatibilitam a problemum s existujicimi programy.

Ze to ma od zacatku neznamena, ze je to spravne. Jak Linus pise na zaver sveho rantu:

"...Case sensitivity is a BUG. The fact that filesystem people
*still* think it's a feature, I cannot understand..."

:-) ???

27. 4. 2025, 09:54 editováno autorem komentáře

Tomu nerozumím. Jako člověk od fochu bych měl snad chápat, že "a" !== "A" a tečka.
Dělat nějaké výjimky, kde to neplatí, pak výjimky z výjimek... to je cesta do pekel.

podľa mňa väčšna ľudí, čo používa filesystém, nie je od fachu

Jako "člověk od fochu" samozřejmě používám v názvech souborů pouze malá písmena bez diakritiky, čísla, pomlčky, podtržítka a tečky. Holt oldschool zvyk no...

To si nejsem jistý, že je správný výklad vzhledem k tomu co napsal předtím...

"Case-insensitive names are horribly wrong..."

A vzhledem k tomu, že k tomu konci píše, že to je jako FAT (který nemá sensitivitu) to pro mě to byl spíše povzdech, že by se něco takového jako sensitivita nemělo řešit a znak má být prostě znak.

To ale byl "překlep", ze zbytku textu je naprosto jasné, že měl na mysli insensitivity.

Je to ale úplne naopak. On píše že insensitivity je BUG, nie sensitivity... takže naopak case-sensitive je správne. A áno, je to správne. Pretože jednoducho ako tu už bolo spomenuté je tu buď všetko jeden znak, alebo môžeš riešiť výnimku s výnimky a riešiť ako určitú kombináciu spojenú do nejakého znaku ako A s chvostíkom a dvomi krúžkami a neviem čo, prevedieš na malú variantu. Navyše že je to BUG máme už skúsenosť z Windows kde to robí poriadnu paseku pri programovaní (jeden súbor môže byť interpretovaný ako subor.pdf alebo Subor.pdf alebo SUBOR.pdf alebo SuBOr.pdf alebo čokoľvek čo ťa len napadne? Potom ako toto pohandluješ? A ako vyriešiš že keď budeš musieť (a to skutočne budeš musieť) riešiť konflikty lebo case-insensitive jazyk môže mať práve rôzne varianty sensitivity pre identifier.

Už z Windows a NTFS máme skúsenosť aký problém to robí. Len sa pozrí do implementácie trebárs NodeJS alebo Pythonu alebo čo len chceš a pochopíš ako je case-sensitive FS špatná vec. Aneb, keď pre poriešenie tohoto potrebuješ sto tisíc riadkov kódu navyše.

Nie, case insensitive je BUG.

Nerikam co je nebo neni bug, pastnul sem to co Linus napsal do kernel mailing listu. Sam si to tam muzes najit...

GNU/Linux není Unix.

GNU Not Unix ? ;-D

Jen poznámka k tomu vtipu: Stále mě zajímá, kdy projekt GNU bude mít použitelný vlastní kernel a z názvu zmizí ono "/Linux". O projektu Hurd vím, ale vůbec nevím, jestli by šel nainstalovat na aktuální x86 64b Procesor (AMD nebo Intel).

Hmm latest release je 2016. Takže na CPU z roku 2025 to možná půjde nainstalovat, ale o nejnovější instrukční sadě AVX512 v Ryzenech to nejspíš vůbec netuší.

27. 4. 2025, 13:37 editováno autorem komentáře

Paradoxně, to samé Windows NT. Což jsem nějakou dobu nevěděla, a docela mi to zavařilo, když jsem na Windows z Linuxu omylem vyrobila vedle existujícího adresáře "Config" adresář "config". Windows se pak k těm dvěma adresářům chová dost nevyzpytatelně :D

27. 4. 2025, 16:46 editováno autorem komentáře

Na úplně stejný problém jsem narazil na macOs. Dokud jsme měli všichni Linux, nebyl problém. Ve zdrojácích byl adresář Resources a resources. Po git clone na macOs a pár změnách se děly věci :D.

On jde i macOS nakonfigurovat, aby se choval správně. Ale...

Ostatně nebyl by bez toho POSIX. Takže většinou není POSIX.

https://www.osnews.com/story/141633/apples-macos-unix-certification-is-a-lie/

V dávné době se objevila řada situací, kdy se o něčem tvrdilo, že je to case in-sensitive, ačkoliv nebylo. Příkladem je třebas FAT. Těžko říci, zda je nebo není case sensitive. Dovoluje totiž jen velká písmena. Malá písmena do názvů napsat nešlo. DOS zvolil cestu, že malá písmena zadat dovolil, ale automaticky je konvertoval na velká.

Podobně to bylo třebas s case (in)sensitive názvy objektů v Oracle. Prostě se vše konvertovalo na velká písmena. Malá písmena jste do názvu nedostali. Takže ačkoliv to bylo case sensitive, tak se to jevilo jako case in-sensitive. Teprve časem přibyla možnost použít název v uvozovkách, který nic nekonvertuje a tak jste plně case sensitive.

Historie je prostě trochu divoká a plná hacků, které nás dodnes dokáží překvapit (nemile).

Jenze si musis uvedomit, za na tu fatku slo predevsim zapsat jen a pouze ASCII znaky. A ty maji dost jasny prevod mezi malou a velkou variantou.

Legracni to zacne byt az s treba ů ... sem zvedav jak to prevedes na to velky pismeno.

Když hledám nebo chci otevřít soubor config.ini, tak neočekávám soubor CoNfIG.InI. Pak to strašně mate. Identifikátory by se měly jmenovat stejně.

27. 4. 2025, 10:28 editováno autorem komentáře

Ale riesit to vie napriklad priamo aj bash:
nocaseglob - If set, bash matches filenames in a case-insensitive fashion when performing pathname expansion

$ shopt -s nocaseglob
$ ls -d l*
LicBak
license.dat
Lists
Logs
LUTs

Smyl hlavne nedava dat do tak lowlevel mist jako parser jazyka nebo FS neco, co resi case sensitivitu. On svet neni jen latinka a ta zmena sensitivity neni jenom pricteni/odecteni rozdilu A-a.

Nemluve o tom, ze to menit ted, znamena rozjebat vsechno na x roku dopredu.

27. 4. 2025, 12:53 editováno autorem komentáře

Ten problém je i v latince, minimálně v turečtině: https://en.m.wikipedia.org/wiki/Dotted_and_dotless_I_in_computing

Nejspíš ne. Existuje řada nesmyslných způsobů, jak pojmenovat soubor. Víc mi vadí dvě mezery za sebou a chybějící nebo naopak přebývající diakritika.

Tak proč ta fixace na velikost písmen? Proč zrovna tohle se má řešit na úrovni jádra pro něco jiného než legacy kompatibilitu (fat...)? Navíc se podle všeho dnes už ví, že to nejde vyřešit pořádně.

Samozrejme že nejde, najmä keď tu máme písmená zložené z viacerých znakov, potom tu máš znaky ktoré nemajú 2 varianty pre case-sensitivitu (napríklad veľká bodka vs malá bodka) atď... vo Windows to jednoznačne nefunguje a bežne sú tam problémy s týmto. Trebárs taký runtime pre Python alebo NodeJS majú nad prácou s FS ešte wrapper, kde toto riešia a pre NTFS (Windows) tam majú o stovku tisíc riadkov kódu viac a aj tak je na Githubu plno reportnutých BUGov že niečo sa rozbilo.

Ja sa ta spytam ale inak,
Existuje tranformacia a inverzna transformacia jednoznacka?

lowercase -> uppercade -> lowecase
tak aby vzdy za kazdych okolnosti vzniklo to iste?

Kedysi ano, dnes uz nie.

Napriklad:
print('straße'­.upper()) => STRASSE
print('SS'.lower()) => strasse

straße != strasse

A toto je len ceresnicka na dorte.
V dnesnom svete je riesit nieco case insensitive je zahravanie sa s ohnom.

A je to dalsi vektor ku potencionalnych bugom, bezpecnostnych rizik ...

Tak zaverom je mozne akceptovat case insetivite napriekntomu ze neexistuje jednoznacna inverzna transformacia po tranformacij aby sme dostali vzdy povodne (male -> velke -> male) ...

Ja bych pockal az nekdo Linusovi rekne ze treba takova cinstina je case insensitive...

Cinstina nema upper nebo lower case symboly - je to jako arabske cislice - proste jedna forma (pomineme uziti jako horni/dolni index).

Nejen číslice. Arabština nemá ani velká a malá písmena.

A čo, v takom prípade rovnako je to znak... ak bereme jeden znak != iný znak, tak nemusí sa toto nikdy riešiť. Jedno jediné pravidlo, stačí prečítať názov, porovnať stringy a je to celé čo stačí aby bolo jasné že súbor X nie je súbor Y.

Náhodou mít už v jazyku "zabudované", že je insensivite je super. Nejde o počítač, ale o lidi. Odpadá milion problémů - nejen s pojmenováním souborů - prostě config.ini a Config.ini nedáš - ale i názvů všeho možného, všechny ty různé hromady guidelines Builder class vs build instance, neskutečná srágora, tohle odpadá ...

Linus to ještě asi nezmění, ale příští generace operačních systémů - až je bude psát AI pro svoje účely - bude možná primárně v arabštině, čínštině nebo prostě v něčem case insenstive. Nebo spíš možná rovnou v bináru - 0,1. Co bude AI do lidí :-)

Nesúhlasím. Je tu xyz dôvodov prečo to dokonca môže byť veľký problém. Napríklad slovo vs skratka zložená zo stejných písmen má 2 úplne iné významy a ty to budeš musieť nejak rozlíšiť. Ak to hovoríme na úrovni "user interface". Ale inak nedáva zmysel aby bol case-insensitive. FileSystem musí byť vždy case-sensitive, inak to vedie len k problémom... v programovaní existuje jeden princíp volá sa "KISS" aneb Keep it Simple, Stupid. A jednoduché je ak máš jednoducho pravidlo že 2 zhodné reťazce = stejný názov a 2 zhodné reťazce... ak by sme mali "subor.pdf" a "SUBOR.pdf" to sú už rozdielne reťazce. Vždy to tak bude, už z princípu.

27. 4. 2025, 21:33 editováno autorem komentáře

není to super. když je něco case sensitive, chce to config.ini a ty tam cpeš CONFIG.INI, tak tě to seřve, jak malýho kluka, že tam prostě ten správnej soubor nemá, ty to napravíš a navždy to bude fungovat.
Naproti tomu, když to máš case insensitive, tak to možná bude pěkně fungovat s config.ini a CONfig.ini, ale ve složitějších abecedách se začnou kupit výjimky, výjimky z výjimek, rozdíly mezi systémy a jednotlivými implementacemi.
A najednou to někdy a někde fungovat bude a někdy a někde ne. A to je mnohem víc nahovno, protože jakýkoli hledání chyb je pak složitější, přináší to nečekané problémy (dělá to jen někdy), navíc se ti to bude měnit pod rukama, protože si někdo vzpomene, že chce přidat pár dalších písmenek nějaký další abecedy a zase ti něco někde nebude fungovat, jak by mělo.
Když se jednou zařídíš podle toho, že CoNFiG != config, tak ti to od tý doby všechno a všude funguje. Pokud ne, tak ses spletl ve velikosti písmen, opravíš a jedeš.
Navíc v nějakejch low power embeded systémech asi fakt nechceš nějakej moloch který řeší, jestli je naše velký měkký I stejný jako malý i ale odlišný od malého ı, a jak je to s velkým dotless I, jestli je stejné jako naše I a jak je to případně s velkým İ s tečkou. Je prostě daleko jednodušší říct, že jsou to vše odlišné znaky a hotovo. Souborový systém není beletrie, jde pouze o to, jak najít nebo nenajít konkrétní soubor s daty.

Jenze ty to resis uplne jinde nez je to resit treba.

Vezmemez tvuj post, proc by v databazi mel byt jako casesensitive? Necht databaze zbavi ten text nabodenicek a ulozi to vsechno jako velka pismena.

Fs neni nic jinyho nez specificky druh databaze. A minimalne presne v okamziku, kdy nekdo akceptoval, ze se nazvy budou psat s nabodenickama, tak proste musi zarove akceptovat, ze budou case sensitive.

Zajimavy je, ze ty databaze nasledne nemaji vubec zadnej problem v tom, ze kdyz to tazatel chce, muze ten dotaz (pokud to dava nejakej smys) poslat v rezimu bez nabodenicek a bez case ze? Ale ta databaze porad vi, ze tam ma 100x totez, jen s jinak velkejma pismenkama.

Náhodou mít už v jazyku "zabudované", že je insensivite je super. Nejde o počítač, ale o lidi. Odpadá milion problémů - nejen s pojmenováním souborů - prostě config.ini a Config.ini nedáš - ale i názvů všeho možného, všechny ty různé hromady guidelines Builder class vs build instance, neskutečná srágora, tohle odpadá ...

Přesně tak. Case-sensitive FS je jen výsledek zjednodušení celé problematiky (neboli lenosti), které neodpovídá realitě. Takový mezikrok - chci to (FS) pro lidi (human-readable jména), ale jsem línej to implementovat pořádně... neboli klasický nerdovský přístup.

Za mňa je bug dovoliť vytvorenie 2 súborov, ktoré sa líšia len case v nejakom znaku. Z toho môžu byť len problémy, nie je to blbuvzdorné, pre používateľa nezmyselné a niekedy to môže byť nebezpečné. Ak nejaký systém podporuje unicode znaky tak potom by mal obsahovať aj nejakú unicode knižnicu a prevod case nemôže byť problém.

A čo v prípade ak máš slovo a skratku zloženú zo zhodných znakov ako to slovo? To nebudeš rozlišovať? Ešte aj v jazykoch (teraz myslím Angličtinu, Slovenčinu, Češtinu a pod, nie prog. jazyky), rozlišujeme veľké a malé písmená. Vždy sa to musí nejak rozlišovať. Jedine že by sme zmenili jazyk a zrušili veľké písmená úplne.

Prostě v takovém případě samozřejmě ty soubory pojmenuju jinak. Prostě nebudu ukládat vedle sebe 2 soubory, které se liší jen velkým/malým píesmenem. Je úchylné něco takového dělat. A když to někdo udělá ještě navíc schválně, tak by to měl být trestný čin :)

A teraz si predstav, ze tam niekto ulozi subor s NFKC a niekto s NFKD a teraz zistuj ci su to rovnake nazvy.

Sa vratme k suborom 8+3 7bit ASCII a bude po probleme.

rozlišovať ako to je vo Win áno, ak vytvorím súbor HelloWorld, tak sa case zachová, ale keď skúsim varobiť v rovnakom adresári helloWorld, tak dostanem chybu, že už existuje

Ked citam komentare musim aj ja pridat komentar.

Zoberme si to po poriadku. Ked si zobereme programovacie jazyky C, C++, C#, Golang, Rust, Python, Java, Javascript, LUA, PHP, Ruby, Perl, TypeScript atd atd

Si mozete vsimnut ze to je case-sensitive.

Nevidim ani jeden dovod, preco si komplikovat u nazovoch suborov a adresarov robit zbytocnu robotu a pridavanie dalsieho vektoru moznych chyb, bezpecnostnych rizik tym aby som mal nazvy suborov a adresarov case-insensitive. Je to nieco co je uplne zbytocne a nelogicke.

Vratme sa do minulosti. Vratme sa do doby kedy sme mali len ASCI a to ASCI bez diakritiky cize len 0-127 . Tam sa to riesilo jednoducho tam si len jeden u jedneho bitu zmenil hodnotu. Cize podmienka ORD > 64 and ORD < 91 and ORD > 96 and and ORD < 123 , tymto si podmenil a-zA-Z.

Nasledne siesty bit urcoval velkost pismena. Ak bola logicka 1 tak male pismeno aj 0 tak velke pismeno.

Takze takze nebol problem spravit podmenku ORD > 64 and ORD < 96 a nasledne bitovovy operaciu alebo jednoducho pricitame 32 cize chr(ord(b)+32) kde b je pismeno. Toto si potom daj do cyklu. Takto jednoducho sa riesilo kedysi ako v pythone string.lowercase()

U starych suborovych systemov kde si bol na nazov suboru limitovany ASCI 0-127 tak to nevadilo. Ale kedze mozeme do nazvu suboru pridat znaky z Unicode tak to problem.

Dnes? To uz je alchymia. Uz sa nemozes spolahnut rozdielom 32 (jedneho bitu) tato vlastnost sa nezdedila. Okrem zpetnej kompaktibility A-Za-z tam ti plati.

Musis mat databazu pomocou ktoreho robis prevod. To ale neni problem. Dnes kedy uz nemusime pocitat kazdy jeden byte, kazdy jeden strojovy cyklus toto nevadi.

Problem ale nastava ze existuju pismena s diakritikou, ktore nemaju svoj naprotivok vo vztahu (male - velke alebo naopak). Tak nikdy nespravis prevod spolahlivo. Na vacsinu pripadov ano, ale nie pre vsetky pripady.

A to este nehovorim ze v unicode mame pisme ktore vyzeraju velmi podobne ako klasicke A-Za-z z asci ale maju svoj vlastny unicode a nemaju naprotivok. Cize aj sme prevod aproximovali na A-Za-z tak pri zpetnej transformaci sa nedostaneme na zaciatok. Cize stratime co za pismeno to bolo.

a mohol by som este pisat dalej.

Ale tu je jasne vidiet ze case-sensitive je akysi prezitok z minulosti u ktoreho sa zistilo ze to vytvara omnoho viacej problemov ako uzitku, obzvlast ked si v nekontrolovanom prostredi ako uzivatel a jeho pomenovanie a umoznenie do nazvov suborou cpat znaky z unicode.

To, že niektoré programovacie jazyky sú case sensitive ako súvisí s filesystémom? Názvy domén sú case insensitive a majú bližšie k filesystému ako programovacie jazyky. Súbory používajú normálni ľudia a dva súbory s rovnakým názvom spôsobia len problémy a diktovať niekomu názov súboru s špecifikovaním pri všetkých písmenách či sú veľké, alebo malé nie je úplne prakticé. Case sensitive súbory sú len vecou lenivosti, alebo neznalosti programátora, existujú knižnice ako ICU (príčetná implementácia FS musí predsa aj tak vedieť zložitejšie veci, aby vedela zoradiť názvy podľa abecedy) a ak pre nejaký znak neexistuje capital varianta, tak to predsa znamená, že s ním nie je žiaden problém, lebo ho netraba nijak transformovať.

Na to aby si to mohol pouzivat musi byt aj naprogramovane. To ze to ty neprogramujes neznamena ze to niekdo pre teba neprogramoval a mas program.

Dalsia vec neexistuje jednoznacna transformacia v celom rozsahu male -> velke -> male

napriklad:
print('ß'.upper()) da na SS
print('SS'.lower()) sa ss

ß != ss

Ako som pisal vznika zbytocny priestor na bugy a ked vdaka bugu pridas o data to ti uz bude vadit

a toto co pisem je len ceresnicka na dorte kolko s tym je problemov a nemusi to byt.

Tu nejde o prikazovani. Ale o chybach, bugoch, necakanych chovaniach , vektory utoku atd.

Zbytočne hľadáš problém, všetko musí niekto naprogramovať. Ako dokázali spraviť find -iname? Aj pri tých doménach to nejak museli vyriešiť. Na overenie jedinečnosti názvu súboru nepotrebuješ prevod veľké>malé>veľké. Stačí napr. hocičo>malé. A ešte aj z toho môžeš spraviť hash pre zrýchlenie nejakého indexu. Vektor útoku je akurát keď si spravíš skript RunMe, nastavíš mú práva na seba a potom niekto iný spraví Runme a omylom spustíš Runme.