HOVD 2018 - Kedvenc szövegszerkesztő

Címkék

atom
5% (35 szavazat)
brackets
0% (3 szavazat)
emacs
3% (25 szavazat)
geany
5% (38 szavazat)
kate / gedit / notepad - de/os alap grafikus szövegszerkesztői
11% (83 szavazat)
nano / joe / ed / mcedit / sandy / konzolos egyszerű szövegszerkesztők
14% (103 szavazat)
notepad++
19% (139 szavazat)
sublime text
6% (47 szavazat)
vi, vim / gvim / neovim
24% (178 szavazat)
vscode
11% (80 szavazat)
Összes szavazat: 731

Hozzászólások

Szomorúan látom, hogy a javaslatokból nem lett megfogadva semmi. Így nem tudok szavazni. Az általam használt SciTe nem tartozik egyik kategóriba sem. Talán a Notepad++-hoz áll legközelebb, mert Scintilla alapú mindkettő.

No keyboard detected... Press F1 to run the SETUP

Notepad++ -t szavaztam, de amugy a Nano meg a masik.

Latom meg mindig a vi vezet, probaltam mar parszor ravenni magam h hasznaljam, de ha nem epp CentOS+Red-Hat ot kell mokolni, inkabb maradok a Nano-nal...:)

Amugy ez is erdekes, mert en pl szovegszerkesztot max konfig fajlok modositasahoz, egyszeru scriptek irasahoz hasznalok. Szoval a felhasznalas modjatol is fugg sztm ez a kerdes.

Az "ős" vi egy szívás szerintem, viszont a vim már egy nagyon szuper cucc. Azt használom a legtöbbet, pedig messze nem vagyok egy vim expert (sőt, gyenge amatőrnek számítok). Igazából eszembe sem jut máshoz nyúlni, akár egyszerű konfig editásásról, akár program írásról van szó. Valahogy szépen, lassan szoktam le a grafikus toolokról, aztán az mc-ről (mcedit).

Pl: van néhány fel nem használt parancsbetű az ABC-ben, amire az ember 30 évvel ezelőtt felkonfigurálta a saját ötleteit, ma meg vacakolni kellene, hogy vim alatt is ugyanazokat csinálják :-) (Én anno g és v parancsokat is definiáltam magamnak, és jól meg is lepett a vim, amikor kiderült, hogy ott ez bizony valami más.)

De amúgy isten bizony találtam már olyasmit, amit a vim másként csinál, mint az ősi vi. (De mivel jó pár éve volt, ezért már nem emlékszem, mi volt az.)

Jav: már meg is van: a Q parancs teljesen másként múködik.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nekem a vim/vi-nel azt magyarazza el valaki, hogy hogyan lehet ertelmesen magyar billentyuzetrol hasznalni.
A j,k,l megy, de az é mar nem.

Amit meg szinten nem tudtam megszokni, hogy command mode-ban hogyan lehetne a sor utolso karaktere utan menni, hogy amikor edit mode-ba valtok, akkor ne kelljen meg egy karaktert arrebb lepni, hogyha utana akarok valamit beszurni.

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

Csak a 2.-ra a válasz(ok) :
a sor (vagy épp a fájl) utolsó karaktere mögé nem tudsz menni, mert akkor az nem az utolsó karakter. Tehát helyesen:

$ - ez sor utolsó karakterére ugrik,
a - ez pedig a(ppend) azaz *mögé* ír (nem pedig i (i)nsert - szerintem eddig ezt használtad, ekkor kell a jobbra lépés)

Vagy még jobb:
I - nagy i- sor első látható karaktere elé szúr be
A - nagy a - sor utolsó karaktere mőgé ír
- és tök mindegy, hogy hol vagyok a sorban.

Ja és az 1. Mit akarsz az é-től? Nem véletlenül a h kellene? (Csak mert azok a mozgató billentyűk: h-j-k-l ; bal szélső balra, jobb szélső jobbra visz. j és k pedig arra, amerre a "farka" mutat - a j farka lefele van, az lefele visz, a k farka felfele mutat és felfele visz)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Jajj, ezt beneztem. De evekig. Mea culpa.

Az i/a-t koszonom. Erre gondoltam.

Akkor a kovetkezo feladvany:) Hogyan lehet kijelolni egy szot, es az osszes tobbi szot a fajlban (mindig csak egyet ugorva), es annyi kurzorod is lesz a fajlban, es egyszerre tudod atirni.
Ha eleve kijelolsz nehany karaktert, akkor nem szot jelol ki, hanem a kijelolest veszi alapul es ugy ugrik a kovetkezo talalatra.

En igy szoktam fuggevenyekben valtozokat atnevezni pikk-pakk. Nagyon additiv, kb. megfelezi a gepelnivalomat... :)
Jo lenne vim-ben is valami ilyesmi.

Ezt visszaolvasva egy kicsit zavaros. Csinaltam egy gif-et:)
https://imgur.com/a/L7VyNLF

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

> Az i/a-t koszonom

Nem jo ez. Mert mindig az i-t szeretnem hasznalni (kurzor ele gepelek), az a "berogzult" mozdulat.
Es csak az utolso karakter utan azert kene az a-t megnyomnom, hogy a kurzor utan tudjak gepelni.
Normal esetben az "a"-t sose nyomnam, mert akkor a kurzor utan kezdene gepelni, ami nem intuitive (semelyik mas program nem gepel a kurzor utan, meg a terminalban is a telikurzor ele gepel)

Egyebkent a kurzor nem a karakteren all, hanem a karakterek kozott. A sorban levo karakterek mint egy tomb elemei, es mindig valamelyik ket elem koze szurja be a karaktert. Szoval *nyugodtan* mehetne az utolso karakter utan (a semmibe), mert logikus.

De nem en fogok megvaltoztatni egy 40 eves hagyomanyt...

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

Probalom-probalom, de nem sikerul.

Itt egy masik pelda:
https://imgur.com/a/gjD5Fvn

Ehhez leirnad, hogy hogyan kell? Ez ugyanaz az eset kb.

Jah igen, a vegen kihagytam egy spacet, ujabb gif:
https://imgur.com/a/8yflAka

A gifek csalokak, a valosagban ennel azert gyorsabban gepel az ember.

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

Az előbbire magyarázat részekben:

yyp: lemásolja az aktuális sort
fD: az első nagy D-re teszi a kurzort
ceRename<ESC>: Rename-re cserél a szó végéig majd vissza parancs módba
fD: a következő nagy D-re ugrik
.: megismétli a Delete->Rename cserét

--
$ grep -c egy$ word.list
100

Ez is viszonylag egyszerű, próbálom magyarázattal:

39G: a 39 sorba ugrik
$: a sor végére áll
CTRL+v: oszlop kijelölés indul
9j: 9 sor le (könnyebb kitalálni ha relatív sorszámozás van a szöveg előtt bekapcsolva)
I <ESC>: kijelölés elejére szóköz beszúrás (nagy i, szóköz és ESC)

--
$ grep -c egy$ word.list
100

Nekem is pont ez a legnagyobb bajom vim-mel. Amerikai kiosztáshoz találták ki. Át tudod alakítani magyarra, de elég nagy munka minden ékezetes billentyűre átdrótozni a funkciókat.

Próbálkoztam egy időben olyan trükkel, hogy automatikusan váltson kiosztást parancs és inser módban. De ez elég körülményes. A megoldás valami olyan lenne, amit az i3wm csinál, ott keybindinget fel lehet venni billentyűkód alapján is, ami nem változik a kiosztással.
No keyboard detected... Press F1 to run the SETUP

Igen, ezeket én is megtaláltam. De vannak DE-k, amik alatt nem működnek. Pl. KDE alatt nem engedi váltani a kiosztást, csak ha a KDE appletjéből állítod. Ha meg a termiálos, konzolos kiosztást akarod váltani, ott meg su/sudóval engedi csak. Szóval szopó, nem egyszerű megcsinálni.

No keyboard detected... Press F1 to run the SETUP

A legelső DE: Vegyük észre, hogy az operációs rendszerek általában "amerikai nyelven íródtak". :-)
Sőt, a parancsok kiadásához is elegendő a 7 bites ASCII karakterkészlet.
Ezekhez a normál kiosztás az US billentyűzet, de legszívesebben a régóta eldobott DIN szabványút említeném, ahol SHIFT,\,...,/,SHIFT az alsó sor kiosztása.
A billentyűzetből alapvetően két fajta létezik: Az egyikkel "betűket írnak", a másik meg az ún. "szedő", amit nyomdában használnak / használtak.
Az a jó kiosztás, ami mindenhol egyforma. Működik unix, dos, windows környezeteben bármilyen billentyűzeten, de akár soros terminálon is, lassú vonalon is. Nem használhat speciális billentyűket, pl. Fnn, AltGr, Gold (??, vagy valami hasonló, ami a VAX terminálok sajátja).
Mindez megvalósítható repülőékezettel. "Modern" terminálokon a repűlőékezet ÉS az compose char alapból támogatott. Az utóbbi gyakorlatilag CTRL+. és repülőékezet.

Ezzel szemben a nagyon speciális kiosztás csak adott környezetben működik. Amint német, francia stb. billentyűzet elé kerülsz, vagy nem a speciálisan kialakított szekvenciákat kell használnod, rögtön meg vagy lőve.

Az alapismeretek is fontosak, nem indegy, hogy "honnan jöttél". Az "egész világ" tudja, hogy egy fájlkezelőben a "másolás" = F5. Ha feltételezzük, hogy a felhasználó valamit tud, akkor a "másolás" = C(opy). Érdekes módon nem az utóbbi terjedt el (az Xtree(Pro) fájlkezelő használta), köszönhetően Peter Nortonnak és az alap parancskészletet sem ismerő felhasználóknak.

A vim-ben funkciók vannak osztva a ; : , stb. billentyűkre. Na, már most, én mivel még mindig többségében magyar szövegeket írok, így magyar kiosztást használok, szintén gépírva, nyomnám ezekhez azt a billentyűt, amit az amerikai kiosztáson kéne, a megfelelő ujjal, de ezeknek a helyén a magyar kiosztásban egész mások vannak, és nem hajtódik végre az a funkció, amiért megnyomtam. Persze, nyomhatnám a magyar kiosztáson az ;:, gombokat, de a vim szándékosan úgy lett tervezve, hogy ezek a jelek az amerikai gépírásszabványnak megfelelő helyekre mappelődjenek, azaz pl. a ; az alapsori tartás, jobb kéz, jobb kisujj. Én meg nyomkodhatok a magyar kiosztáson AltGr+,-t helyette, ami kapásból két billentyű, egy egész másik, nehezebben elérhető sorban, idegen helyre is esik, távol azoktól a billentyűktől, amihez közel kéne lennie a többi funkciót tekintve. A repülő ékezeteket meg a nyomdát a hajamra kenhetem, ha a vim nem vesz be alap parancsokat, onnantól az egész értelme van oda. Különben is a repülőékezetek is függenek a kiosztásból, mert az egyes kiosztásokon máshol van a ' " stb. Értem, hogy azt javaslod, hogy használjak US kiosztást, de egyrészt gépírni magyarral tanultam, az van az ujjakba beidegződve (igaz csak néhány billentyűben térnek el, de az nagyon alapvető, főleg írásjelek), másrészt egy csomó helyen nem lehet repülőékezeteket alkalmazni, pl. webes text input mezőben. A ’szom sem fog 2019-ben repülőékezetekkel, meg US kiosztással szívni, ha egyszer elérhető másik is, meg van unicode. Ami működik is mindenhol, kivéve a vim parancsainál.

Persze a magyar kiosztás is szerencsétlen, mert egy egyszerű [ ] ; jelet és hasonlókat jól eldugták, egyszerre nyomhatsz mindenféle billentyűt, öt kézzel, és még az orroddal is kell nyomni valamit hozzá, vagy a lábujjal, mire beveszi a keycombo-t.

Mondom, mindez nem lenne gond, mert a billentyűknek van egy általános kódja, ami független attól a karaktertől/eseménytől, amit a kiosztás alapján a billentyű egyébként kivált. Ezt az i3wm ablakkezelőben frankón meg is oldották, de vim-ben nem támogatott, hogy karakterbind helyett univerzális keycode-ot lehessen használni.

No keyboard detected... Press F1 to run the SETUP

Na, kipróbáltam. Végül megoldotta a gondom, annyi, hogy nem :map-et használtam hanem :noremap-et, ami ugyanaz, csak ha keresztben vannak átmappelve a billentyűk, akkor nem zavarnak be egymásnak.

Így átálltam vim-re, ez lett a fő szövegszerkesztőm. Tényleg baromi hatékony. Annyira bejön, hogy azóta egy csomó szoftvert vim-billentyűkkel irányítok, Sway (i3wm-klón Waylandre), Firefox Tridactyl-plugin (a Vimperatort nem fejlesztik), Chrome-on fel fogom tenni a Vimiumot, Evince-ben, de át fogok állni Zathura-ra, ami alapból vim gyorsbillentyűi vannak. Fontolgatom, hogy felteszem a Vifm-et vagy a Rangert a Double Commander helyett. A Ranger jobb lenne, de ami miatt ódzkodok tőle, az az, hogy Python-ban van írva, amit rühellek.

No keyboard detected... Press F1 to run the SETUP

Az fura nekem, hogy én éveken (10+) át használtam mutt-ot levelezésre. vim volt beállítva szövegszerkesztőnek.
Ha egy levelet magyarul kellett megírnom, akkor váltottam magyar kiosztásra és írtam, amit kellett. Ha a magyar szövegnek vége volt, visszaváltottam amerikaira, és vezéreltem a mutt-ot, a vim-et, vagy írtam a leveleket angolul.

A billentyűzet kiosztás váltás nálam ctrl-meta-k kombinációra van kötve, de persze lehetne bámi máson is.

Szerintem egyszerűbb nyomni egy billentyű kombinációt, mint szívni azzal, hogy a kizárólagosan használt magyar kiosztással nehézkes a konzolos programokat vezérelni.

De látom, hogy sokan inkább 10+ éven át panaszkodnak, hogy nehéz, de nem váltanak kiosztások között.

Ez vajon miért lehet?

Emberfüggő. Én pl bár sokszor próbáltam, nem tudom agyban megszokni a folyamatos váltást, maradok a magyarnál, vim meg kódolás közben is,, még ha emiatt egyesek furán is néznek rám. Igaz nem is panaszkodok miatta.

[troll]
Igaz, pythonban nem kell egy rakás fölösleges kapcsos zárójelet meg pontosvesszőt kirakni, az segít.
[/troll]

Nekem úgy tűnt, hogy automatikusan megy. Nyomok egy : után egy entert, és a következő sor elején már behúzva folytatom. Nyomok egy akármilyen sor végén egy entert, ugyanazon a szinten folytatom, ahol ő volt.
Ha nem kell annyira behúzni, akkor backspace megy kifelé a szintek között. A jelölések, és a collapse miatt látom azt is, hogy mennyire kell kimennem (ugyanúgy, ahogy C-ben meg azt láttam, hogy mennyi darab bezáró kapcsos zárójelet kell kitenni).

Whitespaceből szerintem nagyjából pont annyi kell, amennyi más nyelvek normális kinézetéhez is. (Kivéve, ha a külön soros balciciben hiszel, akkor ahhoz még több is :) )

Egyébként eddig sok bajt nekem még nem okozott a "v, lenyilak, >". Kétségtelen tény, hogy magyar kiosztással még mindig kell nyomni egy hülye helyen levő karaktert (már amennyivel az alt+baloldali alsó gombok rosszabbak, mint a shift+jobboldali alsók), de az mégse két cici, meg egy rakás pontosvessző :).

Mondjuk én nem nagyon írok vimben kódot (azt se sikerül megszokni), de úgy emlékszem, a python pluginban vannak a curly blockra ugrálóshoz hasonló move commandok

Három nyelvről tudok, ahol a sor elején a whitespace releváns. Az egyik a kártyára lukasztandó Fortran, a másik a Whitespace, a harmadik meg a Python. Az első esetben a sor első öt karaktere cimkének, a hatodik a folytatósor jelölésének van fenntartva, a másodiknál maguk a whitespace karakterek adják a kódot, a harmadik esetben meg "így könnyen tud bárki szépen formázott, áttekinthető kódot írni".

Nomostan az első kettő indoklás teljesen rendben van. A harmadik viszont - szerintem - ordenáré nagy baromság: ha valaki igényes, akkor tetszőleges programozási nyelven tud szép, áttekinthető, jól olvasható kódot kiadni a kezéből, aki megnem, azt a kötelező beljebb kezdés semmenti meg attól, hogy trágya színvonalon kódoljon - külalak tekintetében is.

Akkor keressen olyan munkát, ahol nem kell pythonnal foglalkoznia. Felesleges azon pörögni, hogy szerintem valami rossz, ha mások többé-kevésbé meg vannak vele elégedve.

- Sz@r a Python mert,…
- Sz@r a C, mert…

Korábbi ilyen szavazásoknál, illetve a „melyik programozási nyelvet érdemes megtanulni” topikoknál ehhez jött még:
- Sz@r a Java
- Sz@r a JavaScript
- Sz@r a C++
- Sz@r a PHP
(Elnézést kérek, ha valakinek a gyűlölt nyelvét kihagytam volna.)

Ha bemegyek egy étteremben, ahol van sütőtökös étel, akkor nem verem ki a balhét, hogy milyen hely ez már, hogy sütőtök is van. Rendelek mást az étlapról. Ha csak sütőtökös étel van, akkor átmegyek egy másik étterembe.

Nagyon sok fugg attol, hogy melyik ket kiosztast valtogatod, es milyen a billentyuzet fizikai kiosztasa.
Annak idejen US billentyuzettel kezdtem (jo voltak elotte Commodore-ok is meg egy 286-os LG notebook, de ez most mindegy). A US billentyuzethez aztan lehetett magyar matricakeszletet kapni, stb. Ezt a kiosztast mar meg sem talaltam a neten.
Aztan nemet nyelvteruleten mindig nemet bllentyuzetet kaptam, es ugyan szereztem US billyentyuzetet, de meguntam a jatekot, hogy ha barmikor masnak a gepehez ultem vagy forditva, akkor csak a szenvedes volt. Ehhez jott meg hozza jo 15 eve, hogy mar nem PC-ket kaptam, hname notebookokat termesztesen nemet billyentyuzettel, tehat a US billentyuzetet lassan, de biztosan el kellett felejteni, mert a fizikai kiosztasa is mas volt. Az erdekes es udvozlendo, hogy a nemet billentyuzet es a normal magyar bilyentyuzet azonos fizikai szerkezetu, de valamilyen oknal fogva nem csak az ekezetes betuk, de pl. 0, es a specialis karakterek is mashol vannak. Sot meg a kozos ekezetes betuk sem ugyanott vannak, ami kulon szivas. Gratulalok. Amugy a magyar billentyuzet tudna mindent, amit a nemet, 1 krakter kivetelvel: Ä. Szuper, tehat megsem jon szoba, hogy kizarolag magyar billentyuzetkiosztast hasznaljak. Nem beszleve arrol az aprosagrol, hogy a nemet billentyuzet lenyegesen jobb programozas szempontjabol, mint a magyar, de mondjuk ezzel meg egyutt lehetett volan elni. Vegulis lassankent leszoktam a magyarrol, es csak nemetet hszanalok. Ennek eredmenyekeppen az ekezetek mentek a levesbe. Lusta vagyok? Biztosan. Persze ma is felkonfiguralom a billentyuzeten a kiosztas valtast, es kiveteles esetben hasznalom a magyar kiosztast, amikor kellenek az ekezetek. Ilyenkor az ö helyett tipikusan é-t az ö helyett pedig ő-t utok, mert a szemem becsap.

Arrol most ne ertekezzunk hosszan (pedig jo sokaig lehetne vesezni), hogy a karakter kodolasokkal ezen felul meg mekkora szivas van, tehat minden szempontbol jobb a nyugat europai ISO 8859-1 -ben leledzeni. Tudom itt jonnek a majd a worksforme-k meg UTF meg egyeb dumak. Nem ma szuletett barany vagyok, nem ma kezdtem szamitastechnikaval folglakozni. Rengeteg anyag es file rendszernev, stb. van nem UTF kodolasban, csak hogy egy egyszeru peldat emlitsek. Ma sem hasznal mindenki egysegesen UTF-et, sot. Nem olyan regi trotenet, hogy pl. a SquerrelMail amerikai hoszton, renszeresen osszebarmolta a karakter kodolast, stb. ....

En mara mar vallalom a lustasagot, meg az ekezet nelkulesiget. Eleg energiat tettem mar ebbe a temaba feleslegesen, meguntam a kinlodast.

Háát, tényleg lehetetlennek tűnik magyar informatikusnak ékezetes betűket írni egy US billentyűzeten! Sőt, az Ä bötű azmegazmá' végképp lehetetlen! Nekem is csak azért sikerült, mert olyan öreg vok, hogy akkoriban még az informatikát is számítástechnikának hívták. ;)

Arrol most ne ertekezzunk hosszan (pedig jo sokaig lehetne vesezni), hogy a karakter kodolasokkal ezen felul meg mekkora szivas van, tehat minden szempontbol jobb a nyugat europai ISO 8859-1 -ben leledzeni. ...
Ezek a dolgok teljesen másról szólnak, és ennél kicsit bonyolultabbak.
Tudtad-e, hogy a lenyomott billentyű amíg eléri a programot, úgy 8..12 konverzión megy (mehet) keresztül? Ugyanakkor a program által kiírt betű esetén ez a szám 6..8 körül van.
Ha normálisan szeretnél írni, akkor bármilyen rendszeren van lehetőség a billentyűzet viselkedésének tetszőleges módosítására. Ez általában legfeljebb az első két konverziót érinti.

Azt sem lehet kijelenteni, hogy milyen karakterkészletet kell használni a fs szinten. Ha nem találod el, akkor a mount sem fog sikerülni. De a lényeg: Mindez független a billenyűktől.

"Háát, tényleg lehetetlennek tűnik magyar informatikusnak ékezetes betűket írni egy US billentyűzeten! Sőt, az Ä bötű azmegazmá' végképp lehetetlen! Nekem is csak azért sikerült, mert olyan öreg vok, hogy akkoriban még az informatikát is számítástechnikának hívták. ;)"

Ilyet hol olvastal, hogy ez problema volt? Az US billentyuzeten magyar kiosztast hasznaltam, ami fel is volt matricazva. De ennek a kiosztasnak mar a leirasat sem talatam meg a neten, bar elvileg az USA-ban elo magyarok ilyen kiosztast hasznalhatnak celszeruen.
Az Ä a rendes magyar billentyuzet (tehat nem US fizikai es logiakia) kiosztasrol hianyzik, es azert nem tudtam a magyar billyentyuzetet teljes erteku nemet es magyar billyentyuzetkent hasznalni layout valtas nelkul. De mi volt ezen nem ertheto?

"Ha normálisan szeretnél írni, akkor bármilyen rendszeren van lehetőség a billentyűzet viselkedésének tetszőleges módosítására. Ez általában legfeljebb az első két konverziót érinti."

Ismet nem ertem, hogy hol olvastal ilyet, hogy ezt nem tudom. Termeszetesen tobbfele kiosztast hasznalok ma is, csak ritkan, mert maceras. De ez a fentiekbol egyertelmuen kiderul.
Nekem egybekent ez a normalis iras, mert ez illeszkedik a legegyszerubben a jelen szamitastechnikai korulmenyekhez.

Az összes költői kérdésedre a konkrét válasz: Itt olvasom. :)
Ezek szerint a többféle kiosztás, matrica, anyámtyúkja virtuóz alkalmazásának ellenére "a jelen szamitastechnikai korulmenyek" hibájából nem tudsz magyarul írni. :-D
Én viszont egy Windows XP SP2-ről, de *nix soros terminálról, ssh bejelentkezésből, bárhonnan is tudok. Váltás nélkül írom az ä-t is. Minden macera nélkül, US billentyűvel, vi(m) editorral is. ;)
Szóval mégiscsak worksforme - neked meg nem.

Ne beszelj mar marhasagot. Persze, hogy meg tudom csinalni, csak maceras, es leszoktam rola, illetve csak akkor teszem, ha nagyon szukseges. Es nem mindig szukseges. Pont errol szolt a tortenet. Egyebkent nem figyelsz (erre sem), mert nem az ä-t nem adta ki, hanem az Ä-t.

Szerintem azert az erto olvasassal lehetnek gondjaid, mert eddig minden altalam leirt informaciot osszekvertel, osszemostal, es megprobaltal olyan kijelenteseket cafolni, amiket nem tettem. Ez vajon az ekezetek hianya miatt van? Vagy a WinXP SP2 a *nix ssh terminalon keresztul torzitja az informaciokat? Vagy szuksegesnek erzed az altalanos iskalai szamitestechnikai tudassal villogni, hogy te bezzeg be tudsz allitani mas billentyuzet kiosztast... :-)

Lassan irom, hogy megertsd: mindenki be tud allitani tobbfele kiosztast. Hasznalni szar.

Én amerikai kiosztást használok. Jelenleg éppen UK festésű billentyűzeten, de használtam már US kiosztást magyar, francia, portugál, német és dán billentyűzeten is.

Nem érdekel, hogy mit festettek a gyárban a billentyűkre, nem nézek oda.

Ha magyarul akarok írni, ékezettel, akkor átváltok. Ha már nem, vagy számokat kell írni, akkor rögtön vissza, mert utálom, hogy a 0 helyén ö betű van.

Igen persze, de ez ket dolgot feltetelz:
1. 10 ujjas vakiras - nekem valami sajat (fel)vakirasom van, ami persze tudom, hogy tok rossz, de nem birtam atszokni rola a normal vakirasra
2. mindezt legalabb ket kulonbozo kiosztassal tudod - sajnos en ugyan tobbszor atszoktam egyik kiosztasrol a masikra, de egyidejuleg kettot vakon nem tudok, ezert egy kiosztasvaltaskor keresgetnem kell emlekzetbol a billentyuket, ami azert elegge lassu es idegesito (a legszarabb, hogy a 0 es az irasjelek is mashol vannak)

Ezert bar hasznalok tobbfele kiosztast (nemetet alapbol, es magyart, ha ekezettel akarok irni), de csak, ha nagyon szukseges. Mindig arra torekedtem, hogy lehetoleg valahogy egy kiosztassal lefedjem az igenyeimet, de ez sajna nem sikerult 100%-osan, ahogy a fentiekbol kiderult. ;-)

Én is csak másfelet tudok: US teljesen, magyarban az ékezetes betűk és alap írásjelek és € szimbólum.

Ha valami trükkös dolog kéne, pl. >#&@{}<[]\|$~ akkor váltok amerikai kiosztásra, mert ott tudom, hol van. Magyaron meg max. tippem van és keresgélni kell. Mondjuk a @-ot általában elsőre, néha másodikra eltalálom.

magyar kiosztáson egyébként ezt találtam, amikor az előző sorhoz próbálgattam a billentyűket: ä (alt-gr a) Ä (alt-gr e). Nem te kerested?

Je, tenyleg. Meg voltam gyozodve, hogy az alt-gr e, az €. Koszi, meg lehet, hogy ujragondolom, hogy visszaterjek magyarra. Bar a programozashoz iszonyatosan nehez megszokni.

Szerk: letezeik, hogy a szabvany valamikor valtozott? Jo sok eve volt mar, hogy ezt sok vacakolas utan eldontottem.

Kb. 15 éve lehetett, hogy a cégnél a HP-től olyan laptopokat rendelt a cég, aminek nem US, nem magyar, hanem valami US+magyar kiosztású volt a billentyűzete. Gyakorlatilag ez azt jelentette, hogy a HP a gyárban két különféle színnel festette a billentyűket, és rajta volt az US kiosztás fehérrel, meg valami csehszlovák kiosztás kékkel.

Ja, igen, mert elbaxták. És hiába panaszkodott az ember, mert a katalógus és a cikkszám szerint ez volt a magyar másodlagos kiosztású US, szóval ennyi. :-)

Erre már csak egy frappáns hasonlat jut eszembe: A zsemle is azért szar és felfújt, mert az userek akarták. ;)

Kíváncs lennék, milyen észlény fejéből pattant ki a 101 gombos "szabvány".
- A funkcióbillentyűk felülre kerültek. Van aki csuklótámaszt használ, de minek - minduntalan át kell nyúlni az egész fölött.
- Az esc hasonló.
- Az a négy külön nyíl nem túl ergomókusosan van elhelyezve, meg duplikált. A felette levő blokk ugyanígy.
- A fentiek által elfoglalt helyet szélesítésre használtam volna. Ezzel nem lenne az enter legalább öt féle formájú. Ráadásként normálisan lehetne elhelyezni az angolnál jóval több betűt tartalmazó ábécét.

Persze, ha a qwerty is csak véletlenszerűen alakult ki, akkor csak szívjon a sok paraszt.
Bár az is lehet, hogy nem véletlenszerűen. Talán csak mára csak elfelejtődött az értelme. ;)

Nem vitatom a végső következtetést. De nem lett volna baj, ha a szerző a szakirodalom tanulmányozása mellett egy írógépet is megnéz alaposan. Ha két betű egymás mellett van, akkor a hozzájuk tartozó karok nincsenek egymás mellett. Mert a betű alatti és feletti betűk vannak a szomszéd karokon. Így viszont az egymás melletti betűk általában* 4 karnyi távolságra vannak.

*: Azért általában, mert már rég láttam közelről írógépet, így nem merem biztosra állítani, hogy a széleken is így van.

Az a négy külön nyíl nem túl ergomókusosan van elhelyezve

Ha manapság egy laptopon a négy külön nyíl így van elhelyezve, mint amit kifogásolsz, összeteszem a két kezemet. Az, hogy 3 billentyű helyére teszik be a négy irányt, az sokkal szarabb. Gondolom, az apple kezdte el, mert szép, más meg nem számít. A sok kretén meg szolgaian lemásolta, mert ha az apple valamit kitalál, akkor másolni kell, mindegy, hogy jó vagy rossz.

Nem foglalkoztam a billentyűzetek „történelmével”, így nem kizárt, hogy tévedek, mert a személyes tapasztalatom nem felel meg a történelmi tényeknek. Én sokkal korábban láttam fent elhelyezett funkcióbillentyűket, mint csuklótámaszt. Ha a csuklótámaszt később találták fel, akkor két reális lehetőség lett volna:
- A csuklótámaszt úgy kialakítani, hogy ne kellejen „átnyúlni az egész felett”.
- A csuklótámasz igényeinek megfelelően áttervezni a korábbi billentyűzetet.

Qwerty: A lentebb már említett összeakadás elkerülése mellett az is szempont volt, hogy az angol nyelvben (amerikai feltaláló) gyakran előforduló betűk minél kevesebb ujjmozgással legyenek elérhetőek. Az más kérdés, hogy később nagyméretű irodalmi szövegek statisztikája alapján kiderült, hogy a betűk gyakorisága az angol nyelvben nem olyan, mint ahogy azt a feltaláló gondolta.

Ha egy projekt-könyvtárat egyszerre, kompletten kell kezelni vagy, ha egy IDE-re van szükség akkor atom.io, de arra, hogy grafikus felületről kinyissak egy fájlt egy kommentelt sort megszüntetni vagy egy elérési útvonalat átírni, arra Geany. Terminálban, pedig feladat függő, hogy Vim vagy mcedit.

Pont ugyanez.

Az atom.io-ban a Ctrl-D, meg a Shift-Alt kurzor fuggove tesz. Neha meg a Ctrl le,fel nyilakat is hasznalom.
Szerintem baromi gyors igy.

---
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értelműen a Notepad++. A többi GUI-s szövegszerkesztő mind bloat, 200-300 MB memóriát megzabálva képes csak értelmesen működni.

Azt nem próbáltam. Trinityt fejlesztik még egyáltalán, vagy csak amolyan hirtelen felindulás volt és annak a fejlesztői is beálltak a fősodorba?

Legutóbb, mikor próbáltam a Gtk3 appokat Qt3 köntösbe öltöztető gtk3-tqt-engine-trinity elég bugos volt, sok minden appot szarul, összecsúszva jelenített meg, néhol fekete négyzetekkel és előfordult egy-két crash is. Kb. egy éve próbáltam utoljára.

> Trinityt fejlesztik még egyáltalán

Fejlesztik.

> és annak a fejlesztői is beálltak a fősodorba?

Éppen ellenkezőleg.

Még mindig karbantartják pl. az aRts-ot, ami a KDE3 saját audio layere volt, hogy a rendszer tudjon futni ALSA-n is, meg OSS-en is, (mert a KDE3 nem volt Linux-only, ment FreeBSD-n, meg Solarison is) és így nem kell felrakni a rohadmány-hulladmány pulseaudio-t, ami nem elég, hogy leakel mint egy megfúrt szippantóskocsi, meg olyan ordenáré torzításokat bírt csinálni, hogy nemhogy nekem, de még a hangfalnak is fájt, de ráadásul még be is ragad a lejátszás leállítása után a hang és az utolsó allokált soundbuffer ott loopol recsegve-ropogva, mint egy gramofon, amibe belebasztál egy csorba csavarhúzót. Persze az aRts sem hibátlan, de századannyi hibája sincs (tíz év alatt, ha kétszer volt olyan, hogy valami rejtélyes okból kifolyólag összeomlott), mint a pulse-nak és sokkal kevesebb erőforrással is beéri.

De épp most készül el lassan a Devuan repojuk is, mert a systemd-ből sem kérnek. Asszem a Slackware is full támogatott már a kezdetek óta.

De a legjobb példa: volt anno téma, hogy mivel a KDE4 nem konkrétan a Qt4 miatt szar, hanem maga a KDE4 szar, úgyhogy lehet át kéne állítani a kódbázist Qt4-re (és megmutatni a KDE Teamnek, hogy mennyivel jobban jártak volna, ha a rommá konfigurálható KDE3-at folytatják Qt4 alapokon és nem jönnek azzal a rommábutított KDE4-gyel), de szerencsére végül elvetették és a saját Qt3 forkjukba (TQt) portolnak vissza szükséges dolgokat a Qt4-ből.

Mondom ezt úgy, hogy a Qt4-gyel komolyabb bajom a memory footprintet leszámítva nincsen, még gyenge hardware-en is elfogadható sebességgel fut, pláne, ha a lentebb említett GTK3-hoz mérem. A KDE4-gyel sem az volt a bajom, hogy Qt4-es, hanem az, hogy lassú, bloated és bugos. Többet crashelt, mint ment, lazán felfalta az akkori gépem 2 GB-ját és olyan lassú volt, hogy a lajhárok Mig-29-esnek tűntek mellette.

Aztán próbaképp kipróbáltam a szintén Qt4-es RazorQt-t, ugyanazon a gépen és stabil volt, nem ette meg reggelire a RAM-ot és még a sebessége is elfogadható volt. (Persze a KDE3-nál lassabban futott.) Tehát Qt4-gyel simán lehetett többé-kevésbé elfogadható rendszert építeni, csak a KDE Team-nek nem sikerült. Aztán a RazorQt csapat összeállt a GTK2-es LXDE-t fejlesztő csapattal és a két eddiglen úgy-ahogy használható rendszert összemergelték és átállították Qt5-re. És ez szerintük lightweight. Oké...

> Legutóbb, mikor próbáltam a Gtk3 appokat Qt3 köntösbe öltöztető gtk3-tqt-engine-trinity elég bugos volt, sok minden appot szarul, összecsúszva jelenített meg, néhol fekete négyzetekkel és előfordult egy-két crash is. Kb. egy éve próbáltam utoljára.

Ez valószínűleg most is így van, de ez nem a TQt hibája, hanem a GTK3-é. A GTK3 egy bloated, bugware fosrakás. Kerülendő elvből is, meg józan észből is. Nem azt mondom, asztali gépen még elfutkorászik, ha picsalassan is, de próbáld ki egy gyengébb és/vagy régebbi platformon (RPi vagy régi PowerMac). Garantáltan kopaszon fogsz sikoltozás közben kiugrani a csukott ablakon, mert annyira lassú lesz, hogy kitéped tőle az összes hajad. Nem akarom védeni a GTK2-est, de a GTK3-hoz képest még az is istenes. (Meg főleg gyors, csak bugos is, de lehet vele együtt élni.) Ha valami nincs meg Trinity-re, akkor inkább valami GTK2-es, vagy Qt4-es, vagy oldschool toolkites (Motif, XForms, GNUStep, etc.) cuccot használj, szerintem. (Nem feltétlenül ebben sorrendben persze.) Végső esetben Qt5-öst még meg lehet próbálni (én kettőt használok néha: Transmission és Otter), csak az az alkalmazástól függően már nagyon tudja enni a memóriát. Azt mondjuk el kell ismerni, hogy annyira nem lassú, mint amennyire az ember várná, az asztali gépemen pl. egész gyors, RPi-n még épp használható, míg a GTK3 már használhatatlan volt, sőt az még az asztali gépemen is olyan kibaszott lassú volt, mint egy részeg mocsári teknős (meg instabil is), le is töröltem inkább a gecibe, minden alkalmazásával együtt és pinneltem is a faszba, hogy véletlenül se tegye be a lábát a gépemre ez a bloated mocsokhalom.

Szóval a Trinity pont, hogy nem mainstream. Anno kiröhögték őket, hogy semeddig sem fog tartani a projekt, aztán már lassan 10 éve megy. Bajok persze vannak, kevés a fejlesztő, nagyon nyögvenyelősen készül a FreeBSD és a Solaris port (pedig a KDE3 anno mindkettőre volt), vannak bugok is (évtizedesek is, pl. a Dolphin ablakkezelő detached help bubble crash-jét a mai napig nem fixálták meg, pedig ez egy elég bosszantó bug, hiába ártalmatlan és marginális), de alapvetően stabil a rendszer és nyugdtan fel lehet rakni egy 15-20 éves gépre is, alig eszik valamivel többet, mint a Motif-os CDE, viszont valamivel gyorsabb. Mondjuk P3-ason nem próbáltam, de 1.X GHz-es Athlon64-en kezdtem használni (a KDE3-at) és ha lassú lett volna, akkor leváltottam volna, aztán látod, megmaradt (csak már Trinitynek hívják).

Annak idejen en is nagyon biztam bennuk, hogy eletben tartjak a KDE3-as vonalat, de ennyi eroforrasbol nem lehet egy ekkora okoszisztemat fejleszteni, max toldozgatni foldozgatni. Nagyon is fontos lett volna a portolasokat az uj Qt verziokra vegrahajtani, hiszen ma mar annyira nem illeszkedik a mainstream szoftverkornyezetekkel, hogy nagyon keves diztroban tudod telepiteni.(Debian es RedHat vonalon kivul nincs csomag.)

> Annak idejen en is nagyon biztam bennuk, hogy eletben tartjak a KDE3-as vonalat, de ennyi eroforrasbol nem lehet egy ekkora okoszisztemat fejleszteni, max toldozgatni foldozgatni.

Ez azért túlzás. Inkább úgy fogalmaznék, hogy ennyi erőforrásból csak nagyon lassan lehet haladni. Azért vannak új dolgok a Trinityben a régi KDE 3.5.10-hez képest, nem is kevés.

> Nagyon is fontos lett volna a portolasokat az uj Qt verziokra vegrahajtani, hiszen ma mar annyira nem illeszkedik a mainstream szoftverkornyezetekkel, hogy nagyon keves diztroban tudod telepiteni.

Ugyan lettek volna előnyei is a Qt4-re való migrálásnak, de tekintve, hogy a Qt4-es és TQt-s programok tökéletesen megférnek egymás mellett és nyugodtan ki tudod egészíteni a Trinity - egyébként tényleg foghíjas - programválasztékát mással, így azt mondom, hogy többet buktak volna vele, mint amennyit nyertek volna. Az pedig egyszerűen nem igaz, hogy kevés disztribúcióban tudod telepíteni, ugyanis ők saját repositoryval dolgoznak, amit a saját rendszereden hozzáadsz a repo-listhez és máris telepítheted; hozza magával a saját függőségeit is. (Leszámítva az olyan alap dolgokat, mint pl. az X11 és hasonlók.)

> (Debian es RedHat vonalon kivul nincs csomag.)

Ez sem teljesen igaz. Először is, van Slackware támogatás is (bár a latesthez ahogy nézem pont nincs, amit nem értek, mert korábban volt), másfelől meg azért azt meg kell említeni, hogy a desktop Linux disztribúciók elsöprő többsége RedHat-es vagy Debianos csomagkezelővel dolgozik, tehát ezzel azért elég nagy részét lefedték a Linux disztribúcióknak. (Hivatalosan pl. Mint támogatás sincsen, de valószínűleg valamelyik Ubuntu vagy Debianos repositoryból nyugodtan tudsz Mint alá is telepíteni.) SuSe vagy Arch csomagkezelő támogatás nincsen.

Mint fentebb kitrágyaltuk, kevés a fejlesztő, meg az erőforrás. Ha Arch csomagokra van szükség, a forrás nyílt, meg a Trinity devteam is, lehet jelentkezni csomagkarbantartónak és csinálni Arch-os repo-t. Ők csak annyit tudnak megcsinálni, amennyi idejük van, nem lehet elvárni, hogy azzal a pár emberrel minden igényt azonnal ki tudjanak elégíteni. Mint minden underground projektnél, kicsit itt is magadra vagy utalva. Pl. normális appdocker sem volt Trinity alá, nekem pedig kellett volna, így hát portoltam a régi KDocker-t és beküldtem nekik. Megköszönték és beolvasztották. Eddig nekem az a tapasztalatom velük, hogy nagyon segítőkészek, mert érdekük, hogy a Trinity fejlődjön.

A Notepad++ bloat :D Használj MS Notepad-et, az bezzeg nem bloat.

Cseszegetést félretéve Windowson én is a Notepad++-t használtam, azelőtt meg Context-et, az sem rossz, nem bloat, igaz kicsit kevesebbet is tud, mint a Notepad++.

Linuxon kipróbáltam mindenfélét. Sokáig Kate-et használtam (KDE beépítettje), az sokáig kedvenc is volt, de a KDE5-tel érkezett a Kate 5 is, amiből kivettek sajnos egy csomó funkciót. Így váltottam mindenfélére, pl. Gedit, Geany, Atom, de egyik sem jött be, túl fapadosak voltak. Végül a SciTe-nél kötöttem ki, ez végül is Notepad++ klón, kicsit kevesebbet tud, meg nehezebb beállítani (konfigfájlokat kell hegeszteni hozzá, nicsenek a beállítások a GUI-ra kivezetve), de legalább használható, és nem bloat.

Többször próbáltam vim-re átállni, azt nem adtam fel, időről-időre nekirugaszkodok, tanulgatom, próbálgatom. Alap szinten megy e kezelése, de nem tudtam még megszokni fő text editorként.

No keyboard detected... Press F1 to run the SETUP

Nem vicces, inkább csak nevetséges, hogy pont a Notepad++t bloatozod le, még ha viccből is. Főleg azért, mert az alatta lévő Scintilla engine elég profin ki lett optimalizálva. A Notepad++ egyike azon párjukat ritkító appoknak, amiknél a mai napig nem kell félni a frissítésektől, mert bár jönnek-jönnek az új funkciók, soha nem lesz lassabb maga az egész program, sőt 2-3 főverzió között lényeges sebességnövekedés is tapasztalható, azonos hardveren. Emellett, az XP-támogatást is megőrizték. Amiből már jól látszik, hogy profi programozók állnak mögötte, nem sztárfejlesztők, fejlődésmániás divatmajmok vagy GitHub-divatkommitter csicskák.

KDE5-tel érkezett a Kate 5 is, amiből kivettek sajnos egy csomó funkciót

Gondolom, azt is a fejlődés nevében. Persze lehet úgyis, hogy minden évben más editort használok, csakhogy elmondhassam, hogy friss. Én inkább kihagynám ezeket a felesleges köröket. Örülök, hogy végül a SciTenál kötöttél ki.

Egyfelől, SciTe != Notepad++, másfelől attól még, hogy egy program növekszik, nem lesz bloatware. Akkor lesz bloatware, ha a növekedéssel párhuzamosan az erőforráshasználat is kétszeresére, háromszorosára nő meg, még az alapfunkciókat tekintve is. Tehát, tegyük fel, hogy én az 1.77 funkcionalitásával szeretném használni a 4.1.2-t. Ebben az esetben a 4.1.2-nek nem szabad lényegesen több erőforrást (memóriát, CPU-t) felzabálnia, mint az 1.77-nek. Ha mégis megteszi, akkor bloatware. Na, ezt a tendenciát nem sikerült felfedeznem a Notepad++ esetében. Sőt még optimalizálgattak is rajta, aminek köszönhetően nagyobb textfájlok betöltése, scrollozása, bennük való keresés mind-mind gyorsabb lett.

Továbbra is az egyik legszarabb hasonlatokat felhozni képes mérnök úr képviseltetik személyedben.

Nos, nem egy kispolák funkcionalitására vágyom, ezért nem használok sima notepad.exe-t és edlint sem. A hasonlatod úgy állná meg a helyét, hogy van egy közönséges, korszerű alacsonyfogyasztású autó, amivel lehet közlekedni, autópályán gyorsan menni, illetve van egy terepjáró, amivel lehet közúton, autópályán és azon kívül is menni. A terepjáró sokkal többet fogyaszt közúton is és nem lesz olyan gyors, mint a sima autó. És igen, ebben az esetben a közúton használt terepjáró technológiai bloat. Az is technológiai bloat, ha megtehetnéd közúton ugyanazt az utat egy sima autóval, de te inkább átgázolsz árkon-bokron-földutakon a terepjáróddal, ami ebben az esetben is többet fogyaszt, mintha az alacsony fogyasztású autóval mentél volna.

Félreértések elkerülése végett: A terepjáró a Sublime, a Notepad++ az alacsonyfogyasztású autó. A közút a Windows, az összes többi út az összes többi platform. Ettől függetlenül, a Notepad++ rendelkezik a Sublime funkcionalitásával és mindezt megoljda harmad-negyed annyi erőforrásból. Te most gyakorlatilag a hatékony szoftverek ellen kelsz ki, egy csiligány, bloated példányt védendő.

Te írtad: "az 1.77 funkcionalitásával szeretném használni a 4.1.2-t." - A 4.1.2 egy V8-as turbós sportverzió, az 1.77 az adott tipus korábbi, 4 hengeres szívó motoros verziója. Te a V8 turbós sport kiviteltől várod el, hogy a 4 hengeres szívómotorral szeret funkcionalitását (elvisz A-ból B-be, 50/90/130 tempóban) használva ugyanannyit fogyasszon, ugyanannyi legyen a szervízköltsége, illetve valamennyi egyéb kapcsolódó ráfordítás, mint a 4 hengeres szívómotorral szereltnek.

Igen. Ezt várom el. Mivel van mellette olyan másik gyártó kocsija (Notepad++), ami egyszerre képes hozni a szívómotoros fogyasztást a V8-as turbós sportverzió legtöbb hasznos tulajdonságával. Adott esetben amúgy még többel is, mert a Notepad++-hoz képest a SciTe azért elég fapados. Emellett, a Notepad++ új verziói, bár többet tudnak, nem esznek több erőforrást, mint az előző verziók. Sőt sok esetben kevesebbet esznek. Ezt hívják fejlődésnek. A Sublime, illetve a két véglet SciTe verzió közötti erőforrásigény-különbséget hívjuk erőltetett növekedésnek.

Azt írtad, hogy az adott szoftver 1.x verziójának a funkcionalitását használva a 4.y verzióban azt várod el, hogy a 4.y verzió csak annyi erőforrást használjon, mint az 1.x verzió. És mégegyszer megkérdezem: ki a fenét érdekel (rajtad kívül), hogy a CPU használat mondjuk 5, vagy akár 10%-kal is megnő? Meg a RAM felhasználás tejószaúatyaúristen, nagyobb lesz, és ex has 45M helyett kell neki 76M? Ki a búbánatnak lesz ettől gyereke? Senkinek, mert _elfér_. Egy 6-8 éves gépet sem igazán tudsz desktop felhasználással megizzasztani - és nem, ne mondd, hogy nem kellettvolna a régebbiek helyett újakat kifejleszteni, mert _ugyanakkora_ vagy kisebb(!) környezeti hatással (nagyobb integráltság, kisebb méretű PCB, doboz, egyebek) jóval nagyobb számítási és tárolási kapacitást adnak az újabb eszközök, ráadásul energiafogyasztásban is körberöhögik a néhány generációval korábbiakat.
Tudom, most azzal fogsz jönni, hogy de nem kell, mert forgalmazzák csak szépen a régi eszközöket, fejlesszenek öt évig, és a termékciklust ehhez az öt évhez igazítva ennyi időnként jöjjenek ki újdonságokkal. Nomostan CPU-gyártóban pécés körben vannak legalább ketten. Ha az egyik belengetné, hogy ő öt évig csak fejleszt, de új terméket nem hoz ki, a másik mit csinálna? Neeem, nem lépné meg ugyanezt (csak legfeljebb 1-2 esetleg három év múlva), hanem kényelmesen kihozna mondjuk egy év múlva a versenytársénál jobb, gyorsabb, hatékonyabb (elektromos teljesítményfelvételben jobb, számítási kapacitásban jobb) eszközt,amivel a maradék négy évben letarolná a piacot.
A gazdaság több szereplős verseny, erről (is) elfelejtkeztél. Ha meg az AMD és az Intel is kart-karba öltve meglépné az öntökönbökős öt éves termékciklusra váltást, akkor bővenlenne ideje a 64 bites ARM prociknak feljönni, ha másütt nem, akkor a desktop-on. Ja, hogy úgy gondolod, hogy világméretűen kötelezően valami világkormány kötelezné erre az összes gyártót? Öt év alatt akár új versenyző is megjelenhetne a piacon, és készíthetne újabb, hatékonyabb eszközöket - csak pénz kérdése, és ha tudott dolog, hogy a versenytársak öt évig nem léphetnek piacra újdonsággal, akkor simán tarolhatna az új "versenyző". Vagy talán úgy gondolod, hogy öt évig senki sem léphet ki a piacra újdonsággal, és minden ötödik év adott havának adott napján rukkolhatnak elő az aktuális verzióval, akkor is ha közben indították a fejlesztéseket? Ugye az nem engedhető meg, hogy a többiek után hetekkel-hónapokkal jöjjenek ki valamivel, hiszen akinek ezt megengedik, az versenyelőnyhöz jut azzal,hogy tudja, mivel kell versenyeznie.

csak levezettem a hagymázas marhaságaid néhány következményét...

Azt írtad, hogy az adott szoftver 1.x verziójának a funkcionalitását használva a 4.y verzióban azt várod el, hogy a 4.y verzió csak annyi erőforrást használjon, mint az 1.x verzió.

Igen, ezt írtam. Hányszor kell még ezt átrágni? Amennyiben lehetséges egyik szoftver részéről, hogy a régebbi verziók és az újabb verziók között ne legyen az alapfunkcionalitásban szemmel látható, munka közben tapasztalható lassulás, akkor ez úgy gondolom, nem irreális elvárás másik szoftverrel szemben.

ki a fenét érdekel (rajtad kívül), hogy a CPU használat mondjuk 5, vagy akár 10%-kal is megnő?

Azt, akinél nem 10%-kal nő meg, mert nem csiligépe vagy i3-i5-i7 szériája van. Azt, akinél ami nálad 10%, az nála 50% (egy magon 100%) és bőven érzi a lassulást. Azt, akinél kevesebb memória van a gépben. Azt, akit alapvetően idegesít, hogy egy alkalmazás sokkal több erőforrást zabál el, mint amennyire szüksége lenne, pusztán azért, mert szoftverfejlesztőék lusták voltak normálisan optimalizálni, helyette inkább bloated frameworkökben kényelmeskedtek. Azt, aki felfogja, hogy minél többen használnak egy szoftvert, annál több energiapazarlást okoznak az adott szoftver bloated ciklusai. Ha csak 1 Wattal emelkedik meg a számítógép fogyasztása a magasabb CPU-igény miatt, az is megawattokban mérhető, ha pl. milliók használják.

Meg a RAM felhasználás tejószaúatyaúristen, nagyobb lesz, és ex has 45M helyett kell neki 76M? Ki a búbánatnak lesz ettől gyereke? Senkinek, mert _elfér_.

Igen, ennyi még elfér, még 2 GB-n is. De 200-300 MB memóriazabálás a nagy semmire az már nem fér el. Ha meg mégis elfér, akkor is derogál és ha még a CPU-bloat, meg az akadozás is társul hozzá, akkor máris nyomom az uninstall gombot. Mondom, még egyszer: Próbálj meg egy Sublime Textbe megnyitni néhány hosszú textfájlt, majd nagyíts bele a szövegbe ahogy csak tudsz. Fogsz tapasztalni jókora CPU bloatot, akadozott nagyítást, felesleges memóriazabálást. Linuxon és WIndowson egyaránt. Majd csináld meg ugyanezt egy Notepad++ -ban. Semmiféle lassulás nem lesz, a CPU használat a béka segge alatt. A memóriahasználat egyáltalán nem emelkedik. A két program között 8x-os különbség van memóriahasználatban és több, mint 10x-es CPU használatban, legalább is az én Turion 64-emen.

_ugyanakkora_ vagy kisebb(!) környezeti hatással (nagyobb integráltság, kisebb méretű PCB, doboz, egyebek) jóval nagyobb számítási és tárolási kapacitást adnak az újabb eszközök

Az átkozott befektetőlogikád biztos nagyon jól hangzik egy árajánlatban, egy céges jelentésben, vagy egy marketinganyagban, de a valóság ennél sokkal cifrább. Méghozzá azért, mert alapvetően nem lenne szükség nagyobb integráltságra, számítási kapacitásra, amennyiben a szoftverek nem híznák ki folyamatosan a rendelkezésre álló hardvert, köszönhetően annak, hogy ma már minden jöttment csicskát felvesznek kódolni, csakmert hiányszakma™ és látott már StackOverflowt életében. Szarráfizetik őket, miközben meg nagyságrendekkel silányabb, csapnivalóbb és értéktelenebb munkát végeznek, mint akik a hardvereken dolgoznak. Csak ugye a hardvert nagyon olcsón lehet tömeggyártani, a rabszolgabéren fizetett távol-keleti munkásoknak köszönhetően. Akik egyébként simán megérdemelnék ugyanazt a bérezést, mint egy jöttment webökör, aki sablonokból gányol össze egy-egy céges honlapot. Ugyanis intelligencia több nem kell hozzá. Tehát, jelenleg a javak szélsőségesen egyenlőtlen eloszlásán, az olcsó szénenergián, az ez által okozott mérhetetlen környezetszennyezés büntetlenségén élősködik a szoftveripar burzsoá mérnök úr rétege. Te pedig ezt helyesled.

Ha az egyik belengetné, hogy ő öt évig csak fejleszt, de új terméket nem hoz ki, a másik mit csinálna?

A másik szépen előre rohanna a semmibe és defektes, gyártási, tervezési hibás processzorokat dobna piacra, mert olcsóbb, mint újratervezni. Gondolom, az megvan, hogy az AMD az elmúlt évtizedben volt, hogy több évig nem tudott letenni semmi érdemit az asztalra, miközben az Intel fosta magából a Spectre/Meltdown elektronikai luxushulladékot. Kihoztak úgy 6 generációnyi processzort, hogy effektíve 70%-ot gyorsult egy mai 8. generációs Intel egy 2. generációshoz képest. Ami átlagosan generációnként kb. 10% gyorsulás. Az Intel már nem képes valódi fejlődést felmutatni és ezt úgy igyekszik ellensúlyozni, hogy köztudottan tervezési hibás, csak lassulással javítható processzorokat dob piacra (Coffee Lake, Cannon Lake), innovációt hazudva, továbbá szándékosan szoftveres elavulásra ítél olyan hardvereket, amik még tökéletesen alkalmasak lennének a mai korszerű szoftverek (pl. Windows 10, Chrome stb.) futtatására. Mint például a 2. generációs processzorok, amihez már nem fognak soha kiadni chipset és video drivert Windows 10-re, így előbb-utóbb a Microsoftnak is dobnia kell, ha csak nem akarják ők karbantartani a legacy drivereket, illetve sajátot írni hozzá. Tehát, végső soron, az Intelnek köszönhetően lesz elektronikai hulladék jól működő számítógépek nagy részéből. A fennmaradó kis részre meg raknak Linuxot, aminek nyilván semmi baja nem lesz a driverekkel.

Ja, hogy úgy gondolod, hogy világméretűen kötelezően valami világkormány kötelezné erre az összes gyártót?

Minek ide világkormány? Ahogy Kína bejelentette, hogy nem vesz át több import elektronikai hulladékot, úgy az EU is bejelenthetné, hogy mostantól kötelezően 10 év garancia és szoftvertámogatás minden alaplapra, processzorra, okostelefonra, esetleg megspékelve egy olyannal, hogy minimum 100% gyorsulást kell hoznia bizonyos szempontokat figyelembe vevő mérés (mondjuk userbenchmark.com toolja) szerint. Persze, jobb lenne a világ nagyhatalmainak összefogni a cél érdekében, de tök simán meg lehetne lépni EU-s szinten is, mellette támogatni a hatékony, optimalizált szoftverek fejlesztését.

csak levezettem a hagymázas marhaságaid néhány következményét...

Koránt sem. Felvázoltad, vadkapitalistáék FUD logikájú gondolatmenetét. Nem tudom őket sajnálni.

"Majd csináld meg ugyanezt egy Notepad++"

Nagyszerű, csak szezont a fazonnal hasonlítasz össze. Másra van, Notepad++ jóval kevesebb olyan funkciót tartalmaz, amire egy fejlesztőnek szüksége van, cserébe jobb a nagy fájl támogatása. Sublime, vscode meg az összes ilyen meg inkább a forráskódok szerkesztésére van kihegyezve, ami ha párezer sornál hosszabb, akkor ott valami már igencsak el van kúrva jellemzően. Notepad++-ban pl. se olyan funkció nincs, hogy egy könyvtárat egyben kezelj, se go-to anywhere funkció (ez kb. mindenben alap már), de még annyi se, hogy legalább a kódban lévő symbolokat felismerje, autocomplete ebből kifolyólag a 22-23 _éves_ Delphi-k funkcionalitását SEM éri el.

Jó a Notepad++, magam is használom bizonyos funkciókra (makrózás benne pl. tök hasznos, bár jó lenne, ha menthetőek lennének a makrók és ne lenne olyan istentelenül lassú, ha sokszor kell megcsinálni, mert retard módon mindig frissíteni próbálja a képernyőn a tartalmat), de attól még helyén kell kezelni, hogy mit tud és mire van.

Szóval kb. olyan összehasonlítást mondtál volna, mintha azt mondtad volna, hogy szar a teherautó, mert nem fér be a garázsba, bezzeg a kispolski.

" legalább is az én Turion 64-emen."

Eddig még P4-esed volt.

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

Notepad++-ban pl. se olyan funkció nincs, hogy egy könyvtárat egyben kezelj, se go-to anywhere funkció (ez kb. mindenben alap már), de még annyi se, hogy legalább a kódban lévő symbolokat felismerje

Egészen "véletlenül" pont azt a három featuret kellett említened, ami a www.sublimetext.com alatt oda van marketingezve a kezdőlapra. Miközben egyébként ezek a funkciók a Notepad++ban is elérhetők, csak esetleg meg kellett volna tanulni használni. Mert amit nem hajigálnak a marketingesek az arcodba csiligány videókkal, az fősodratú mérnök uraságod számára nem is létezik. Nade, vegyük sorra. A Notepad++ meg tud nyitni egész mappákat (File -> Open Folder as Workspace...) és a fájlok tartalmában is tudsz egy lépésben keresni (Find in Files). Sőt ha a baloldali könyvtárfa van fókuszban, alapból az összes fájlban keres. A kódokban lévő symbolokat felismeri, elég rákattintani egyre és ki fogja jelölni a többit. Ez alapfunkció. A go-to anywhere funkció a TagsJump pluginnal teljes egészében megvalósítható. Ne feledjük, hogy Sublime Text 2-ben is csak pluginnel lehetett ilyet csinálni.

Hogy mi az alapdolog és mi nem, felhasználása válogatja, de én egy szövegszerkesztőtől alapvető funkcióként várom el, hogy a szöveg képernyőre renderelése ki legyen optimalizálva. Sokkal inkább alapvető funkcióként, mint egy go-to anywhere fícsört.

a 22-23 _éves_ Delphi-k funkcionalitását SEM éri el.

Nagyon rá vagy pörögve a fejlődésmániás maszlagra, bizonyára ezért szeretsz ennyire az évekkel dobálózni. Attól még, hogy valami 20 éves, nem biztos, hogy haszontalan. Nyilván, a Notepad++ban is az keltett visszatetszést, hogy csiligány, tapicskoló, steril szar helyett normális, klasszikus felülete van, ezért behaluztad, hogy nem tudja azokat, amikről a Sublime Text webökre gondoskodott, hogy az arcodba legyen tolva, ha felmész a honlapjára.

Eddig még P4-esed volt.

Volt az is. Attól még, hogy azt állítom, hogy valami P4-en fut vagy nem fut, nem biztos, hogy fő gépnek is azt használom. Ahogy te is néha benyögöd, hogy P4-en ilyen jól, meg olyan jól fut a Windows 10 és gyorsabban bootol, mint az XP. Mégis inkább a Xeonjaidon .NET-bloatkodsz.

" pont azt a három featuret kellett említened"

Mivel nem használom a Sublimet. Legtöbb tapasztalatom az N++-vel, VS-el, VSCode-al, és a PHPStormmal van.

"A Notepad++ meg tud nyitni egész mappákat"

Ok, ezt elfogadom, régi verzióm van, nem frissítettem. Mondjuk ettől még mindig nem fogja tudni egy projektként kezelni a kódot, mivel még egy fájlon belül is csak szövegfájlként tudja. 6.8.8 még nem tudta, ez van most előttem a gépen.

" A kódokban lévő symbolokat felismeri, elég rákattintani egyre és ki fogja jelölni a többit. "

Viszont az még mindig csak szöveg és nem symbol. Ha nem érted mi a kettő közt a különbség az régen rossz. Notepad++ vs amikor egy IDE ismeri azt, hogy mi az, hogy symbol.

"(Find in Files)"

Ok, de ezt egy picit már meghaladta a tudomány. Ha egy Bar nevű symbolra keresek (értsd: osztályra, metódusra, enumra, stb.), akkor nekem ne dobja már ki az összes létező hívás helyétől kezdve az összes olyan szót is, amiben szerepel ez a három betű. Arról nem beszélve, hogy nagyjából minden olyan szoftver, amiben ezt a funkciót megvalósították tud kezdőbetűre is keresni.

"Ne feledjük, hogy Sublime Text 2-ben is csak pluginnel lehetett ilyet csinálni."

Viszont most már alapfunkció lényegében minden IDE-ben vagy IDE-nek szánt szövegszerkesztőben. (VS, VSCode, JetBrains cumók, stb.)

"de én egy szövegszerkesztőtől alapvető funkcióként"

Tehát elismered, hogy szezont a fazonnal hasonlítasz össze. Ezeket nem általános célú szövegszerkesztőknek szánják, hanem kódtúrásra. Ott kevésbé hangsúlyos igény a 3 gigás TXT fájl megnyitása.

"Nagyon rá vagy pörögve a fejlődésmániás maszlagra"

Hát sorryka, jobb toolokkal, gyorsabban lehet jobb szoftvereket csinálni. Gondolom az autocomplete funkció is csak ilyen fejlődésmániás hülyeség, mennyivel jobb begépelni mindig mindent, mint pár kezdőbetűből, vagy rövidítésből letudni azt. (Ezen feature esetlenségét igen cselesen elhallgattad.)

"Attól még, hogy valami 20 éves, nem biztos, hogy haszontalan."

Attól még nem lesz jobb.

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

"A kódokban lévő symbolokat felismeri, elég rákattintani egyre és ki fogja jelölni a többit. Ez alapfunkció."

Sőt, kérdezek jobbat, mikor fogja a Notepad++ felismerni azt, hogy itt a var az egy Foo nevű osztályt takar valójában? Mert itt ugye a VS nagyon szépen mutatja, hogy az egy osztály, mutatja az összes előfordulását és a deklarálási helyét is narancssárgával. Ezt a Notepad++ sosem fogja tudni, hacsak nem raksz bele egy teljes értékű C# parsert vagy készíted fel a Roslyn kezelésére. De még ott sem fog tudni mindent meghatározni anélkül, hogy ne komplett projektbe, függőségekkel együtt dolgozzon.

https://i.imgur.com/Of4eLTl.png

A leglényegesebb különbség, hogy mivel a szerkesztő tisztában van azzal, hogy mi a kód szerkezete, tud támogatást nyújtani abban, hogy mit csinálj a kóddal. Pl. egy átnevezés itt annyi, hogy megnyomom a refactorban, hogy átnevezés és kicseréli mindenhol az osztály nevét. Hogy miben több ez, mint a search and replace? Hogy nem fogja nekem elbaszni egy másik névtér alatt lévő Foo osztályt. És akkor ez még csak a felszín csúcsa.

Tudom, tudom, az, hogy egy nagyobb projektbe ne kézzel kelljen átírni egy osztály vagy függvénynév helyét, az holmi erőltetett fejlődésmánia és majd jól megideologizálod azt is, hogy a szügyhámot is csak a földesurak extraprofitja miatt találták fel.

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

"a szintaxisfan operalas kepessege mar szerintem is masik kategoriaba helyezi a waret"

Pont ez az a pont, amit szerintem hajbi nem akar megérteni: Sublime, vscode, stb. nem egy kategóriában játszik a N++-al. N++ egy szövegszerkesztő, ami mellékesen támogat némi syntax highlightot meg egy-két alap kódszerkesztő funkciót, a Sublime meg a többiek meg kódszerkesztésre vannak kihegyezve. IDE-k meg az összes többi funkcióra is.

És azt nem érti meg, hogy ezek a plusz funkciók igényelnek némi plusz erőforrást.

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

> a Sublime meg a többiek meg kódszerkesztésre vannak kihegyezve

arra vannak kihegyezve, de a HOVD 2018 - Kedvenc szövegszerkesztő kategoriaban inditotta oket valaki
nem ez az egyetlen kategoria a HOVD-on amit minden ember a sajat szaja ize szerint ertelmez

> ezek a plusz funkciók igényelnek némi plusz erőforrást.

hat a mindenfele file megnyitasa nelkul 460MB memoriat zabalo VSCode (meg gondolom a tobbi electronos szutyok is ilyeneket produkal) eseten ez szerintem nem all meg, es nyugodtan lehet oket bloatnak nevezni meg kodszerkesztokent is
Sublimeot nem ismerem

Vscode őszintén szólva nekem sem a kedvencem. Egy időben JS-re használtam, most max a debuggere miatt veszem elő néha, de ott is úgy vagyok vele, hogy meg kellene néznem, hogy a endes VS-sel belőhető-e a mocha/node

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

Úristen, 460MB... Lehet még 4GiB-nál kevesebb memóriával értelmes gépet kapni? Annak ez bő 10%-a, és nem sokkal mászik feljebb, ha egy komplexebb projektre ereszted rá, akkor sem. Cserébe jóval gyorsabban tudsz benne dolgozni, az idő meg pénz, és ha néhény hét alatt megspórol ezzel a mérettel egy újabb memóriamodul árát munkaidőben, akkor bőven megéri.

Engem csöppet zavar, hogy a notepad++ nem natív linuxos progi, mert hiába enne kevesebbet mint akár a geany, de kell alá egy komplett wine.
Szóval érdekelne, hogy miben tud többet nyújtani a notepad++ a geany-nél (amiért érdemes ezt bevállalni)?
---
Why use Windows, if you have open doors… to Linux

Saját szövegszerkesztőt használok.

> Sol omnibus lucet.

A sublime text-et van aki ismeri használja és úgy tart jobbnak mást? Melyiket miért? Vagy a pénz miatt nem kedvenc?

Annyi jo open source vagy ingyenes szovegszerkeszto van, olyanok is, amik jo reszben hozzak a sublime text kepessegeit is. Miert fizetne valaki 80$? Mi az elengedhetetlen hozzaadott ertek?
En szoktam szoftvert venni, ha nincs jobb alternativa. Pl. Beyond Compare. De ebben az esetben nem latom szukseget.

En hasznaltam joideig. De amint az atom.io hasznalhatova valt, attertem.
Amit en hasznaltam a sublime-bol azt az atom is tudja. Okafogyotta valt.

Raadasul atomnak testreszabhato a kinezete, ami az en esetemben azt jelenti,
hogy egy monitoron kifer normalis betumerettel ket fajl egymas mellett ugy,
hogy a sorszamozas is megvan es a 80ch szelesseg is.

Ehhez a sorszamok betuit osszenyomtam css-bol. Kep:
https://imgur.com/a/eim1FQB

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

Aki csak sok-kevés szélsőségekben képes gondolkodni, az nyugodtan vegye meg az újat és dobja ki a régit, mert a kínai rabszolgák lehetővé tették, hogy ezt elérhető áron és tiszta lelkiismerettel megtegye (persze kell egy jókora adag struccpolitika is hozzá, de ez fősodratúéknál default megvan, tehát hagyjuk).

Ettől függetlenül, azért elmondom, hogy amennyiben a Notepad++ ugyanazokat a feladatokat megoldja jóval kevesebb RAM-mal és CPU-val, abban az esetben a Sublime bloatware, egy bloated text editor. Teljesen mindegy, hogy mennyi GB RAM van alatta. Még akkor is, ha az átkozott befektetőlogikád ismét a felszínre tör és totál életszerűtlen kontextusba igyekszik helyezni a RAM bekerülési árát. Elmondom neked, hogy mi az, ami fajlagosan a legolcsóbb: Az, ha nem kell egy bloated alkalmazás miatt új RAM-ot venni. Meg úgy általában semmilyen új perifériát, vagy gépet.

Nem, nem kell elmenni az edlinig. A Notepad++ már kezdetektől fogva ilyen és 2 GB-on is köszöni, jól van. Akkor is, ha szélsőségesen idealista, fősodratú mérnök uraságod ismételten képtelen felfogni, hogy van értelmes középút az ősember barlangja és Dubai luxuslakosztályai között.

A régi gépemben valami kétmagos Pentium CPU van (64 bites), és jött vele 4GiB RAM, meg a még azelőtti alaplap+CPU+RAM elpasszolásából még 4GiB. Az alaplapot selejtezésből kaptam meg - annyi volt a baja, hogy a memóriát nem tudta 800MHz-en hajtani, csak 667-en (sok év használat után döglődtek a kondenzátorok). Nálam így kiszolgált jópár évet. Tavaly váltottam egy "újabb" gépre, ami szintén használt vasként érkezett hozzám, alapból 8GiB ram és valami Core i5-ös proci, négy maggal. Már akkor, amikor ezeket a gépeket _munkára_ megvették, már akkor sem volt divat a 2GiB RAM-mal szerelt munkaállomás - nem, nem a "bloat szoftverek", hanem a feldolgozandó adatok mennyisége miatt. Mindkét alaplapban 2GiB memóriamodulok csücsültek/csücsülnek, és a hardver kialakítása okán illendőren párosával rakja be az ember őket, azaz rögtön 4GiB az alap, ugyanis egy 1GiB modul csak minimálisan olcsóbb, mint egy dupla akkora - miközben (figyelj!) a 2GiB legyártásának környezeti lábnyoma egy fikarcnyival sem nagyobb. Nomostan akkor miért is szívna az értelmes ember 2x1GiB memóriával, még a te khm. erőteljesen környezettudatos elveid figyelembe vételével is?

Fősodratú mérnök uraságod hardverkonfigurációja nem mentesíti a Sublime-ot bloatware mivolta alól.

Amúgy, egyszerű kísérlet: Próbáld ki Sublime Text-ben, hogy belenagyítasz a szövegbe Ctrl + Scroll-lal, amíg csak lehet és figyeled a CPU- és memóriahasználatot. Majd próbáld ki ugyanezt Notepad++ -ban. Aztán magyarázd el nekem, mi a véreres lófasznak kell a készítőnek custom font renderelőt írni, ha szimplán nem ért hozzá és elpazarolja a memóriát, meg a CPU-t. Nem mellesleg még elvárja azt is, hogy fizessenek érte.

Nomostan akkor miért is szívna az értelmes ember 2x1GiB memóriával, még a te khm. erőteljesen környezettudatos elveid figyelembe vételével is?

Nem kéne szívni, ha lennének rá normális szoftverek, API kliensek, böngészők nélkül. Lehet nyugodtan a fősodorból kikiabálni, hogy márpedig nemérimeg™ szoftvert optimalizálni, meg minden hardver kurva olcsó. Egyfelől, a saját szakmádat árulod el, amikor ilyeneket mondasz és így állsz hozzá. Előbb-utóbb eljön majd az idő, amikor a hardvergyártogatás nem lesz olcsó alternatíva, mert elfogynak az erőforrások és Kínában is emelkedik az életszínvonal (pápá olcsó munkaerő).

Definiáld már azt, hogy "elpazarolja a CPU-t", mert nemértem, mi a baj azzal, hogy rosszabb esetben kétszámjegyű százaléknyi processzoridőt felhasznál valami? Ugyanez a memóriával, merthogy még kilapozni sem kell semmit a használata miatt (v.ö.: kényelmesen elfér a memóriában).

A sajár font renderelő oka két dolog lehet: az egyik, hogy cross-platform, és vagy ír sajátot, vagy platformonként, meg akár azon belül verziónként, grafikus környezetenként egyedileg kezeli le, hogy hogyan is történjen a dolog, a másik, hogy fogta a számára elfogadható "közös halmaz"-t (GL?), és azt használja - ahol lehet. Ahol meg erre képtelen a hardver/OS páros, ott belép a saját rendering. Láttunk már ilyet más szoftvereknél is: Ha tudta a kártya/OS adni alá a megfelelő hardveresen gyorsított GL-es funkciókat, akkor szélsebesen ment, ha meg nem, akkor meg köszvényes csiga kiegészítve a CPU jelentős használatával - merthogy számolni azt azért bőven kell hozzá.

"meg minden hardver kurva olcsó" - merthogy az. És egy dupla méretű memóriamodul szinte pontosan (tizedszázaléknyi eltérés talán van) ugyanannyiba kerül a környezetnek, mint a kisebb. Akkor mi a -téged idézve- véreres lófasznak kéne kisebb modulokat gyártani, használni? Erre válaszolj, légyszives. Nem, ne azzal gyere, hogy az ára több - igen, az magasabb, mert a gyártó sem hülye: ha minimálisan különböző költséggel drágábban eladható terméket lehet készíteni, akkor azt fogja nagy tömegben előállítani.

A "pápá olcsó munkaerő" megjegyzésed meg pont, hogy a félvezetőiparban a legkevésbé lényeges - kifejezetten alacsony az élőmunka-igénye a gyártásnak.

A sajár font renderelő oka két dolog lehet

Ez a két ok nem ürügy (és kifogásnak is nagyon szégyenletes) arra, hogy szar-húgy megvalósítással renderelje a szöveget, mind Linux, mind Windows környezetben. Gyakorlatilag a klasszikus mindenre jó, de semmire se igazán csapdája. Annyira sikerült közös nevezőt találni, hogy sokkal szarabb lett a végeredmény, mintha egyáltalán nem is keres. Egyébként, a Sublime fejlesztő, tudomásom szerint a szoftvereladásokból él, tehát bőven lenne ideje kioptimalizálni a rendering engine-t, akármilyen backendre is épül.

Láttunk már ilyet más szoftvereknél is: Ha tudta a kártya/OS adni alá a megfelelő hardveresen gyorsított GL-es funkciókat, akkor szélsebesen ment, ha meg nem, akkor meg köszvényes csiga kiegészítve a CPU jelentős használatáv

Láttunk. Például a Google Chrome semmivel sem kompatíbilis, driver workaroundolgatós hardver"gyorsítása". Nem gondolom, hogy példát kéne venni ezekről.

"meg minden hardver kurva olcsó" - merthogy az

Elég nagy árat fizet ezért a világ, csak te ezt a kényelmes seggeden ülve nem érzed. Az unokáid már fogják.

Akkor mi a -téged idézve- véreres lófasznak kéne kisebb modulokat gyártani, használni? Erre válaszolj, légyszives.

Nem mondtam, hogy most ilyeneket kéne gyártani. Azt mondtam, hogy az eddig legyártottakat nem kéne kidobni. Mi történik vele, ha kiveszed a gépből, mert nem elég a Chrome-nak? Megy szépen a bolhapiacra vagy az elektronikai hulladékgyűjtőbe. Miközben meg még évekig, akár évtizedekig tudna működni, hatékony, optimalizált szoftverekkel. Ugyanez igaz a 32-bites processzorokra is. Újakat csak akkor kéne gyártani, ha a régiek már tönkrementek és már csak nyersanyag szinten újrahasznosíthatók. Addig pedig optimalizálni kéne rájuk a szoftvereket és nem kéne engedni évente telíteni a piacot túltermelt árukkal.

"szar-húgy megvalósítással renderelje a szöveget" - csinálj jobbat, mert eddig csak a szájtépést tetted le az asztalra, semmi mást. Cross-platform megoldás sohasem lesz optimális, n+1 platformra optimálni meg sokszorta többe kerül élőmunkában, tesztelésben, mint egy ismert korlátokkal rendelkező, platformfüggetlen, vagy a támogatott platfromok mindegyikén elérhető lehetőségeket hasnzáló megoldás.
" a Sublime fejlesztő, tudomásom szerint a szoftvereladásokból él, tehát bőven lenne ideje kioptimalizálni a rendering engine-t" - eladásból él, valóban, viszont a fejlesztés az költség, és a költséget, ráfordításokat csak addig szabad növelni, amíg a bevételekben is legalább annyi pluszt hoz. Tudjuk, hogy közgazdasági téren is legalább annyira vagy okos, mint IT-ban, úgyhogy fölösleges lenne belemenni mélyebben, bár ez a költség-haszon dolog közgáz szakközepes szinten is alapismereti dolog.

"Például a Google Chrome semmivel sem kompatíbilis, driver workaroundolgatós hardver"gyorsítása"" pont nem erre gondoltam, hane pl. arra, hogy a GL-t tudó hardverekre prímán lehet építeni, kvázi OS/driverfüggetlenül, viszont ha nem ilyened van, akkor vagy nem tudod hasnzálni az adott szoftvert, vagy jön a szoftveres emuláció, ami nem gyors, ellenben krva lassú lesz. Ugyanez van a Windows-os könyezetben a DirectX témában - ha ócska a kártya, akkor az újabb DX funkciókat maximum szoftveresen fogod tudni a driverrel kamulálni, ami dettó nem gyors, de lassú lesz.

"Elég nagy árat fizet ezért a világ, csak te ezt a kényelmes seggeden ülve nem érzed." Leírtam, de mégeyszer... Egy memóriamodul legyártásának a környezeti hatása gyakorlatilag független attól, hogy 1GiB-nyi vagy 2GiB-nyi memóriacella kerül a félvezetőlapkára, tehát ilyen szempontból hótt mindegy, hogy mekkorát gyártanak le - viszont ha már gyártják, akkor miért kéne a kisebbet csinálni (amiből pont kétszer annyira van szükséga dott memóriamennyiséghez), amikor nagyobbat is lehet. Igen, most jössz azzal, higy nem kell új gépet venni. De kell. Ugyanis a felhasnzálók száma növekszik, ahogy az emberiség létszáma is. Ergo lesznek új, frissen eszközt igénylő emberek, akik elé valamit le kell rakni. Lehetne ócska gépeket lepakolni eléjük, csak azoknak a karbantartását ki fogja csinálni? Ki fogja a javítást megoldani - mondjuk egy bithibás memóriamodult kicserélni (huszonsok év alatt láttam jópár ilyet), miközben az adott típust már senki sem gyártja? Mondd, te a nagyapád gúnyáját hordod? mert az IT-s vonalon ezt várod el. Komolyan kérdezem.

"az eddig legyártottakat nem kéne kidobni" - Egy ideig megtarthatóak, de a fenntartás költsége egyre emelkedik, hiba esetén (ami idővel egyre gyakoribb lesz - a fizika meg a diffúzió már csak ilyen...) cserealkatrészt találni egyre tovább fog tartani - és az idő bizony pénz, eljön az a pillanat, amikor többe kerül a leállás miatt kieső idő és az utánajárás, mint az egész ócskavasat bedarálni, és visszanyerni belőle azt, amit érdemes.

"Addig pedig optimalizálni kéne rájuk a szoftvereket és nem kéne engedni évente telíteni a piacot túltermelt árukkal." - Hajrá, finanszírozz meg egy 32 bites, 2GB RAM-ban elfutkározó optimalizálást mondjuk csak a Linux kernel, egy init, egy shell, egy GUI, egy böngésző halmazra. Nem kell több, csak ennyi. Legyen gyorsabb, gördülékenyebb... Oké, ne finanszírozd meg, csak adj egy becslést, hogy fejlesztói időben ez mennyit tenne ki azzal a könnyítéssel, hogy a funkcionalitás a projekt kezdetén meglévő szinten befagyasztásra kerül, kompatibilitási dolgokkal egyetemben. Nos, hány évnyi fejlesztői munkt saccolsz erre?

csinálj jobbat, mert eddig csak a szájtépést tetted le az asztalra

Nem csinálok jobbat, mert nem az én dolgom egy ebből élő fősodratú teljes életművét újraimplementálni, csak azért, mert képtelen volt bizonyos szempontból kioptimalizálni. Ott a Notepad++, az kapásból jobb.

Cross-platform megoldás sohasem lesz optimális, n+1 platformra optimálni meg sokszorta többe kerül élőmunkában

Egészen addig nem lesz jobb, amíg a szoftveriparban divat lesz az élőmunkán spúrkodás.

eladásból él, valóban, viszont a fejlesztés az költség, és a költséget, ráfordításokat csak addig szabad növelni, amíg a bevételekben is legalább annyi pluszt hoz

Az átkozott befektetőlogikád teszi tönkre az IT-világot, napról napra egyre jobban. Miközben ez a Sublime fejlesztőjének annyiba kerülne, hogy néhány hetet, hónapot rászán arra, hogyan lehetne optimalizálni a betűrenderelést és a megjelenítést. Nem gondolom, hogy éhenhalna. Remélem, te sem. Pláne, hogy már egy full-featured szövegszerkesztő, amihez a hiányzó funkciók hozzáadhatók pluginokkal. Emlékeztetnélek, hogy egy alap fícsörről beszélünk egy szövegszerkesztő esetében, amit alapból nem szabadott volna így gányul benne hagyni. Ha azért hagyta benne, mert értékesebb fícsöröket szeretett volna fejleszteni, hogy gyorsan elterjedjen az alkalmazása, az még érthető. De az, hogy most, hogy már elterjedt, most is képtelen optimalizálni, az nem más, mint a felhasználók szembeköpése. Az átkozott befektetőlogikád pedig nem mentség. Működni pedig csak akkor működne, ha a felhasználók úgy gondolkodnának, mint én és megválogatnák a használt eszközöket, erőforráshasználatuk alapján, ígyhát szoftverfejlesztőék kénytelenek lennének optimalizálni.

pont nem erre gondoltam, hane pl. arra, hogy a GL-t tudó hardverekre prímán lehet építeni

Igen, ugyanezt gondolták Google-ék is, aztán leimplementálták minden idők legszarabb, legótvarabb, leghúgyabb, legerőforráspazarlóbb, semmivel sem kompatíbilis hardvergyorsítását.

ha ócska a kártya, akkor az újabb DX funkciókat maximum szoftveresen fogod tudni a driverrel kamulálni, ami dettó nem gyors, de lassú lesz

Van GDI, ami ócska kártyán is gyors, csak használni kéne. Van 4-5 féle, kifejezetten videórenderelésre kitalált API Windows-on. Használni kéne, majdmegírjukmimertmivagyunkagugli saját trágyadombok gányolása helyett.

Leírtam, de mégeyszer... Egy memóriamodul legyártásának a környezeti hatása gyakorlatilag független attól, hogy 1GiB-nyi vagy 2GiB-nyi memóriacella kerül a félvezetőlapkára, tehát ilyen szempontból hótt mindegy, hogy mekkorát gyártanak le

Leírom még egyszer: Senki nem beszélt arról, hogy 1GB vagy 2GB memóriamodulokat kéne gyártani a ma gyártott 4GB, 8GB, 16GB helyett. Arra hegyeztem ki a mondandóm, hogy a most gyártott modulokat nem a régiek helyett kellene gyártani, azokat kidobatva.

De kell. Ugyanis a felhasnzálók száma növekszik, ahogy az emberiség létszáma is. Ergo lesznek új, frissen eszközt igénylő emberek, akik elé valamit le kell rakni.

Vázolom a szitut: A fejlett világban (EU + USA ~ 1 milliárd ember) birkáék megveszik a legújabb hardverket. Minél többen veszik meg (ami ugye hardvermultiék szent profitcélja), annál több felesleg marad. Ha 1 milliárd ember 50%-a vesz új gépet, akkor marad 500 millió gép, amivel nem igazán lehet mit kezdeni. Persze, el lehet adni használtan, de nem mindenki fog vele szarakodni. Pláne nem, ha már csak tizedét éri, mert több, mint 3 éves. Aztán el lehetne játszani ezt minden évben és rövidesen tele lennénk felesleggel, amivel nem tudunk mit kezdeni. Célszerű lenne ezeket a hardvereket akkor mind begyűjteni és odaadni a fejlődő országoknak. Nem, nem elektronikai hulladékként, hanem működő eszközökként. Egyáltalán nem látom ezt a tendenciát. A fejlődő országok nyomorognak, a fejlett országok által levetett elektronikai eszközök kis százaléka jut csak el hozzájuk. A nagy része szeméttelepeken, zúzdákban, újrafeldolgozó üzemekben végzi. Ami sokkal-sokkal pazarlóbb, mintha tényleg odaadtad volna az emberiség gyarapodóbb részének.

Mondd, te a nagyapád gúnyáját hordod? mert az IT-s vonalon ezt várod el. Komolyan kérdezem.

Ha szeretnél értelmesen beszélgetni, légyszíves fejezd be a provokatív, szélsőséges csúsztatásokat és ezt az indirekt szalmabáb érvelést. Nagyon sajnálom, hogy számodra csak két véglet létezik, a kétütemű trabant és a V8-as sportkocsi, illetve a barlangi lét és a nyugati típusú pazarlás. Az a helyzet, drága mérnök úr, hogy nem hordom a nagyapám gúnyáját. Viszont az IT-ipar ettől még rendkívül pazarló, akkor is, ha ezt te a szemellenződön keresztül nem vagy képes meglátni.

Mondok valamit, ami kicsit közelebb van a V8-as motorhoz, mint a kétütemű trabanthoz, hátha sikerül felfele kerekíteni és megüti az ingerküszöböd. Egy 2011'Q1-ben (tehát 8 éve) kiadott i5-2400-nál egy mostani i5-9600K processzor effektív sebességben csupán 74%-kal képes gyorsabb lenni, ami átlagfelhasználást tekintve szart se jelent, ugyanis egy ma utánad dobott konzumer laptop a Media Marktban bőven lassabb mindkettőnél, mégis alkalmas a 2019-es feladatokra, 2019-es oprendszerrel és szoftverekkel. Ha pedig esetleg az utasításkészletes baromsággal jönnél: minden fő utasítás, amit konzumer szoftver használ, támogatott a régiben is. Igen, a BitLocker által előszeretettel használt AES-NI is támogatott a 2. generációs Intelben. Szóval, visszatérve a témához, ehhez a 74%-hoz 7 generációnyi Intel processzort (!) kellett legyártani! Tehát: nyersanyagot kibányászni, nyersanyagot feldolgozni, ideszállítani a (légvonalban) 9000 km-re lévő Costa Ricából és a (légvonalban) szintén 9000 km-re lévő Malajziából (merthogy ott gyártják az Intel Core processzorokat), elszórni rengeteg pénzt marketingre, csomagolóanyagokra, megvetetni birkáékkal, a régit meg kidobatni (vagy eladatni, de végső soron ígyis-úgyis kidobatni). Már önmagában ritka nagy pazarlás 7 processzorszériát legyártani azért, mert egyik 10-15%-kal többet hoz az előzőnél (innováció nulla). Ami viszont már tenyérbemászó, hogy az Intel már nem készít 2. generációs hardverekhez Windows 10 drivert, a mai felhasználásra való alkalmasságuk ellenére. Még mielőtt azzal jönnél, hogy a Windows 10 majd úgyis felrak mindent és minden jól fog menni a generic driverekkel, kérdezzük meg erről ezeknek a gépeknek a felhasználóit. [1] [2] [3] [4] [5] [6] [7] [8]

Ez után nyilván várható majd a harmadik, negyedik stb. generációknál, hogy adott Windows 10 buildtől már azok se lesznek támogatottak. Tehát, végső soron, az Intel tenyérbemászó, arrogáns, vadkapitalista, undormány viselkedése miatt, szoftveres elavulásnak köszönhetően kell majd kidobni ezeket a gépeket (is). És akkor emellett van az az oldal, ami szerinted közelebb van a kétütemű trabanthoz. Hogy szerintem egy 10-15 éves gépen, ami tud képeket, szöveget, videót megjeleníteni, simán lehetne a mai Interneten elvégzett feladatokat megfelelő szoftverrel végezni, ha ki lenne rendesen optimalizálva és nem weben keresztül működne. Persze, erre is legalább annyi energiát fordít az IT-ipar, mint a 2. generációs Intelek modern oprendszereken való driver-támogatására (értsd: van egy-két valamirevaló alkalmazás, de amúgy szart se).

Nos, hány évnyi fejlesztői munkt saccolsz erre?

1, max. 2 év, mondjuk úgy 20-30 fejlesztővel. Ha tényleg annál maradunk, hogy egy meglévő Linux disztribúcióban optimalizáljuk ki a csomagokat. Melleseleg, sokat nem is kéne, csak néhány grafikus frameworköt, webböngészőt, meg egyéb bloated felhasználói programokat (pl. Double Commander). Command-line cuccok elég jól optimalizáltak.

"ebből élő fősodratú teljes életművét újraimplementálni, csak azért, mert képtelen volt bizonyos szempontból kioptimalizálni" - nomostan a teljes munkája sz@r, vagy csak némi optimalizálásra van szükség? Nagyon nem mindegy.

"a szoftveriparban divat lesz az élőmunkán spúrkodás" - mert az a legdrágább benne, b+!

"Sublime fejlesztőjének annyiba kerülne, hogy néhány hetet, hónapot rászán arra, hogyan lehetne optimalizálni a betűrenderelést és a megjelenítést." - definiáld már az "optimalizálni"-t, hátha kiderül, hogy halovány segédfogalmad sincs arról, amiről beszélsz. Az egységes kódbázisból kellene paltformonként, OS-verziónként külön-külön kezelt, egyedileg megvalósított oda optimalizált megjlenítőmotort csinálni - majd ezt karbantartani. Ha ez szerinted néhány hét, akkor nagyon el vagy tévedve - ráadásul olyan "fejlesztést" vársz el, amit _senki_ sem fizetne meg a termék árában.

"Igen, ugyanezt gondolták Google-ék is, aztán leimplementálták minden idők legszarabb, legótvarabb, leghúgyabb, legerőforráspazarlóbb, semmivel sem kompatíbilis hardvergyorsítását." - te mit csináltál volna? Nem, a platformonként, GL/GDI/X/satöbbi verziónként mindenre külön extra optimalizált kódot írni nem jó válasz, ugyanis rettentő sokba kerül, és érdemi bevételnövekedést nem hoz. Lásd játékszoftverek: azok is csak adott szűk hw/sw-kombinációkon működnek optimálisan. Pedig ott azért van sw-optimalizálás dögivel, van ehhez kapcsolódó tudás is - viszont pont emiatt korlátozott a támogatott hw/sw-környezetek halmaza.

"most gyártott modulokat nem a régiek helyett kellene gyártani, azokat kidobatva" - senki sem dobat ki semmit, az aktuális igények, gazdasági számítások (ide sorolva a környezeti hatás nagyságát is) alapján nagyobb tudású/méretű eszközöket gyártanak. Az, hogy a régi hardvered ezzel nem képes együttműködni, az a te problémád, ahogy az is, hogy a fejlesztések ezekre az új, nagyobb teljesítményű eszközökre vannak tervezve. Használhatod nyugodtan a régi 32 bites motyódat régi szoftverekkel, de ezzel felvállalva azt, hogy egyre több korlátba fogsz ütközni. Ahogy egy EURO-1-es motorral készült autóval is közlekedhetsz, csak mondjuk egy szmogriadó esetén lerakatják veled, vagy épp bizonyos városokba nem engednek be, meg hasonló apróságok. A döntés a tiéd, attól hogy egy huszonéves autóban ülsz, még másnak lehet igénye új, korszerű járműre.

"i5-2400-nál egy mostani i5-9600K" - a sebesség összehasonlítása egy dolog, azért nézd meg jobban, miben különböznek még egymástól.
"ehhez a 74%-hoz 7 generációnyi Intel processzort (!) kellett legyártani" - nem pontos. Ehhez ennyi generációval jött ki az Intel a piacra. Ha nem teszi, akkor az AMD tette volna meg, de a sok éves termékciklusról már leírtam, hogy miért baromség és gazdasági öntökönbökés, nem szeretném megismételni, mert úgy sem fognád fel.

"1, max. 2 év, mondjuk úgy 20-30 fejlesztővel." - azaz 20-60 emberévnyi fejlesztés. Mennyibe is kerül egy fejlesztó egy hónapra? Optimalizálásról van szó, ergo juniorok kilőve, megfelelő tudással, tapasztalattal alsó hangon havi 2M Ft-os költség alatt nem lehet megúszni, évente 24M, ez 20 emberévre közel félmilliárd Ft. Ez az általad becsült minimum erőforrásigény arra, hogy két év múlva legyen egy funkcióiban, tudásában akkor legalább két évvel lemaradt, de meghatározott hardverkörnyezetekre (mert "mindenre" nem fog menni) "optimalizált" Linux. És ezt magyarországi költségekkel számoltam, ennyiből egy nyugatabbra lévő fejlesztőt nem fogsz találni - indiai kódreszelőt talán, de ahhoz meg kell valaki, aki megmondja neki részletesen, hogy mit csináljon.
Kérdés: ki fogja megvenni, és kifizetni a beletolt félmilliárdot? Nos?

Ááá, nem láttál te még valóban bloat szoftvert. A Sublime még kutyafüle kettőbe törve. Próbáld ki a Komodo Edit-et, hatalmas, megabloat, agyonscriptelt monstrum, őrületes erőforrásigénnyel, pedig nem is használ Gtk3-at sem. Már mikor tölt be, akkor le fogod fosni a bokád, előre szólok, szóval pelenkában próbálkozz. Egyből vissza fogod sírni még a LibreOffice-t is, mert még az is villámgyorsan indul a Komodohoz képest. A Sublime MS Notepades pehelysúlynak tűnik utána, garantálom.

No keyboard detected... Press F1 to run the SETUP

Ismerem a Komodo Editet és én is tapasztaltam, amiről beszélsz. Ezért nem is használom.

Egyből vissza fogod sírni még a LibreOffice-t

Nem fogom visszasírni. Ha valami bloatware, nekem mindegy, hogy mekkora bloatware. Nem fogom használni.

A Sublime MS Notepades pehelysúlynak tűnik utána, garantálom

Nem fog annak tűnni, mert nem az. Ugyanaz a bloatware lesz, ami volt. Attól még, hogy mutatsz valaminél egy szarabbat, a jelenleg szar is ugyanaz a szar marad.

Azért nem mindegy. Engem nem szokott érdekelni, ha valami bloatabb, de van egy szintje, ami már fősodratúéknál is kiveri a biztosítékot. Kár a Komodóért, mert amúgy nem rossz editor/IDE, csak így ebben a formában használhatatlan.

No keyboard detected... Press F1 to run the SETUP

Nekem a fizetős szoftverekkel Linuxon az a bajom, hogy nem férnek bele a nyílt forráskódú filozófiába: hiába is fordítják le a zárt kódot, belefordítva minden libet statikusan, lesz majd olyan pont, hogy a rendszer egyes komponensei túl újak lesznek neki, és nem fog futni, vagy csak bugosan. Meg ha véletlenül a fejlesztő abbahagyja a fejlesztését, akkor emiatt egy ponton túl használhatatlan lesz új rendszereken.

Így amire csak lehet, opensource-os alternatívát használok. Egyébként elég profinak tűnik a Sublime, meg elég jó a szintén fizetős UltraEdit is, de nekem a fentiek miatt kiesnek.

No keyboard detected... Press F1 to run the SETUP

De vegyük észre, hogy az opensource-nak pont ez a lényege, hogy dinamikusan tudjon a rendszer fejlődni, ne fogja vissza zárt forráskódú komponensekkel való visszafelé kompatibilitás, amivel kínlódni kell. Nem azért opensource, hogy Mari néninek legyen free beer GNU OS-se. Így a fejlesztőknek nem ősi dolgokkal kell foglalkozni, azokat koloncként cipelniük, hanem tényleg meg tudnak húzni olyan újdonságokat, ami érdemi fejlődést hoz.

Nem gond, ha eltörik a kompatibilitás, mert a nyílt kódot bármikor újra tudod forgatni, meg más fejlesztők karban tudják tartani, forkolni, továbbfejleszteni. A zárt az csak ott van, megy, amíg megy, nem tudni meddig lesz használható, mi lesz a jövője.

No keyboard detected... Press F1 to run the SETUP

De vegyük észre, hogy az opensource-nak pont ez a lényege, hogy dinamikusan tudjon a rendszer fejlődni

Amennyiben a fejlődés jelentései közül kivesszük a kerékújrafeltalálást, úgy észrevettem és egyetértek. Azonban, a Free Software nem ezért jött létre eredetileg, hanem hogy a nagyvállalati arrogancián, a szabadalmakkal jogi erőre emelt önzésen, illetve az emberi tudás szabad áramlásának korlátozásán alapuló szoftverfejlesztést visszaszorítsa. Mondhatni, sikerrel járt, mert a korábban ezt az érát tűzzel-vassal támadó szoftvermultik meglátták benne az ingyenmunkaerő lehetőségét és azóta egyre inkább alkalmazzák is.

Nem gond, ha eltörik a kompatibilitás, mert a nyílt kódot bármikor újra tudod forgatni, meg más fejlesztők karban tudják tartani

Magyarul nem gond, ha X szélsőségesen idealista fejlesztő kitalál valami divatbaromságot, majd eltör minden API-t és emiatt többezer fejlesztőnek csinál pluszmunkát. Lásd GTK3, ami még a "stabil" verziói között is eltörte a saját API-ját.

Mondjuk, hogy ne kelljen több gigányi szemetet, .NET keretrendszert, JVM-et, mindenféle enterprise bloatwaret felpakolni, hogy meg tudj írni néhány egyszerű programot vagy scriptet.

Nagy szövegfájlokat, XML-t, JSON-t is tudj szerkeszteni anélkül, hogy ki kelljen dobni a gépet/memóriát és venni kelljen újat, csak mert ironikus módon szoftverfejlesztőék pont a szoftverfejlesztő alkalmazásokat (IDE-ket) implementálják a legszarabb-leghúgyabb, legótvarabb, legerőforráspazarlóbb módokon.

Gyakorlatilag arra, amire minden más IDE és text editor között félúton elhelyezkedő szövegszerkesztőt. Csak ez a példány rendkívül hatékonyra és sokoldalúra sikeredett.

Azert az latszik az eredmenybol, hogy ez nem egy programozoi szavazas, de meg csak nem is programoloi.

Stiluserzek az mi? (francba, kitoroljem ezt a sort? Nem torlom ki, szeretek zavart okozni)