11 technológia, ami Linusnál kiverte a biztosítékot

Linux

Linus ismert arról, hogy véleményét nem rejti véka alá. A Linux kernelfejlesztés első embere az elmúlt két évtizedben bőven osztotta a kritikát. A legemlékezetesebbeket szedte egy csokorba az IT World. 11 technológiai dolog, amitől Linusban felment a pumpa:

  • GNU Emacs
    • “... an infinite number of monkeys typing into GNU emacs would never make a good program.” 1995

    • “... [Emacs is] the most gummed-up piece of absolute sh*t there is! December 17, 2008

    • “... real emacs... is the tool of the devil” July 11, 2012

  • GNOME
    • “... the reason I find GNOME limiting is BECAUSE IT IS.” February 16, 2007

    • “I have yet to meet anybody who likes the unholy mess that is gnome-3.” August 2011

    • “... the whole gnome3 approach of ‘by default we don't give you even the most basic tools to fix things, but you can hack around things with unofficial extensions’ seems to be a total UX failure.” June 1, 2012

    • “Gnome seems to be developed by interface nazis….” December 12, 2005

  • HFS+
    • “... OS X in some ways is actually worse than Windows to program for.  Their file system is complete and utter crap, which is scary." February 2008

    • “The true horrors of HFS+ are not in how it's not a great filesystem, but in how it's actively designed to be a bad filesystem by people who thought they had good ideas.” December 23, 2014

    • “Quite frankly, HFS+ is probably the worst file-system ever. Christ what shit it is.” December 22, 2014

  • Java
    • “Essentially I see the Java engine just slipping, not going anywhere.” August 1998

    • “[Java] has lost much of its potential, partly because of the way Sun Microsystems has handled it.” April 1999

    • “Java, I don’t care about. What a horrible language.” November 2011

  • GNU Hurd
    • “I think Hurd is dead. ... It has a ‘big vision’, and people forgot about the details, and forgot about admitting when they went wrong.” October 2004

    • “... Hurd isn't really a microkernel, it's an abomination that makes all other microkernels look bad.” May 15, 2006

    • “In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people.” October 4, 2001

  • C++
    • “The fact is, C++ compilers are not trustworthy. … the whole C++ exception handling thing is fundamentally broken.” January 19, 2004

    • “C++ is in that inconvenient spot where it doesn't help make things simple enough to be truly usable for prototyping or simple GUI programming, and yet isn't the lean system programming language that C is that actively encourages you to use simple and direct constructs.” September 7, 2007

    • “C++ is a horrible language.” September 6, 2007

  • Mach
    • “My personal opinion of Mach is not very high. Frankly, it's a piece of crap. It contains all the design mistakes you can make, and even managed to make up a few of its own.” 2001

    • “I claim that Mach people ... are incompetent idiots.” April 20, 2006

  • GCC
    • “For chrissake, that compiler [GCC 4.9.0] shouldn't have been allowed to graduate from kindergarten.” July 24, 2014

    • “Gcc is crap.” November 28, 2006

  • XML
    • “[XML] is probably the worst format ever designed…. it really doesn't scale as a file format, and it's generally a complete disaster.” March 6, 2014

    • “XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist.” March 6, 2014

  • Solaris
    • “A lot of people still like Solaris, but I'm in active competition with them, and so I hope they die.” February 2005

    • “Solaris/x86 is a joke….” December 2004

  • MINIX
    • “Your job is being a professor and researcher: That's one hell of a good excuse for some of the brain-damages of Minix.” January 29, 1992

    • “... linux still beats the pants of minix in almost all areas.” January 29, 1992

A részletek itt olvashatók.

( mn3monic v | 2015. 01. 27., k – 14:17 )

Any programming language that you don't understand will be a horrible language for you, Mr. Crapvalds

( forsaken | 2015. 01. 27., k – 14:26 )

Kicsit nagy az arca és piszkos a szája.

( forsaken | 2015. 01. 27., k – 14:29 )

Eléggé szélsőséges megnyilvánulásai vannak. Ha nincs ő, akkor a most linuxot heggesztgető emberek megtalálják a mach-t, vagy a Hurd-öt.

Más: kicsit elavultnak érzem a posix root filesystem koncepciót.

Szerintem a tökéletesen egységes fájlrendszer, ahova tökéletesen transzparens módon tudsz felcsatolni eltávolítható és távoli fájlrendszereket nem elavult. Az hogy C:\, D:\ meg egyéb betűjeles meghajtóid vannak, inkább elavult (C/PM).

--
arch,centos,debian,openelec,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

ellenpélda: ubuntu alatt viszont mindent magyarítanak, így nem lehet értelmesen semmire se keresni a dash-ban.
Ki is kapcsoltam a p*csaba.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

De amikor azt utod be, hogy "screensho", akkor csak magyarul adja vissza, hogy "Képernyőkép".
Nem pedig csak angolul, vagy angolul es magyarul.

Milyen kolto?:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nekem egy default login idecsesz vagy 7-8 darabot ami valami global IT cucc. (Az más kérdés, hogy minek). Ha nem total commanderből cdznék az effektív használt vackokhoz, simán lenne még vagy 5, plusz még ez az. Szóval azért nem olyan rettentő sok. Illetve értem én, hogy lehet mountolni, de arról volt szó, hogy a betűjelezés bad design, meg elavult. Azon nem segít, hogy lehet csatolni is.

De egyébként csak annyit akartam mondani, hogy pendrive példa azért erősen kamu volt.

Ja, es nem akarok olyasmibe ugatni amihez nem ertek (az eletbe se hasznaltam OSX-et) de akkor ezek szerint az OSX fajlrendszer kezelese is elavult. Sot igazabol a vilag nagyobbik resze ilyen, csak a Windows nem. Ugye? :)

--
arch,centos,debian,openelec,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

gugliztam kicsit, mert kivancsi lettem hogy mi ez a brutalis kirohanasa a HFS+ ellen, talaltam is egy cikket ami pont Linux velemenyet elemzi, illetve bovebben ideznek tole
abbol az jott le hogy ket baja van vele: az hogy nem case-sensitive (siman lehet arra is formazni HFS+-t, egyszeruen azt kell kivalasztani a lenyilo comboboxbol), es valami unicode-os problema (ez utobbiba nem mentem bele melyebben)

vagyis ezek alapjan nem is a filerendszerrel illetve annak az alacsonyszintu megvalositasaval van a baja, hanem a filenevek tarolasaval/kezelesevel...

Bárcsak tartanánk már ott, hogy a számítógépek képesek felismerni, hogy a kisbé valójában ugyanaz, mint a nagybé.

Na igen, mert pl. pont a makkosiksz által favorizált Private Use Areas-nál [lásd: http://sambaxp.org/fileadmin/user_upload/SambaXP2014-DATA/wed/track1/Ra…, 13. dia] pl. olyan marha könnyű eldönteni, hogy mi upper/lower case...

Amúgy meg... azért ha valahol, hát pont a windowsnál/NTFS-nél vannak ALAPVETŐ gondok a fájlrendszerkezeléssel, ha egy rendszer az alap ASCII-t képtelen használni a fájlnevekben (?*|, a többi móka, fenti előadás 12 dia...), akkor ne az legyen már az etalon...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Öööö, ja, az. Én pl. a doksiaimat szeretem a címük alapján elnevezni, nem a címük-minusz-azok-a-karakterek-amiket-nem-hasznalhatok (és igen, szükséges rossz, hogy így path separator nem szerepelhet a fájlnévben, de az ritka). Viszont előferdül hogy mondjuk kettőspontot használok címben. Vagy kérdőjelet. Vagy...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Én arra a változatos szélességű Unicode szóközöket szoktam használni, általában a standard ASCII szóközre szoktak figyelni (mármint nem enged csak azt tartalmazó kitöltést), de pl. egy mathematical space-re már nem :)

Szerk.: Újabb szivatás: egy mappában a fájlokat úgy elnevezni, hogy mindegyik egy-egy unicode szóköz nevű :) Plusz pontért kiterjesztést is lehet uniformizálni...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

loremipsum@loremipsum-suse:~> mkdir teszt
loremipsum@loremipsum-suse:~> cd teszt/
loremipsum@loremipsum-suse:~/teszt> echo "foo-1" > foo-1.txt
loremipsum@loremipsum-suse:~/teszt> echo "foo-*" > "foo-*.txt"
loremipsum@loremipsum-suse:~/teszt> ls -la
összesen 24
drwxr-xr-x 2 loremipsum users 4096 jan 28 10.01 .
drwxr-xr-x 82 loremipsum users 12288 jan 28 10.01 ..
-rw-r--r-- 1 loremipsum users 6 jan 28 10.01 foo-1.txt
-rw-r--r-- 1 loremipsum users 6 jan 28 10.01 foo-*.txt
loremipsum@loremipsum-suse:~/teszt> rm -rf "foo-*.txt"
loremipsum@loremipsum-suse:~/teszt> ls -la
összesen 20
drwxr-xr-x 2 loremipsum users 4096 jan 28 10.02 .
drwxr-xr-x 82 loremipsum users 12288 jan 28 10.01 ..
-rw-r--r-- 1 loremipsum users 6 jan 28 10.01 foo-1.txt
loremipsum@loremipsum-suse:~/teszt>

Egyébként jó, a csillagot ne számítsuk. Kettőspont?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Fun:
Szórakoztam és találtam egy kis "bugot" (vagy minek nevezzem - inkább érdekesség), aminek ugyan semmi jelentősége nincs. 


I:\k>echo tesz1 >teszt-1.txt

I:\k>echo tesz* >"teszt-*.txt"
A fájlnév, a könyvtárnév vagy a kötetcímke szintaxisa nem megfelelő.

I:\k>copy con "teszt-*.txt"
zzz^Z
        1 fájl másolása történt meg.

I:\k>dir
2015.01.28.  11:30    <DIR>          .
2015.01.28.  11:30    <DIR>          ..
2015.01.28.  11:30                 3 teszt-.txt
2015.01.28.  11:29                 8 teszt-1.txt
               2 fájl                11 bájt

Sőt, a copy con-nak ehhez még idézőjel sem kell :)
(persze egy del "teszt-*.txt" gyalulja mindkettőt)

Ne kattints ide!

ADS címzésnél van használva: Practical Guide to Alternative Data Streams in NTFS.

Ez jól hangzik, leszámítva, hogy FAT-re is érvényes (a poén kedvéért feldobtam egy DOS 6.22-t, arra is ;) ), aminek köze nincs az ADS-hez.
Egyszerűen egy korábbi (igen, CP/M korú) tervezési hiba (driveletter, nem egységes névtér, ":", mint drive separator...) miatt volt nekik "szabadon" erre egy karakterük, ezért ezt választották.

Ext4-en sem használhatsz / jelet a fájlnévben.

Jaja, fentebb/lentebb írtam is, hogy a path separator-t sajnos nem lehet elkerülni, de 1 (pontosabban kettő, null bájt és /) vs. a fenti amúgy gyakran előforduló lista hossza...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

valobal lehet case-sensitive-re formazni, viszont egy csomo progi meghal vele (adobe appok, parallels stb.)
unicode issue meg elegge valos, volt olyan hogy nemet umlautos fileneveket szepen megjelenitette a finder, a terminal mar elrontotta oket viszont ha ez egy git repoban volt akkor teljesen kezelhetetlenne tette. (git azt hitte hogy uj file, de amikor megprobaltad torolni vagy committelni semmi sem tortent - mert ugye a file mar letezett es nem is valtozott. az egyetlen megoldas az volt hogy kivulrol valaki kiszedte a spec karaktereket a filenevbol, pusholta a repoba es a kovetkezo pull megjavitotta. mac-rol teljesen eselytelen volt barmit csinalni vele)
lenyeg hogy api szinten van elcseszve a file kezeles.

en Linux alatt is talalkoztam nagyon hasonlo problemakkal (az eleg alap mar 10+ eve hogy terminalon mashogy nez ki ugyanaz a filenev mint GUIn, bar az utobbi idokben az UTF8 mar kezdi megoldani)
bar nalunk az SVN azt produkalta az umlautos filenevvel, hogy nem volt hajlando kicsekkolni a file-t a repobol egyaltalan :D

"valobal lehet case-sensitive-re formazni, viszont egy csomo progi meghal vele (adobe appok, parallels stb.)"

Valaki mondjon már legalább _EGY_ valós, igényt arra, hogy hol, kinek és miért van _szüksége_ a case sensitive FS-re.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

_szüksége_ valószínűleg senkinek nincs, mert az algoritmikus eldönthetőség határáig bármi körbetaknyolható, de van olyan helyzet, hogy case sensitive azonosítót akarsz fájlrendszerre leképezni "bohóckodás" (pl. a leképezés külső tárolása stb.) nélkül; és ilyenkor szarul tud esni, hogy egy kifelejtett "létezik-e" vizsgálat miatt szépen felülütöttél egy másik fájlt, mert bár az azonosítójuk nem egyezett, a fájl/oprendszer szerint de.

De egy példa: youtube-dl --id opcióval...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Eeeh... jogos lehet, de azt azért vegyük hozzá, hogy egy adatbázisban tárolt random ID és egy (sokszor nominális jelentésű) címke (fájlnév) nem ugyanaz.

Ha a valaki olyan workflow-t épít, ahol "Fájl1" és "fájl1" egymással nem függ össze, ott azért bajok vannak. :)

Arról nem is beszélve, hogy szokjunk már le a "csinálok naponta százezer darab <4 KB-s fájlt, ugyan mi baj lehet" című történetről, mert ezek miatt lesz ilyen:

http://hup.hu/node/72761
http://hup.hu/node/135048

Aztán lehet sírni, amikor hozzá kell nyúlni, csak akkor meg már ugye mindegy.

Az adattárolás történet ott indul, hogy van egy random access tárterületünk, ahol meg kell találnunk a számunkra szükséges információt. Erre szolgál a fájlrendszer is, meg az adatbázis-szerver is. Sőt, ha az adatbázisszerver nem "nyers diszken" tárolja az adatait, hanem egy fájlrendszeren, nagyméretű fájlok formájában, (legyen az akár 1 fájl/tábla, vagy éppen journal felépítésű) akkor a helyzet alapjaiban véve az adatbázis-szerver számára még rosszabb, hiszen még egy köztes rétegen (a fájlrendszeren) is át kell vergődnie magát.

A kulcs az, hogy az SQL szerverben vannak olyan rutinok, amik némiképpen hatékonyabbá teszik az adatok megtalálását, lásd célirányos indexelés.

Azonban, ez nem jelenti azt, hogy ne lehetne implementálni egy olyan fájlrendszert, ami legalább olyan hatékony, mint egy SQL szerver. Emlékeim szerint a Microsoft is emlegetett valami hasonlót, talán WinFS néven.

Úgy egyébként azt nem gondolom, hogy SQL-szerver komplexitású filerendszer-kódot kellene beledrótozni a kernelbe, viszont a "sok kis fájl" problémakörét igencsak lehetne hatékonyabban kezelni fájlrendszer szinten.

Azokra vadaszati engedelyt kellene kiadni. Volt dolgom ilyen fejlesztovel, tonnaszam fogyott az inode a diszken, es otletem se volt, miert. Aztan ratalaltam Az Adatbazisra. Tobb tizezer fajl, 1 es 20 bajt kozott.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Hogyan is jutottál erre a következtetésre? Számomra annyira triviális, hogy csak annak van értelme, hogy nem is tudom hová tenni a kérdést, ezért kérdeztem (és én kérek elnézést, hogy előbb kérdezek ha valami nem tiszta és csak utánna jár a kezem/szám/whatever). Igazából nem case sensitive FS-re van szükség, hanem arra, hogy aminek elnevezem a filet, annak az legyen a neve bötűről-bötűre. Mivel emberek is olvassák a fájlnevet, és az emberek használnak kis és nagybetűket különböző célokból (sajna nincs statisztikám az emberiség hány százaléka tesz különbséget kis és nagybetű között aktív kommunikációja során), alapvető elvárás, hogy az emberek a megszokott formában nevezhessék el fájljaikat.
-
Változékony Grails alkalmazás konfiguráció facepalm

Kell annál valósabb igény, hogy az FS-eket úgy általában embereknek csinálják, akik írott formában hajlamosak kis és nagybetűk megkülönböztetésére, és lévén a fájlnév írott szó/szavak halmaza, pont az a fura, ha nincsen megkülönböztetve??

-
Változékony Grails alkalmazás konfiguráció facepalm

Ebben szerintem akkor lenne igazad, ha pld. lenne jelentés és tartalombeli különbség pld. a leírt "asztal", "Asztal" vagy "ASZTAL" között. Az egyszeri usert meg a sírba lehet vinni egy hosszú állománynév esetén a case-sensitive tulajdonsággal. (Pld. III.8 Igazgatósági Beszámoló a Költségekről és Tervekről.doc vs. III.8 Igazgatósági beszámoló a költségekről és tervekről.doc - tutira össze-vissza fogja szerkesztgetni mindkettőt (vagy csinál még belőle vagy 6 változatot más nevekkel), aztán csak les, hogy hol vannak a módosításai.

(Ha tulajdonnév az Asztal, akkor van különbség a jelentésben, mert egy személyről és egy tárgyról van szó, de az aki egy könyvtárban akarja tárolni Asztal Antal és egy asztal infóit, és úgy tesz különbséget, hogy a személy Asztal.txt, a tárgy meg asztal.txt... hát annak egészségére :) )

Ne kattints ide!

Igen, csak aztan ugyanezek az emberek problemaznak azon, hogy semmit nem talalnak meg, mert elfelejtettek, hogy akkor most kis vagy nagy F volt az a fajl. Egy case insensitive vilagban (Windows) ezzel nincs problema.

Amikor az emberek a "kisnyuszi12" tipusu jelszavaikat felejtik el, akkor nehogy mar egy gilisztanal tobb ertelemre keszuljunk fel a human interakciok teren...
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A case-insensitive FS-sel az a baj, hogy nyelvfüggő melyik kisbetűnek melyik nagybetű a párja. Lásd: https://msdn.microsoft.com/en-us/library/ms994325.aspx#cltsafcode_topic4
Ez azért vezethet problémákhoz, ha török oprendszerből viszel át fájlokat más latin abc-t használó oprendszerbe, és a kis-nagybetű különbség figyelmen kívül hagyása miatt egyik oprendszerben ütköznek a fájlnevek, másikban nem. Megoldás lenne, ha minden fájlhoz vagy fájlrendszerhez el lenne tárolva, hogy milyen nyelven lett létrehozva, de szerintem sokkal egyszerűbb és logikusabb a case-sensitive fájlrendszer használata.

Vagy te hogy oldanád fel a problémát case-insensitive esetben?

A filerendszernek nincsenek "problémái", a felhasználóknak vannak ha szar a filerendszer.
Török nyelven, case insensitive módon ezek különböző fájlnevek: "I.txt", "i.txt", ezek ugyan azok: "I.txt", "ý.txt".
Angol nyelven, case insensitive módon ezek különböző fájlnevek: "I.txt", "ý.txt", ezek ugyan azok: "I.txt", "i.txt".

Aztán mehet a szívás, hogy éppen milyen nyelven történik a komparálás, és miért pont olyanon.

( tonnmx | 2015. 01. 27., k – 15:00 )

Az emacs kommentjeidhez, Linus: C-x C-c

Szép napot! :)

Egy általános célú szövegszerkesztő, ami modulokkal bővíthető.
Erre dobják rá 40 éve a funkciókat úgy, hogy nem kell egerészni semmihez.
Ezért a rengeteg billentyűzet kombináció.

A használatáról annyit, hogy egy idő után készség szinten fognak menni az általad leggyakrabban használt funkciók kombinációi. Ekkor már ha bármi mást kell használnod, akkor azt primitív, korlátozott, rugalmatlan sz@rnak fogod találni.

Oke, de az alap parancsokat, for example, a kilepest megoldhattak volna egy darab leutessel is, pl. C-q. Oke, mielott megint jon a saxus-fele hup okossag: atkonfiguralhato. Nevermind.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( csearo | 2015. 01. 27., k – 15:14 )

Nna, 12 egy tucat, pótlom kedvencemet: a hírhedt CVS+SVN-fikázós elborulását. :)

L.T.> "When I say I hate CVS with a passion, I have to also say that if there any SVN users (Subversion users) in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was 'CVS done right' or something like that. And if you start with that kind of slogan, there is nowhere you can go. It's like, there is no way to do CVS right."

Szerk.:
L.T.> "If you like using cvs, you should be in some kind of mental institution or somewhere else."

:wq

Hadd kérdezzem már meg, hogy láttál-e már nagy* projektet Git-ben, illetve SVN-ben? Szerintem próbáld ki, utána majd beszélhetünk róla, hogy melyiknek jobb a branch-kezelése. ;)

* nagy projekt = 10+ dedikált, fulltime fejlesztő

Láttam. Több csapat, mindegyiknek saját branch, periodikusan merge* a main line-ba. Láttam ilyet SVN-ben és TFS-en is. Fájdalmas, ha nem git vagy Mercurial a SCM.

Én kérdezek: cherry-pick? Mit használsz helyette SVN-ben?

*: nem klasszikus merge, cherry-pick a kész fákból.
--
http://naszta.hu

Peldanak okaert van olyan projectem (es mielott meg valaki megjegyezne, hogy en vagyok a hulye, rajtam kivul mas hulyek is jutottak hasonlo eredmenyre, szoval legalabb nem vagyok egyedul) ahol a workflow az, hogy van egy jatszos branch, ami soha, semmilyen korulmenyek kozott nem fog semmire mergelodni, mert jatszos branch, kiserletezesre. Viszont neha kiserletezes kozben az ember kijavit egy hibat - hat szepen becommitolja, majd jatszik tovabb, es valamikor kesobb csinal egy dedikalt branchet a hibanak, ahova szepen at cherry-pickeli a korabbi javitast.

Erre kivalo a cherry pick, mert nem kell megszakitani a munkat. A jatszos branchet meg kesobb ugyis rebaselem, igy nem faj, hogy cherry picknel megvaltozik a commit id.

Egyszeru, nagyszeru, es kenyelmes.

--
|8]

Persze, az ezer pedig még nagyobb, de valójában valahol 5 ember körül van az a lélektani határ, amikor a workflow-nak már elkezd érezhető overheadje lenni.

Imho 2 és 10 fejlesztő között sokkal nagyobb a különbség overheadben, mint tíz és száz vagy száz és ezer között.

Pontosan milyen overheadre gondolsz?

Mi most éppen kb. 30-an dolgozunk egy terméken (változó, az aktuális fejlesztés igényeitől függ), és baromi jó a workflow. Van overheadje, főleg adminisztráció (code review, issue lifecycle stb.) de ennek az overheadnek vannak előnyei. Sok-sok évre visszakereshető issue tracking, ki mikor mit és miért csinált, miért az szerepel a kódban, ami és hol lehet utánanézni a dolgoknak.
Aki overhead nélkül akar programozni, az impliciten épít arra, hogy "úgyis emlékezni fogok rá, hogy ez miért van". Aztán amikor bejön egy bug 3 év múlva, akkor meg néznek, hogy mégis hogyan és miért van az úgy ("jha, azt még a Laci csinálta, de már nem dolgozik itt, nem tudom miért úgy van").
És ez 5 embernél, meg 100 embernél is ugyanúgy fontos.

Ezt honnan veszed? Voltál már 100 fős R&D-ben?

10 fő még éppen elfér egy sprint teamben, tudnak koordinálni, mindenki tudja min dolgozik a másik, nem gáncsolják el egymás munkáját.

100 fő esetén ez esélytelen, ott bontani kell több teamre, és a feladatot is nagyon szét kell osztani. Egy trunk-on dolgozva folyton azzal fognak szopni, hogy az egyik csapat munkája miatt átmenetileg törnek a tesztesetek, emiatt a többi csapat nem tudja ellenőrizni, hogy jó-e amit commitolni akar. Ilyenkor egyes iskolák szerint szigorú commit tilalom kell hogy életbe lépjen, amíg a tesztek ki nem javulnak. Emiatt csomó ember feleslegesen várakozni fog. Ugyanakkor azt praktikusan nem lehet megcsinálni, hogy addig tilos a commit, amíg nincs 100%-ra rendben az összes teszt, mert így meg nem lehet együtt dolgozni egy feladaton. 10 főnél még bontható a feladat akkora darabokra, hogy egy kódrészen max 1-2 ember dolgozik egyszerre (2 mondjuk pair programmingben), akkor nem kell kódot szinkronizálni a gépek között, ez a probléma kikerülhető.

Nagy létszámra az egyetlen értelmes kiút az, hogy a teamek egymástól független brachekben végzik a saját feladatukat és csak akkor pusholnak a fő branchbe, ha legalább annyira készen vannak, hogy a tesztek rendben lefutnak. Persze lehet próbálkozni SVN-nel is, de azért... hát nem az igazi.
---
Régóta vágyok én, az androidok mezonkincsére már!

Nem azt mondtam, hogy 10 és 100 fő között nincs különbség, hanem hogy van, de kisebb.

De arról beszélsz, hogy 10-100 váltáskor már konkrét módszertanok közti különbségről beszélsz, míg a gyakorlat azt mutatja, hogy 2-3 fős projektekben legtöbbször egyáltalán nincs semmilyen módszertan. Ami persze nem jó, csak nehéz vele mit kezdeni.

Nem mondom, hogy teljesen univerzális a tapasztalatom, de én átéltem mindkettőt. Az 2-3 fős projektről ~10-re, majd pedig a 10-ről ~50-re (illetve ez utóbbi még mindig tart).

A második _sokkal_ durvább.

Eleve a 2-3 fős esetben a "nincs módszertan" - vagy ahogy az agile-os arcok mondják "chaos process" van :) - nem feltétlen baj, sőt az általam látottak közül ez működött a legjobban. De ez pár fős csapatnál följebb nem megy. Ahogy egyre több ember jön borzasztóan romlik a hatékonyság, és az egyre szofisztikáltabb módszertanok bevezetése csak egy kényszer, ami próbálja valahogy enyhíteni a létszámnövekedésből adódó problémákat. A GIT-re is így tekintek, sokminden nem áll kézre benne, de egy bizonyos méret fölött már ez tűnik a legkevésbé rossznak.
---
Régóta vágyok én, az androidok mezonkincsére már!

olyan munkatarsam is szop vele, aki imadja es tobbeves rutinja van benne, szoval egyaltalan nem vagyok biztos benne hogy en vagyok a nagyon hulye :)
vannak benne erdekes es hasznos feature-ok, de az eddigi tapasztalatom alapjan SOKKAL tobb ido megy el a git patyolgatasara, rebase-elgetesre, stb. mint amennyit az svn-re kellett aldozni :(

Nem akarom túlságosan védeni a gitet mert néha nekem is szívás, de ha már rebase-elni kell akkor felmerül hogy talán ti csináljátok rosszul. Az utóbbi fél évben egy kezemen meg tudnám számolni hány rebase-t láttam, mind git pull --rebase volt. (Feature branchek vannak, normálisan egy fejlesztő dolgozik egy branchen de néha előfordul hogy többen nyúlnak azonos kódhoz, ilyenkor rebase-zel elkerülhető egy teljesen felesleges merge.)

Nem tudtam. Nálunk az a szokás, hogy legkésőbb nap végén mindenki push-ol a központi repóba. Ezzel egyrész lesz backup, másrészt látjuk, hogy a másik min dolgozott. Rebase-elni már nem is nagyon szoktunk. A merge mindig --no-ff kapcsolóval megy, így tudjuk revertelni, ha nagyon muszáj.

Én napi szinten használom a GIT-et már jó ideje, de kétszer is meggondolom, mielőtt ajánlanám olyan embernek/csoportnak, akik még a verziókezelés alapjaival sincsenek tisztában. Az SVN kétségtelen előnye, hogy könnyebben átlátható (egy branch = egy könyvtár).

Szerintem a git népszerűségének a felét az adja, hogy maga Linus Benedictus Torvalds szerezte (a másik fele a GitHubnak köszönhető). A Mercurial 12 nappal fiatalabb, mégis kevésbé ismert, pedig műszaki szempontból semmiben sem marad el a git mögött.

Fuszenecker Róbert

Hat, nekem okozott nemi fejtorest, mire megertettem a mercurial branching lenyeget, bar mint kiderult, kb. ugyanaz mint a git, de feltetlen szukseges volt, hogy meg csak hasonloak se legyenek a ket rendszer ehhez szukseges parancsai.

A Mercurial kicsit olyan, mint a PHP, alapvetoen nem rossz, de nagyon rafert volna plusz egy alapos atgondolas, mielott implementaltak.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( uid_16313 | 2015. 01. 27., k – 15:49 )

Baromira irreleváns, hogy egyesek hogyan minösítenek másokat. Nyilván az ember elöször mindig magát minösíti, amikor és ahogyan megszólal.
Amúgy meg csak stílusosan: ki nem szarja le?

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( Oops | 2015. 01. 27., k – 15:58 )

Ahogy nézem, kábé minden szemét. Tudunk olyat, ami szerinte jó?

( deje | 2015. 01. 27., k – 18:49 )

Akkor én jövök:

* Linux: kókványolt szar, elavult megoldásokkal és orbitális design hibákkal, nagy monolitikus fos.
* Git: dettó. én nem fogok commandline-ból verziókezelni meg merge-elni, jobb szeretem a GUI-t.

PS: aktív (és többnyire elégedett) Linux, és aktív és k*rva elégedetlen git felhasználó vagyok. Dvcs téren inkább a Mercurial.

Pedig igaza van. CLI-ből mergelgetni, conflictot feloldani (mikor lehetne GUI-n szépen kulturáltan is megoldani, hogy mi merre hány méter) hányás.

Linux meg a múlt század technológiája, rakás kőkorszaki, kókány megoldással, deal with it.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Megforditom: csak GUI-bol mergelgetni, conflictot feloldani szopas, mert arra sokkal nehezebb mas feluletet, esetleg automatizmust epiteni. Ha nincs egy lib, vagy legalabb CLI, akkor a GUI-t csak es csakis ugy tudod hasznalni, ahogy a fejlesztoi megalmodtak. Az pedig baj. Sokkal jobb kritika a Git ellen, hogy CLI van, es nem lib. (Egyebkent pl Magit <3, legjobb dolog a szeletelt kenyer ota.)

--
|8]

> Pedig igaza van. CLI-ből mergelgetni, conflictot feloldani (mikor lehetne GUI-n szépen kulturáltan is megoldani, hogy mi merre hány méter) hányás

Ez erosen szubjektiv dolog, aktivan hasznalok git-et es mercirual-t is, de a gui-ktol sikitofraszt kapok, ellenben a CLI-s verzioval toketelesen meg vagyok elegedve. Nem csak konnyebb hasznalni, de ugyanazt a feladatot gyorsabb is elvegezni (console-bol). Szoval kinek mi esik kezre...

Ez erdektelen. Ez egy elmeleti vita, aminek a gyakorlat szempontjabol semmi jelentosege. Lehet mikorkernelbol is szart irni, es monolitikusbol is jot. A masik, hogy a monolitikus jelzo valojaban egy tervezesi alapstrukturat takar, amit az osszes OS tankonyv egyszeruen hibasnak titulal, egyebkent teljesen fals indokok menten. Valoszinuleg azert mert az OS tankonyvek nagy reszenek koze van Tannenbaumhoz. Vagy o irta, vagy rola masoltak.

Engem a kollega megalapozott szakmai velemenye erdekel, hogy konkreten a linux kernelben mik a tervezesi hibak, miert is problema amonolitkussag, stb.

Hogy miért probléma? Anno egy nyomorult Bluetooth driver miatt kellett kernelt forgatnom, innentől kezdve a disztribúció kernele mellőzve, minden rohadt security patch után forgathattam újra. Kurvára élveztem. És ez bizony tervezési hiba.
Ha végre nem csak kávé alatt érek rá, majd írok még indokokat.
Ja, még valami: GPL.

"Bluetooth driver miatt kellett kernelt forgatnom"

Ez a dolog ketelu fegyver. Ha megengeded a tetszoleges binaris driver hozzadasat, akkor azert tudjuk mekkora stabilitast lehet vele elerni. Ha azt mondod, hogy a kernel szallit minden tamogatott drivert, az szerintem onmagaban nem tevut, es legkevesbe sem tervezesi hiba.Az, hogy egy disztribucio keszitoje mennyi drivert fordit modulba, az pedig szinten nem a kernel hibaja. Ha letezett a driver a kernelhez, akkor az szerintem a kernel oldalrol teljesen korrekt. Azt meg esetleg el tudom kepzelni, hogy bizonyos driverek nem hajlandoak modulbol korrekten mukodni, ez megint kevesse tartom a kernel hibajanak, a driver kod valoszinuleg rosszul van megirva.

"GPL"

Ez miert is tervezesi hiba? Ettol a lett a linux kernel sikeres. Ha ennek kovetkezteben lassabban keszulnek el driverek, hat ez ennek a fejlesztesi modellnek a hatranya, de tervezesi hibanak nem neveznem.

"akkor azert tudjuk mekkora stabilitast lehet vele elerni." - A Linux is elerte... a hozzaadast is meg a stabilitiast is.
"a kernel szallit minden tamogatott drivert, az szerintem onmagaban nem tevut, es legkevesbe sem tervezesi hiba." - Hat igen, latjuk is, mennyire jok a kernelbe integralt driverek, nouveau, radeonhd, es a tobbiek. Kepunk _nem_ illusztracio.

A programozoi elvezkedesen kivul erdemes lenne idonkent a felhasznalok igenyeit is figyelembe venni. Csak ez az opensource vilagban egyre kevesbe divatos dolog, mert majd mi jol kitalaljuk, mi lesz jo a felhasznalonak. A problema ezzel az, hogy ezt a poent mar tul sokan elsutottek.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( f0xhu v | 2015. 01. 27., k – 20:09 )

((((((((((sok-sok [10!] zarojelben: Linus letett valamit az asztalra, ami a fel vilagot felboritotta egy idore - ez teny... - de ez indok es/vagy ok arra, hogy a fentiekben leirtakat komolyan vegye barki is, vagy barki - barmilyen dontest hozzon az "o" velemenye alapjan es ezzel "meghatarozza" az informatika tovabbi fejlodesi iranyat? -- GY.K. "szubjektiv", mint fogalom.))))))))))

--
A gyors gondolat többet ér, mint a gyors mozdulat.

( PDA_FAN | 2015. 01. 27., k – 21:16 )

Ez azért akkor is nagyszerű, hogy a Linux kiötlője bármit is gondol a Gnome-ról vagy az EMACS-ról, ezek mégis léteznek és használhatóak Linuxon.
Ezzel szemben képzeljük el, ahogy Steve Jobs leordítja egy fejlesztő haját valami olyanért, ami bár lehet, hogy zseniális, de nem nyerte el Jobs tetszését. Mekkora esélye van (volt) egy ilyen fejlesztésnek?

Kicsit felre van csuszva a pelda. Ha Linus leorditja valamelyik kernelfejleszto hajat egy olyan feature miatt, ami lehet, hogy zsenialis, de nem nyeri el Mr. Torvalds tetszeset, akkor az a feature az eletben nem lesz a kernel resze. Ellenben Jobsnak meg lehetett volna a velemenye a Microsoft Office for Mac-rol, az megis letezett volna.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( buran | 2015. 01. 27., k – 21:57 )

Valóban nem egy kedves ember, de ettől még lehet népszerű. Mint Fábry vagy Bochkor. :-) Mellesleg bele is trafált néhányszor: Emacs, Gnome 3.6+, Hurd, XML...

---
;-(

Mesélj még.
Elolvasod a JSON specifikációját (http://www.ietf.org/rfc/rfc4627.txt). Ez szép.
Ezután hogyan tudod a specifikációban leírt eszközökkel interop módon (azaz mondjuk egy .NET és egy Java alkalmazás között) úgy JSON adatot cserélni, hogy a szabványban specifikált eszközöket használva mindkét fél tudja validálni az adatokat és ne kelljen a validátort mindkét nyelven megfogalmazni.

Tudom, hogy létezik JSON Schema (http://tools.ietf.org/id/draft-zyp-json-schema-04.txt), de ez már 2013 augusztusa óta expired. Aki ez alapján akar JSON-re építeni, annak grat :)

( Hijaszu | 2015. 01. 28., sze – 00:41 )

Ejj de szívesen megnézném, hogy teljesen egyedül mit tenne le az asztalra. Merhogy a rendszer amire veri a mellét, és ami az okozta, hogy híres legyen, az azért nagyon nagy részben nem az ő munkája és érdeme, hiába ő indította el. Lehet sokat tenne a Linuxért, ha egy kicsit visszavenne az arcából. Az sem tesz jót, hogy mindenki mást utál aki nem vele egy véleményen van.

Wikipedia (http://en.wikipedia.org/wiki/Git_%28software%29#History):

The development of Git began on 3 April 2005.[14] The project was announced on 6 April,[15] and became self-hosting as of 7 April.[14] The first merge of multiple branches was done on 18 April.[16] Torvalds achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second.[17] On 16 June Git managed the kernel 2.6.12 release.

De nyugodtan nézd meg magad is:
https://github.com/git/git/commits/master?page=1103

Az ötlet válasznak jó, azonban nem helyes. Még ha el is fogadjuk, hogy ő kezdte el és milyen ügyes, a munka nagy része nem tőle származik. Nem tudom, hogy ki az a Junio C Hamano, de a committek nagy része tőle származik a gitben, több mint tízszerese mint amit Linus Torvalds csinált. Ez azért már nem indokolható azzal, hogy ki mekkora munkákat végez el egy commitben.

Mellesleg nem attól lesz valami, hogy valaki egyedül elkezdte megcsinálni és milyen nagy ötlet, hanem attól, hogy ki is lett vitelezve, amihez kell egy csapat. Így értettem, hogy megnézném egyedül mit alkot.

De nyugodtan nézd meg te is a dolgot, amit belinkeltél.

starlight:tmp hijaszu$ date
2015 Jan 29 Csü 14:13:57 AEDT

starlight:tmp hijaszu$ git clone https://github.com/git/git
Cloning into 'git'...

starlight:tmp hijaszu$ cd git/
starlight:git hijaszu$ git shortlog -s -n
14602 Junio C Hamano
1631 Jeff King
1400 Shawn O. Pearce
1109 Linus Torvalds
758 Jonathan Nieder
748 Johannes Schindelin
743 Nguyễn Thái Ngọc Duy
511 Jakub Narębski
503 René Scharfe
487 Eric Wong
483 Michael Haggerty
414 Felipe Contreras
400 Johannes Sixt
348 Christian Couder
345 Nicolas Pitre
336 Thomas Rast
335 Paul Mackerras
293 Brandon Casey
282 Ævar Arnfjörð Bjarmason
252 Simon Hausmann
242 Michael J Gruber
222 Petr Baudis
215 Matthieu Moy

(az alján még van egy rakás commit, de azok ennél már kevesebb számmal vannak)

Igen, olvastam. A linked nem relevans ide, de elmagyarazom neked, hogy miert, hatha nem vilagos:

Abbol, hogy 10x annyi kodot irtak masok egy projectbe, mint az eredeti alkoto, nem kovetkezik, hogy az eredeti alkoto nelkul most egyatalan letezne a project. Ha nincs meg az otlet, nincs aki elkezdi, akkor teljesen mindegy, hogy hanyan es mennyit tettek bele utana. Persze lehetseges, hogy akkor kitalalja mas (vagy beleolik ezt az energiat pl a mercurialba), de az erosen mi-lett-volna-ha kategoria.

--
|8]

A Gitet Linus azért gányolta össze pár hónap alatt, mert nem használhatták a Bitkeepert. Aztán, mivel ő a Linux diktátora, megtette, hogy a Linux innentől kezdve bizony Gitet használ.
Emiatt persze, hogy elterjedt.

Aztán pár értelmesebb alak nekiállt rendesen megcsinálni a Gitet, hogy ne a gányolást kelljen használni, hanem ha már mindenképpen Git, akkor legyen normális.
Ekkor keletkezett az a Git, amit ma is ismersz, pár rendes szaki nekiállt átírni az egészet jól.
Eredetileg shell scriptek kusza halmazából állt az egész.

Nem azért lett a Git az übermester király dolog, mert Linus alkotta, hanem azért, mert ő tette meg ezt a Linux revcontrol szoftverének, majd mások emiatt megcsinálták jóra a Gitet.
Ha a Darcs, vagy a Mercurial (vagy bármi, akkor már létező) mellett döntött volna anno Linus, akkor az lenne most a király.

> Nem azért lett a Git az übermester király dolog, mert Linus alkotta, hanem azért, mert ő tette meg ezt a Linux revcontrol szoftverének, majd mások emiatt megcsinálták jóra a Gitet.
> Ha a Darcs, vagy a Mercurial (vagy bármi, akkor már létező) mellett döntött volna anno Linus, akkor az lenne most a király.
Szóval akkor az az űberkirály dolog, ami mellett Linus dönt? Végülis csak hatással van a dolgokra a muksó.

Amúgy eredetileg csak C kódból állt az egész, nem voltak shell scriptek (https://github.com/git/git/tree/e83c5163316f89bfbde7d9ab23ca2e25604af290)

De nyugodtan nézd meg te is a dolgot, amit belinkeltél.

Azt linkeltem be, hogy pár hét alatt írt nulláról egy DVCS-t, ami elég jó volt ahhoz, hogy egy Linux méretű projektet elvigyen. Ez van az angol szövegben is.

Nem azt linkeltem be, hogy ki mennyit kommittolt a gitbe. Direkt az első kommitokat linkeltem....

( uid_395 v | 2015. 01. 28., sze – 08:54 )

"Öröm" lehet egy ilyen emberrel együtt dolgozni..

( gmoore | 2015. 01. 28., sze – 14:02 )

V.42bis error correction

  • "Fuck this 'hardvert venni tudni kell' shit, I'll just hack up a shitty monolithic kernel - Lunatic Torvalds

    • ( KGer | 2015. 01. 28., sze – 14:14 )

    Szerintem bárki összehoz ennyi leszólást ennyi év alatt, nem is olyan rossz arány.

    Linus a tetejébe valószínűleg jóval aktívabb közösségi fórumokon mint az átlag, több dologról mond véleményt, most 20 év alatt kigyűjteni a fikázós hozzászólásait és egyben feltüntetni, nem is látom értelmét.

    ( asch v | 2015. 01. 28., sze – 16:09 )

    Engem kifejezetten szórakoztat, hogy keményen fogalmaz. Nem óvoda ez már, hogy megsértődjünk. Van 1-2 a fenitek között, amit szeretek, mégis viccesnek tartom amit mondott róla.

    ( XMI | 2015. 01. 28., sze – 21:10 )

    Hiányzik a listáról: Systemd

    ---
    Régóta vágyok én, az androidok mezonkincsére már!

    ( zeroms | 2015. 01. 29., cs – 08:30 )

    A felsoroltak nagy reszehez semmi kozom, u.h. nem tudom oszehasonlitani az en velemenyemmel, de az XML kapcsan szerintem tokeletesen igaza van.

    Mondjuk az xml megítélésének nem segít, hogy nagyon sokszor "kacsacsorok kozotti egymasbaagyazott stringek halmazaként" használják, majd ujraimplementálják az egyébként meglevő dolgokat, vagy hogy akkor is használják, amikor valóan csak kb annyi az igény, hogy legyen valami fix szintaktiájú izé, mert a programozó úrnak kényelmesebb, aki konfig filet ír, az meg hadd szopjon nyugodtan.

    Programozó úr használja csak az XML-t és valami jól működő, tesztelt library-t, és ne szopassa üzemeltető urat a saját kókányolt konfig fájl parserével, ami aztán vagy egy önálló security bughalmaz lesz, de van, hogy simán csak nem működik. Üzemeltető úrnak meg ha kényelmetlen az XML, használjon jobb editort.

    BlackY
    --
    "en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

    Randomra: libxml2. Amúgy milyen nyelvhez?

    Itt két dolgot kell figyelembe venni: 1) a jól definiált formátum miatt bármilyen parser jó [akár platform-specifikus is lehet] és 2) a library-k egyik előnye, hogy ha van bennük secu. bug, akkor egy javítás után az az összes azt használó alkalmazásra is javítva van. Szemben a mostani gyakorlattal, ahol alkalmazásonként saját formátum/parser, így mondjuk egy hiba valóban alkalmazáshoz köthető, viszont annak a security auditálását és támogatását is az alkalmazás fejlesztőinek kell elkövetniük - amire vagy van szabad kapacitásuk, vagy nincs.

    BlackY
    --
    "en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

    "bármilyen parser jó" vs " ne szopassa üzemeltető urat a saját kókányolt konfig fájl parserével"

    Hol az igazsag mostanaban? Baratsagos, meleg szobaban!

    Amennyi custom XML parsert en mar lattam, siman azt mondom, hogy inkabb 100x ini fajl mint egyszer XML.
    --
    Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 

    
()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

    "Bármilyen parser jó", amit nem csak az adott alkalmazáshoz írnak; így ok? Így az N darab parser helyett lenne N/M, M>1; és egységes standardot implementálnának, hivatalosan, és pl. két rendszer kompatibilitásához nem kéne bug-by-bug reprodukálni a korábbi rendszer konfig parserét.

    BlackY
    --
    "en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

    [ ez igazából a lentebbibe is tartozik]

    Az ugye megvan, hogy nem az xml minőségét, hanem az xml megítélését emlegettem? ;) Egyébként ha tudsz mondani egy olyan editort, amiben nem szar xmlt szerkeszteni mondjuk egy foo = bar sorokat tartalmazo file viozásához képest, azt komolyan megköszönöm. Ha bónuszként mondjuk a centos minimal telepítésben is benne van, még inkább ;)

    Egyébként meg azért konfig file kezelésre van még az xmlen kívül pár jól működő tesztelt lib. ;) Ha meg az xmlben ez triviális, akkor mégiscsak a programozó urakkal lesz a gond, hogy mégis mindenféle házitakonnyal szoptaják magukat folyamatosan, amik változatos módon csinálnak furcsaságokat :)

    Az ugye megvan, hogy nem az xml minőségét, hanem az xml megítélését emlegettem? ;)

    Jóvanna, reggel volt még :)

    Egyébként ha tudsz mondani egy olyan editort, amiben nem szar xmlt szerkeszteni mondjuk egy foo = bar sorokat tartalmazo file viozásához képest, azt komolyan megköszönöm.

    Eclipse :)
    Komolyra fordítva a szót: a vi-os szerkesztéshez valóban kevésbé alkalmas (bár a jól definiáltság ott is jól jön, mert ugye alkalmazás-függő, hogy foo=bar ugyanazt állítaná-e, mint foo = bar. Vagy foo = foo bar ugyanaz-e, mint foo = "foo bar"), bár (soha nem próbáltam:) https://github.com/vim-scripts/XML-Completion

    --
    Lib-ek vannak random konfig formátumhoz (mostanában a legtöbbett a Microsoft Deployment Toolkit ini konfigján anyázok, egész máshogy értelmezi ő, a PHP parse_ini_file és a Python ini parsere...), eszközellátottság kevésbé. XML-el kulcsrakészen kapnánk scriptelhető módosítási lehetőséget (XMLStarlet), ellenőrző eszközt (XMLStarlet, xmllint), "emberi" megjelenítőt (XSLT) stb.

    akkor mégiscsak a programozó urakkal lesz a gond, hogy mégis mindenféle házitakonnyal szoptaják magukat folyamatosan, amik változatos módon csinálnak furcsaságokat :)

    Pontosan. Pár hónapja a nememlékszemmelyikBSD-s távlati tervek előadásban nem ok nélkül szerepelt, hogy egységesítik a konfig fájl formátumokat... (talán pont XML-t írtak ők is...)

    BlackY
    --
    "en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

    Igen, itt is komolyan felmerült, hogy a használjuk a faszomsetudja milyen verziókezelőt mi is, mert a fejlesztésen milyen szuper. Ja, van használhatatlan cli, meg eclipse, de ugye tartod benne a text filejaid, jó lesz.

    Az utolsót kicsit félreértetted: én xml, vagy annak látszo szarokkal is rendszeresen látok ilyeneket, egészen nem játék rendszerekben is :)

    Inkabb legyen egyfajta szintakszisu konfig file (XML), mert ahhoz eleg 1 XML editor, hogy strukturalt, syntaxhighlightos szerkesztot kapj, ami tud code foldingot (nagy konfig eseten elony), meg tud syntax checket, ahelyett, hogy van:
    - property file
    - INI-style
    - felig kacsacsoros directiva file, lasd Apache httpd
    - JSON-jellegu konfig, lasd nginx
    - sok minden mas, mert mindenki ujrafeltalalja az ultimate konfig szintakszist

    Plusz ha XML egy konfig, akkor adhato melle schema file, amivel meg lesz kodkiegeszites is, ha normalis az XML editorod. De hat ez ugy latszik, tul modern dolog, maradjunk csak a XX. szazad 70-es eveiben technologiailag.
    Sot, ha van schema file, megfelelo kommentezessel ellatva (annotation es documentation), akkor az XML editor segit a konfig szerkesztesekor, es nem kell kulon appban megnyitnod a konfig file leirasat.

    Az a baj, hogy akármennyire is átlátja az ember aggyal egy ilyesminek a jogosságát, xmlt kézzel szerkeszteni szar, személy szerint roppantul rühellek bármit, ami abban, vagy olyasmiben tartja a konfigját. Illetve azt vettem észre magamon, hogy hacsak nem nagyon braindead a struktúra, akkor nem fáj, hogy 5 félét kell szerkeszteni, mert egy konfig file általában átlátható struktúrában van. Ami nagyon braindead az meg nagy százalékban pont xml ;)

    Továbbá aki azt hiszi, hogy egy normális xml editor mindenhol rendelkezésre áll, az még nem üzemeltetett :)

    A schema meg a kiegészítés szép dolog, de ez tipikusan ilyen programozós gondolkodás. Mivel a programozó egy IDEben él, ezért azt gondolja, hogy az ott megszokott, neki kézráló dolgok másnak is kézreállónak, meg mások is ahhoz vannak szokva, meg másokat is zavar, ha nincs. Meg hogy mások is egy IDEben élnek. A gyakorlatban meg az esetek nagyon nagy százalékában baszottul nincs rá szükség, key value párok vannak valami blokkokban, felettük elfér hasmarkkal a magyarázat, átírod, jóidő. Szofisztikált csudietior helyett egy vi-al.

    TL;DR érdemei elismerése mellett -- nem szarkazmus, az xml rengeteg szempontból a legkiforrottabb alternatíva -- az xml nagyon sokszor overkill. És nagyon sokszor szarul van használva. És emiatt hiába tudja az ember, hogy alapvetően van vele egy csomó jó dolog, ha napi szinten inkább csak szopat, akkor, hogy is mondják szépen, negatív érzelmi töltet fog hozzá kapcsolódni, és az ember nem fogja szeretni.

    Potoltam. Ne haragudj, de az utobbi idokben elofordult, hogy megnyitottam szalakat, hogy majd valaszolok, aztan restartoltam a bongeszot, onnantol meg nem jeloli meg "uj"-kent a tracker. Mindig ez van, ha valami weboldalt kell hakkolni, sajnos.
    --
    Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 

    
()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

    Bennem mindig felmerül, hogy xml editor alatt miért text editort értünk? Az xml egy fa, ahol a nodeoknak lehetnek attribútumai. Erre baromi egyszerű összedobni egy guit, egy kis érzékkel egész használhatót is. Mégis általában textként editáljuk, esetleg van hozzá syntax highlighting, jobb esetben code completion és schema validation, de ennyi. Még csak navigálni sem lehet a treeben rendesen, ami szerintem alap kéne, hogy legyen. (Oké, eclipse xml editorában mintha lenne valami ilyesmi, de eclipset nem vagyok hajlandó használni amíg nem muszáj.)

    Jó esetben a séma validátor megmutatja, hogy ez a node/attrib/érték a hibás. Rossz esetben meg tényleg nem nagy mutatvány egy keresőt beletenni, ami nodenév-re, attrib névre, attrib értékre és node textvalue-ra keres.

    Egyébként (bár pont egy UI katasztrófa) példának ott a Microsoft unattend.xml szerkesztője.

    de a hasonlókat is találja meg, stb.

    Hogy definiálod a hasonlót és ezt melyik text editor tudja?

    BlackY
    --
    "en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

    Jó esetben, azaz elméletileg mindenki úgy használja az xml-t, hogy az alkalmazás is séma alapján validál. Máskor meg nem.
    Tetszőleges editor meg a szemem tudja a "hasonló" feature-t (de a case-insensitive mintaillesztős keresés is sokat tud segíteni) elsősorban persze akkor, ha a fájl nem úgy épül föl, hogy 10% hasznos adat és 90% struktúraleírás :-P

    > te is azt hiszed, hogy az XML az kacsacsorok kozotti egymasbaagyazott stringek halmaza, de baromira nem

    En csak .xml-ben irt konfigfajlokat latok, ahova egy .ini is qrvara sok lenne...

    ---
    Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

    Sor lezaro?
    C-ben utasitasok vannak, ezeket zarja pontosvesszo. Kifejezeseket ugyanugy vesszovel hatarolunk el egymastol C-ben is.
    Peldaul egy struktura inicializalasa igy nez ki C-ben:
    http://www-01.ibm.com/support/knowledgecenter/SSXVZZ_8.0.0/com.ibm.xlcp…

    static struct address perm_address =
    { 3, "Savona Dr.", "Dundas", "Ontario", "L4B 2A1"};

    Olyan nem igazan definialt, hogy "sor" lezaro, ezek free-form nyelvek, az utasitasok nem a sor vegeig, hanem az utasitaslezaro karakterig tartanak (;), igy egy utasitas lehet tobb soros is, illetve egy sorban lehet tobb utasitas is.
    Ez igy logikus, hiszen a sorokat ujsor karakter zarja, attol sorok :)
    Vesszovel a kifejezeseket tudjuk egymastol elvalasztani (vesszo operator).

    JSON-ban is vesszo a strukturan belul adattagok elvalasztasanak az eszkoze.

    Jo, nyilvan nem a megfelelo terminologiat hasznaltam. Gondoltam, igy is erteni fogod.

    Az nginx konfigban az egyes konfiguracios opciok felfoghatok utasitasoknak is akar.

    En ugy tudom egyebkent, hogy az nginx konfigja is megengedi a tobbsoros utasitasokat.
    --
    Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 

    
()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

    Ahogy latom sokan tevedesbe estek. Linus magarol az XMLrol, mint filerol beszel. A koreje epitett funkciokat/standardokat szerintem "nygodtan" lehetne peldaul JSON-ra is alkalmazni (JSONt tarolni, kuldeni, parseolni lenyegesen olcsobb). Beolvasas/betoltes utan az eredmeny a memoriaban lehet teljesen hasonlo.

    Ha kore lesz epitve a sok funkcio, ugyanannyiba kerul majd parzolni, hidd el. Pont azert draga az XML helyes parzolasa, mert nem csak szintakszis-ellenorzes van ott :)
    Kacsacsorokkel egymasba agyazott dolgokat pontosan ugyanannyi dolog parzolni butan, mint kapcsos zarojelekkel hatarolt cuccot.

    ( NevemTeve | 2016. 01. 23., szo – 08:35 )

    Nahát, ezt nem is láttam eddig... Szörnyű! Ez az ember egy A-kategóriás troll!

    Speciel amit a C++-ról mondott, abban van igazság. Vagy az XML-ről. És a gnome-ról. Az emacs inkább olyasmi lehet, hogy nem szánt rá néhány hónapot az életéből, hogy megtanulja, hanem rögtön használni akarta -- és persze nem ment (persze sok olyen sw van, amire ez igaz, pl: http://xkcd.com/1597/)