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

 ( trey | 2015. január 27., kedd - 13:47 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"Priorities, people, priorities."

--
trey @ gépház

Jegeskávé?

Mivel a kernelfejlesztés múlik rajta, minimum RAID1 kávéfőző.

--
trey @ gépház

Tükörjegeskávé? :^)

Mondjuk, így már munkaeszköznek számít.

Ha nincs kave akkor nagyon bugos lesz a kernel. Valaki vigyen mar kavet neki!

Ez nagyon jo volt!

- Nagymama ! Miért olyan nagy az arcod ?
- Mert Debiant használok !

:)))) beszartam

Te hallgass, és válts gatyát! (Gzalog-galopp, bár abban a "berittyentettem" kifejezést használják először, és csak másodszorra hangzik el a "megint beszartam")

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

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

+1

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

> 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

NTFS? :)

https://technet.microsoft.com/en-us/library/cc753321.aspx vagy van GUI is hozzá

Akkor kimondhatjuk, hogy ennek nem szabadna így 2015 környékén gondot okoznia? :)

(Adott esetben függetlenül attól, hogy van-e egy konkrét root folder a fájlrendszerben, vagy sem)

Szerintem ha bedugok egy pendrive-ot a Windowsba, akkor külön meghajtó betűjel alá kerül, tehát nem lesz egységes a fájlrendszer.

--
arch,centos,debian,openelec,android

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

De: minden a "My Computer" mappába kerül. :D
--
http://naszta.hu

Még My Computernek hívják? Merthogy magyarul már jóideje nincsen "Sajátgép"...

Angol W 8.1-ben ha elkezdem gépelni, hogy "my com" ugyanúgy előjön a "This PC". Magyarul is működik.

--
trey @ gépház

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....

Biztos. Az én Ubuntu-mban egyetlen magyar szó sincs.

--
trey @ gépház

Nekem ubuntu 14.10 alatt a dash megtalálja magyarul és angolul is (kipróbáltam pár dologgal, mint képernyőlép/screenshot számológép/calculator nyomtató/printer). Vagy pontosan mire is gondolt a költő?

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....

Nem pont ez a cél?

Beírod, hogy screensho és odaadja neked azt, amit keresel, a képernyőkép nevűt.

Az a baja, hogy nem írja még oda pluszba burkinafaszóiul is.

locale=C -ben. Tudod alap, informatika, miegyeb.

---
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....

vagy nem kap betujelet, ha eppen olyan napja van :D (legalabbis XP alatt tobbszor elofordult hogy kezzel kellett raeroszakolni egy betut mert "magatol" nem kapott, azota remelhetoleg ez mar megoldodott)

... és ennek az a hátránya, hogy...? ;)

De amúgy nem, oda lesz mountolva, ahová szeretnéd. (Win-X --> Disk Management)

Lehet, hogy az angol ABC-ben korlatos szamu betu van, es mondjuk vallallti kornyezetben el szoktak fogyni a betuk....

lock

Teljesen legitim use-case, hogy nagyvállalati környezetben 26 25 darab pendrive-ot kell egyidőben felcsatolni, ráadásul úgy, hogy muszáj neki külön betűt adni, nem lehet a C:-n becsatolni egy mappa alá. :D

network driveot láttál-e már :)

Nem az a kérdés, hogy láttam-e, hanem hogy mennyit? :D

Amúgy mindegy, iirc network share-t is lehet mappaként csatolni, de fixme.

Nem.

RESOLVED, FIXED.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

Lehetni lehet (mármint drive-ot, network share-t passz), de nem teljesen transzparens. Lásd még: Adobe Reader és az NTFS Junction Point esete ;)

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

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.

Jó, de gyakorlatban mire nem szokott elég lenni? Ha feleslegesen felhasználsz 20-at, ne csodálkozz, hogy kevés.

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

A gyakorlatban elég szokott lenni. Ezt még csak nem is vitattam, mindössze a teljesen blőd 26 pendrivera mondtam, hogy azért azon túl van még élet betűjeleknek.

Unpopular opinion: szerintem a sima, mezei network share is egy baromira elavult dolog, úgyhogy pont összeillenek a betűjelezéssel. :P

>Ha nincs ő, akkor a most linuxot heggesztgető emberek megtalálják...
hálásak is vagyunk ezért

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...

> 2015
> case-insenstive
> baj

Dehogy baj, te jó ég. :)

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é.

+1! Pedig az AmigaOS-nek anno ez nem okozott gondot :(

--
"In a cult, there is a person at the top who knows it's a scam. In a religion, that person is dead."

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/Ralph_Boehme-AppledancesSamba.pdf, 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)

Pár nem használható karakter tényleg ALAPVETŐ gond...

:)

Öööö, 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)

Először nem jött át a vicc, de most már megvan.

:)

Nem az fs, hanem az os korlátja, egyébként meg inkább korlátozza mint hogy engedi létrehozni aztán szenvedés megszabadulni tőle. Pl. ESC-et tartalmazó filenév (true story).

Idézet:
ESC-et tartalmazó filenév

Wow... köszi a tippet, ezt valamikor egyszer valakivel tuti eljátszom :)

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

newfagz cannot into ALT+255.EXE (+autoexec.bat)

WUT?

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

A legjobb koleszos szivatások egyike (volt) :). Ugyanakkor sok esetben jó trükk arra, ha valami program kötelezően vár valami adatot, amit ráadásul ki is nyomtat, de te nem akarsz megadni semmit.


Ne kattints ide!

É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)

De ezt egy 'ls -B' azonnal lebuktatja...

Ave, Saabi.

Nagyjából annyira "alap ASCII" a * egy fájlrendszerben, mint a < a HTML-ben.

Ne tegyünk már olyat a fájlnévbe, amit az oprendszer használ. Linuxon pl. nincs szívás az rm -rf körül, ha * van a névben?

Idézet:
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)

C:\
\\izémizé:8080\

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              .
2015.01.28.  11:30              ..
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. Ext4-en sem használhatsz / jelet a fájlnévben.

Idézet:
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.

Idézet:
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. :)

Pláne, hogy élőszóban nincs is kisbetű-nagybetű.

Fuszenecker Róbert

Kár, hogy fájlnév rohadtúl nem élő szónak minősül
-
Változékony Grails alkalmazás konfiguráció facepalm

És mi van azokkal az alkalmazásokkal, amelyek a fájlrendszert használják adatbázisként? Miért kellene fele dupla akkora metaadatot eltárolnom, amikor fele akkorával is megúszhatnám?
--
zsebHUP-ot használok!

>És mi van azokkal az alkalmazásokkal, amelyek a fájlrendszert használják adatbázisként?

ha nem "A Fájlrendszert" célozva vannak megírva (tehát oppansource módon) hanem fájlrendszerekre, akkor semmi baj

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.

Sajnos szinte(?) az összes open source MTA így működik...
Egyébként erősen függ a felhasználás jellegétől. Ha videókat tárolok, az rendben van?
--
zsebHUP-ot használok!

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.

BLOB-okkal, Oracle alapon, látott már a világ ilyet - masszív hozzáférési jogosultsággal megspékelve :-P

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
()_()

Több 10 ezer fájl gondot okoz? Akkor ott nagy bajok vannak.

De nem a fájlrendszer DB-nek használata miatt :-P Bár egy könyvtárba történő belapátolás lehet, hogy erősen szuboptimális, az igaz :-)

Ez most irónia vagy komoly kérdés?

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

tehát nem tudsz semmit mondani

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

>az emberek használnak kis és nagybetűket különböző célokból

goto

>különböző célokból

goto

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

>az FS-eket úgy általában embereknek csinálják
>a fájlnév írott szó/szavak halmaza

comedy gold

Te tényleg ennyire idióta vagy, vagy én vagyok az idióta, hogy leállok veled a semmin vitatkozni, mert végülis te semmit sem mondtál eddig. Majd szólj ha van is valami mondandót, ígérem figyelni fogok.

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

goto

>idióta vagy, vagy én vagyok az idióta

legalább a problémát jól látod

>Majd szólj

obligát newfag reading

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?

És ezért nem is illik spec karaktereket tenni fájlnévbe. Nem azért, mert az OS/FS képtelen lenne kezelni, hanem mert a túloldalt szívatod vele, ha dolgozni kell vele.

Ja, nagyon sok mindent nem illik, de ez nem megoldás arra a problémára, ami fel sem merül a case-sensitive fájlrendszer esetén.

>hogy oldanád fel a problémát

lehet ez most neked durva lesz, de a "NAGY TÖRÖK I-T AKAROK ÍRNI" az nem a filerendszer "problémája"

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.

>A filerendszernek nincsenek "problémái", a felhasználóknak vannak

ha ezen a ponton befejezted volna a kommented, nem kerültél volna hupmeme-be

Nem szégyen, ha nem érted a problémát :)

>git azt hitte hogy uj file
>szar a HFS!!!

hupexpertized

.

Milyen kedves ember.

"I'm not a nice person, and I don't care about you. I care about the technology and the kernel—that's what's important to me."
Persze senki nem szereti ha leszólják a munkáját, de jobb mint évekig tévúton járni, miközben mindenki hátba vereget.

> konstruktív kritika

Értem, hogy mire gondolsz, de ez szerintem nem az. :) Ha egy szoftverről azt mondom, hogy a sátán műve, akkor nem a hibákra világítottam rá, hanem a saját személyiségem hiányosságaira.

Igaz, de így jobban odafigyelnek rá.

És ez jó fajta figyelem? (Obligatory: http://www.dedoimedo.com/computers/you-made-a-mistake.html)

Van akinek bejön. Legalább nem csinál magából idiótát 5 perc hírnévért, mint Steve Ballmer.

"A Linux kernel fejlesztoje meleg." - vajon megfelelo-e a megnovekedett figyelem?
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

Az más téma, jó hogy nem Charles Mansonnal jössz. De Dr. House-t is szerettük, pedig nyomába sem ér Linus bunkóságban ;)

Hat, bakker, errol a fickorol meg csak nem is hallottam, most olvastam eloszor a nevet. Kicsit kupalodnom kellene meg amerikai tortenelembol...
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

Nem a kedvességéért szeretjük.

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

Szép napot! :)

sose ertettem ezt a dupla shortcutot...

Marmint ertem, hogy le kell utni, de megis miert?

---
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....

Annyi funkciót akartak lefedni, hogy csak 2 leütéses shortcutokkal tudták megoldani (persze van pl. C-k, C-a, C-e, stb. is). Azonkívül emacsban csak egy mód van (editor), ezért nem tehették pl. q-ra a kilépést mint a vi-ban.

Ha mar ennyi shortcut, akkor egy alapfoku zongoratanfolyamra beirattam volna oket....

---
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....

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
()_()

ez hulyeseg, pont rossz pelda
nem kell folyton kilepkedni, ritkan kell hasznalni, akkor is csak egyszer
ez olyan mintha a desktop-odon a legkonnyebben elerheto bill. komb. az lenne h reboot

meg ha soxor inditod, zarod be, akkor is meg nagyon konnyed a C-x C-c

Ja, és a vi-ban a kilépés eljárása:

  1. ESC, hogy command vagy milyen módba kerüljek
  2. :q
  3. ENTER

Ez miért jobb?

Szerkesztés módban "ZZ": ment és kilép.

Ave, Saabi.

Hát nem :)

Ööö... parancs mód lesz az... :-D Huhh, ritka nagy hülyeséget írtam le fenn... :-D

Ave, Saabi.

Dehogy irtal hulyeseget.

:nnoimap ZZ <Esc>:wq<CR>

;-)

szerk: kacsacsorok javitva

Nem a ZZ-vel, az nyilván van a vi-ban, hanem hogy szerkesztés módban használható. Sose tudnám leírni, hogy ZZTop. :-)

Ave, Saabi.

Pedig command mod lesz az csak meg a kettospont megnyomasa elott (utana irnad be a :wq-t, vagy lepnel i-vel insert modba vagy v-vel visual modba

az _normal_mod_ amire te gondolsz
a command mod az, ahova a : megnyomasaval lepsz normal modbol :)

>2015
>1970-ben elavult vi így vi úgy

what the fuck am i reading

lehet hogy a vi elavult, de a vim az vi-kompatibilis :P

/o\ Rosszul tudod. Normal mode, nem "Command mod csak a kettospont megnyomasa elott" A Normal modban a kettospont megnyomasaval ersz a Commandba.

Én még úgy tanultam, hogy a ":" ed módba lép. Mivel a vi a felhasználóbarát változata az ed editornak. Tehát amíg az "ESC" "ZZ" vi parancs, addig a ":wq" ed parancs. Zahy, jól emlékszem? :-)

Ave, Saabi.

Majdnem. A ":" a vi-nak szól, hogy váltson ed módba, a wq meg az ed parancsa. Szerintem :-P

Nekem azért, mert azt szoktam meg. Soha nem nyúltam emacshoz, és szerintem már nem is fogok. :)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
Get dropbox account now!

(toroltem)

igy van
az emacs az egyik legjobb dolog a nyilt vilagban (a vi-al egyutt)

És van-e már benne jó text editor? Mert sok éve már csak az hiányzott belőle :-D

most tenyleg azt gondolod h nem az emacs es a vi a legjobbak, vagy csak viccelsz (latom a smile-t)

Látszik, fiatal vagy, hogy nem ismered ezt a kérdést :-) Még az EMACS-fanok is elismerik, hogy egy jó text editor még hiányzik belőle :-D

Már hogyne volna. :-D

Ave, Saabi.

[hányok]
:D

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

Oké, hogy leszólta, de legalább konstruktívan állt hozzá. Nekiállt és megcsinálta úgy, ahogy szerinte jó. És így született meg a Git.

--
trey @ gépház

sokkal tobbet szoptam gittel az utobbi 6 honapban mint svn-nel az azt megelozo 6 evben
ettol a git meg lehet jo, de en hacsak lehet el fogom kerulni a jovoben...

Akkor tanuld meg rendesen használni! A git egy nagyságrenddel jobb SCM rendszer. Pl.: a többiek branch kezelése egy vicc.
--
http://naszta.hu

+1

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

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

Semmit, szerencsére. :)

Pedig a cherry-pick nagyon hasznos tud lenni. Van olyan workflow es helyzet, amikor sokkal kenyelmesebb es hatekonyabb, mint barmely alternativa. Persze idealis esetben tenyleg nincs ra igeny, de a valosag el szokott terni az idealistol neha-neha :)

--
|8]

> de a valosag el szokott terni az idealistol neha-neha

hát, ha csak úgy nem :)

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]

10+ dedikált fejlesztő nem is nagy projekt. Egy normálisabb mobilapp is ennyi fejlesztőt igényel. Nagy projekt inkább egy nagyságrenddel efelett van.

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.

Nem azt mondtam, hogy az overhead rossz, hanem hogy az igazi választóvonal még valahol bőven <10 fejlesztőnél van. Onnantól, hogy 30-an vagy 150-en dolgoznak egy projekten, már sokkal kisebb különbség (ebből a szempontból, nyilván).

Viszont ha 2 fejlesztő van, akkor is megéri mindent pontosan adminisztrálni a fejlesztés kapcsán, mert nagyon hamar káosz lesz, ha nem így van.

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!

10? :))))

50+

--
NetBSD - Simplicity is prerequisite for reliability

Kérdésedből ítélve te nem láttál :)

:'(

Lattam SVN-ben nagy (tobb Gb [nyilvan ennek egy jelentos resze nem forras, hanem adat], olyan 4-5 tucat aktiv fejleszto, aktivan branchelt fejlesztes). Sokkal boldogabbak gittel, megha volt is nemi szivas az elejen a toolinggal.

--
|8]

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 ertem. pull/rebase/push kb megfelel az svn workflow-nak. ha sokkal tobb ido megy el ra mint svn-el akkor valamit nagyon rosszul csinaltok (no offense)

lehet hogy rosszul csinaljuk
mivel a git nekem uj volt, arra a kollegara hallgattunk akinek komoly tapasztalata van vele es imadja
o is szop, csak o ezt nem eri meg fajdalomnak, hanem teljesen normalisnak tartja :D

Ezt tessek elolvasni (akar tobbszor is), megerteni, es lon vilagossag: http://git-scm.com/book/en/v1/Git-Internals

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.)

ízlések és pofonok, mi mindig rebaselünk, abból még baj nem volt alapon
-
Változékony Grails alkalmazás konfiguráció facepalm

nem "ha mar rebase-elni kell", hanem ez a policy (nem pullozunk hanem rebase-elunk az "svn up" megfelelojekent)
ez izles dolga, tobb olyan gitet hasznalo fejlesztovel talalkoztam aki ezt preferalta a pull helyett

a brancheket pedig pontosan ugy hasznaljuk ahogy leirtad :)

Ti megosztott branch-eket rebase-eltek? Az nem tul jo otlet.

mit ertesz megosztott branch alatt?

Ami nem csak nálad létezik lokálban, hanem mondjuk push-olva lett egy központi repóba.

azt hittem alap hogy ezekrol beszelunk...

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.

nalunk naponta tobb push a kovetendo
(mar csak azert is, mert akkor az esetleges conflictokkal mas fog szivni :D)

Ez a "legkésőbb a nap végén" illetve naponta több push a központi repó masterébe megy, vagy külön branchekbe?

nalunk az aktualis branchbe
masterre csak a CI-n keresztul merge-elunk (amikor a megfelelo feature elkeszul, ez jo esetben egy scrum sprinten belul megtortenik)

Akkor abba az "aktuális branchbe" többen pusholnak?

elofordul hogy nem egy hanem ket fejleszto hasznal egy branchet, de kozottuk nincs conflict, az a master-re valo visszarakasnal szokott kezdodni

kulon branch-be. ami masterbe kerul, az automatikusan megy ki elesbe (mar ha nem torik el a build). nap vegen meg ugye nem elesitunk :)

Olyan branch, amit mások is láthatnak, rosszabb esetben arra alapozva fejleszthettek.
Lásd git help rebase /bad idea.

nalunk olyan eleve csak nagyon-nagyon ritkan fordul elo hogy egy branchbol agazunk le
de ha megis, akkor meg ott az "easy case" alatt leirt megoldas

mindenesetre a "link" jol nez ki, koszi, lehet hogy a legkozelebbi git-szopasnal bedobom a ceges chatre :D

amen.

+1

És itt tegyük hozzá, hogy ezek után összedobott egy elég jó verzió kezelőt (Git).

--
http://pyftpadmin.earthquake.hu

> elég jó

:'(

>elég jó verzió kezelőt (Git)

10/10 sarcasm, well done

Ohh, nezd mar, egy hozzaerto.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

Ja a CVS meg SVN azok nagyok voltak. :D Meg szerintem kimarad a kozepsoujjas nVidia beszolasa is: "So nVidia, F.CK YOU!" Nekem amugy Gnome-os interfesznaci a kedvencem, mult honapban unnepelte 10-edik szuletesnapjat. (repul az ido)

É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
()_()

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

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

Buvarkodni peldaul szeret. Nomeg git es a kernel termeszetesen jo. (De volt mar jopar egyeb, ohozza nem kotheto dolog, amirol pozitivan nyilatkozott, de az a sajtot kevesse szokta erdekelni, mert nem lehet rajta jot csamcsogni.)

--
|8]

Miért nem lehet csámcsogni a sajton?
(bocs)

Mert kékpéniszes :(

--
trey @ gépház

:D

ROTFL

--
NetBSD - Simplicity is prerequisite for reliability

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.

lock

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™

Ezzel egyetértek.
Ellenben azért szidni egy valamit, mert _lehet_ CLI-ből használni.
Gyönyörű GUI-k vannak, s az IDE még azokat is pótolja.

A Linuxhoz nem értek, csak használom, azzal a felével semmi bajom.
--
blogom

Szerintem Linus nem fejlesztett sosem Git GUI-t, az már más emberek érdeme, hogy próbálták menteni a menthetőt. :)

De fixme.

Megmutatnad, hogy az SVN fejlesztok hol fejlesztettek GUI-t? Tenyleg kivancsi vagyok.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

Csak ha előbb te megmutatod nekem, hogy hol írtam azt, hogy az SVN fejlesztők csinálták az SVN GUI-kat is. ;)

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...

"Linux: kókványolt szar, elavult megoldásokkal és orbitális design hibákkal, nagy monolitikus fos"

Oszinten kivancsiva tettel. Erdekelnenek az elavult megoldasok, a tervezesi hibak, es a monolitikussag problemai.

The Tanenbaum-Torvalds Debate ;)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
Get dropbox account now!

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.

"a kollega megalapozott szakmai velemenye erdekel, hogy konkreten a linux kernelben mik a tervezesi hibak, miert is problema amonolitkussag" - Ez itt a HUP, itt fölösleges ilyesmit várni :-D

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.

Én nem nagyon emlékszem olyanra, hogy egy drivert nem lehetett modulba fordítani, és emiatt ki kellett dobnom a stock kernelt. (Igazából lassan már olyanra se, hogy drivert kellett fordítani, de lehet, ez csak azért van, mert nem linuxozok desktopon)

Nekem volt hogy át is kellett írni... régi szép idők, azóta persze nem használok linuxot és boldog ember vagyok :D

Mármint drivert? Ok, olyat én is láttam (bár többnyire ez kimerült annak elmagyarázásában, hogy jó lesz ez a driver más PCI ID-khez is), de olyanra, hogy egy drivert be kellett volna forgatni, tényleg nem nagyon.

"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.

>Ettol a lett a linux kernel sikeres.

this is what hupus actually believe

"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
()_()

Igen teljesen egyetertek. Ugyanakkor megsem tervezesi vagy strukturalis hibanak latom, egyszeruen az implementacio minosege ilyen.

>be linux user
>using layer2 vpn
>modprobe ipv6
>module subsystem deadlock now
>pinux unrebootable :=]

nem nagyon erőltetted meg magad az "őszinte kíváncsiságtól" hajtva

"unrebootable"

A RESET gomb minden problemat megold!
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

hronexpertize :D

((((((((((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.

"Linus letett valamit az asztalra, ami a fel vilagot felboritotta egy idore..."

Ugyanez igaz Hitlerre is, mégsem gondol rá senki jó szívvel.

Fuszenecker Róbert

senki?

Blondi kutya.

>senki

0/10 too obvious, libsi

Linus go fsck yo'self...

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?

+1

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
()_()

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...

---
;-(

xml, ami fajlformatum!

--
NetBSD - Simplicity is prerequisite for reliability

Nem teljesen ezt írta, azt írta fájlformátumként rosszul skálázódik. Tisztában van vele, hogy lehet másra is használni, lásd a mondat másik felét.

Lehet, hogy tisztában van vele, azonban pont arra is az a véleménye a második fele szerint, hogy szar.

Miért, nem az? A felhozott érvei megállják a helyüket.

Lehet, hogy szar, de sok feladatra még mindig nem találtak ki jobbat. :)

json?


Bye Bye Nyuszifül - DigitalOcean referrer, 10$ kezdő kredittel - <3 openSUSE, Ubuntu, KDE <3

Ami nem támogat sémát, típusokat, meg még pár dolgot. Az XML nem csak egymásbaágyazott stringek kacsacsőrök között. Az csak a szintakszis, van neki szemantikája is.

Hátő..., de.


Bye Bye Nyuszifül - DigitalOcean referrer, 10$ kezdő kredittel - <3 openSUSE, Ubuntu, KDE <3

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 :)

FYI, Linus a GNU Emacsrol beszelt. Sokaig - lehet meg most is - o is Emacsot hasznalt, csak nem a GNU felet, hanem egy microEmacs forkot.

--
|8]

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)

Hanyszor bizonyitson meg Linus, hogy meg _te_ is elfogadd, hogy nagy asz? Ugy tunik neked 2 worldwide & live projekt nem elegendo.

>worldwide & live

kimaradtak az "européer", "demokrata" buzzwordok

git Initial release April 7, 2005
Torvalds turned the entire project over to Hamano in July 2005.

yfw linus mindössze 3 hónapig taknyolt a giten, a fennmaradó 9 év pedig, nos...

Cserebe a harom honap nelkul nem lenne a 9 ev sem, ez nem egy elhanyagolhato tenyezo.

--
|8]

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)

Ez a plumbing, a content-addressable FS, de ez meg nem egy DVCS.

Maga a porcelain meg shell scriptek halmaza volt.
https://github.com/git/git/tree/a3eb250f996bf5e12376ec88622c4ccaabf20ea8 es mondjuk
https://github.com/git/git/blob/a3eb250f996bf5e12376ec88622c4ccaabf20ea8/git-commit-script

Elbeszelunk egymas mellett ugy latom. En azt mondom Linus nelkul nem lett volna git, te azt mondod, hogy nelkule lett volna mas. A ketto nem zarja ki egymast.

--
|8]

>Elbeszelunk egymas mellett

egy ilyen gitmo fluffernek igazán feltünhetett volna hogy nem a subthread indító emberrel beszél

...es ez relevans miert is?

Javasolnam, hogy esetleg gondolkodj, mielott valaszolsz, de az utobbi hozzaszolasaidbol sajnalatos modon azt a kovetkeztetest kellett levonnom, hogy nagyjabol fel bitnyi kontextus ertelmezesere vagy kepes. Igy nem javaslom.

--
|8]

.

Mert aztan Linus volt az elso, aki a content-adressable FS-t vagy a distributed version controlt kitalalta. Ja varj, nem.

Nem is allitottam ezek kozul egyiket sem. Gitrol van szo, nem annak egyes epitoelemeirol.

--
|8]

"starlight:git hijaszu$ git shortlog -s -n"

--no-merges nélkül ez azért eléggé torzít az arányokon.

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....

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

Senki sem dolgozik vele együtt, egy kisszobában tartják elzárva, csak sajnos vele zárták a root passwordöt is, így mindenki neki könyörög, ha kell valami. :)
--
zsebHUP-ot használok!

Ah, gondoltam hogy valami ilyesmi lehet a háttérben! :)

V.42bis error correction

  • "Fuck this 'hardvert venni tudni kell' shit, I'll just hack up a shitty monolithic kernel - Lunatic Torvalds
  • 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.

    mellesleg sokszor nekem is sokkal kifejezőbb valamire azt mondanom ez egy rakás szar, mint kiselőadásban kifejteni pontosan mi bajom van vele, hol és hogyan lehetne továbbfejleszteni, milyen egyéb pozitív értékei vannak

    +1

    En is szidtam mar igen sok mindent eletemben. Aztan neha felulbiraltam magam - neha nem.

    --
    http://www.micros~1
    Rekurzió: lásd rekurzió.

    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.

    Nem-e? Az óvoda ott fejeződik be, hogy a "szar az egész" után van egy alaposan kifejtett rész, ami úgy kezdődik, hogy ", mert".

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

    +1

    +1

    Hiányzik a listáról: Systemd

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

    +1 :-D

    Feltehetoleg azert, mert azt csak azok utaljak, akik nem ismerik, Linus meg ugye ennel profibb. </troll>

    --
    |8]

    Én ezzel fordítva vagyok. Eleinte azt hittem, hogy ez egy tök jó dolog, de ahogy egyre inkább megismerem egyre gázabb az egész. Linus meg sajnos leszarja, hogy mi van userspace-szel.
    ---
    Régóta vágyok én, az androidok mezonkincsére már!

    Linus systemd user.


    Amit nem lehet megirni assemblyben, azt nem lehet megirni.

    0/10 tryhard

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

    Miért? Illetve máshogy: mi van helyette? :)

    A miertre ott linus valasza, amint irtam egyet ertek vele, tehat "XML is nasty to parse for humans, and it's a disaster to parse even for computers".
    Helyette meg peldaul ott a JSON :)

    te is azt hiszed, hogy az XML az kacsacsorok kozotti egymasbaagyazott stringek halmaza, de baromira nem. Arra tenyleg jo a JSON. De az XML sokkal tobbet tud, mint a JSON, meghozza interoperabilis modon, mivel szabvanyos es minden fontosabb platform implementalta a szabvanyt.

    Mivel mar be is skatulyaztal a "te is azt hiszed"-el a parbeszed koztunk itt veget is ert.

    butthurt much?

    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)

    Mutass kerlek egy olyan cross-platform XML libraryt, ami nem egy security bughalmaz. Ha bonuszkeppen meg kenyelmes is hasznalni, az sokat erne.

    --
    |8]

    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)

    Mondom nem security bughalmaz. Nezd meg a libxml2 CVE listajat az elmult par evben. (C nyelvhez egyebkent, mas nyelven nem nyultam XML-hez bohockodas szintnel melyebben.)

    --
    |8]

    Akkor JAXP. Multiplatform, es nem igazan volt hozza sok XML-t erinto security issue. Have fun.

    Koszi, megnezem. Bar azert erre is van CVE szep szammal, de elso blikkre nem rettento veszes, szoval egy probat majd meger. Mondjuk a jelenlegi libem 0 CVE-jenel ez is tobb, de ha ennyit tud az XML lib kozosseg felmutatni, hat ez van. :P

    --
    |8]

    "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)

    és akkor loop oda, hogy a megítélésen nem segít, hogy egy csomóan kóklányolnak az xmlel is, ezért bár úgy néz ki, de mégiscsak marad a bug-by-bug... :)

    [ 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 :)

    Idézet:
    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 :)

    Idézet:
    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.

    Idézet:
    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 :)

    félig off: a kedvencem a SOAP üzenetben stringként utazó XML dokumentum - egy-két kivételt leszámítva azok szidják proaktívan az XML-t, akik nem tudják használni és/vagy nem használják ki a képességeit

    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.

    "De hat van Eclipse!!!44negy!" - random fejleszto a HUProl.
    --
    Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

    Jó, hogy eszembe juttatod! Még mindég nem kaptam választ...

    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.)

    Szerinted mindenütt és minden körülmények között baromi egyszerűen lehet GUI-t használni? Egy hibás paramétert ha meg kell keresni, akkor az "egyszerű" GUI-d hogyan támogatja? Ja, hogy "akkor legyen benne keresés is" - de a hasonlókat is találja meg, stb.

    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.

    Idézet:
    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

    FYI: Az nginx inkabb C-like mint JSON-like
    --
    Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

    > 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....

    ASN.1?

    Fokozod itt a fokozhatatlant... :-)

    Egyebkent nem rossz, de akkor mar inkabb YAML, vagy valami C-like stuff.
    --
    Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

    C-like alatt azt erted, hogy {-t és }-t használ strukturálásra?
    Mert akkor a JSON is az.

    Nem, a C-like alatt azt ertem, hogy a { es } mellett ; a sor lezaro, ami peldaul a JSON-nal nem igy van. De termeszetesen FIXME.
    --
    Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

    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.xlcpp8l.doc/language/ref/strin.htm%23STRIN?lang=en

    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.

    Lehetne, de mint ahogy saxus kollega helyesen ramutatott, nincsenek szabvanyok a validalasara...
    --
    Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

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

    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.

    nemide

    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/)