IDE kerestetik

Fejlesztés

Friss DevOps pozicioban egyre tobb es tobb a kod amit irok, igy szuksegesse, indokolta valt egy jo IDE beszerzese. A nano kezd kicsit buta lenni ahhoz hogy tudja kovetni amit muvelek.

Amit elvarnek
-Ne java alapu legyen ( nem all szandekomban java-t telepiteni a gepemre ebbol csak akkor engedek ha minden mast mar kiprobaltam )
-Git / SVN tamogatas
-Syntax highlighting-en kivul barmi okositas plus ( automatikus kiegeszites, stb )

Leginkabb Cloudformation(json), Puppet, Docker, Bash, PHP, JavaScript, Django( python ), SQL projektekkel foglalkozom.
Idealis esetben distro package, de ugy sejtem ha lenne a repoban ilyen mar megtalaltam volna, de barmi mas johet ( linux )

  • 6604 megtekintés

( deje | 2014. 08. 11., h – 16:44 )

Mivel a legjobb multi-purpose IDE-k Java alapúak, így lehet, hogy ezt a kritériumot ki kell húznod.
Amúgy mi bajod azzal, hogy fel kell raknod egy JVM-et? Nem fér el a python meg a PHP mellett?

( uid_7086 | 2014. 08. 11., h – 16:53 )

Tartok tőle, hogy a javat nem fogod megúszni.
Mivel az általános használatra szánt gépemre én sem akartam javat, felraktam virtualboxba egy linuxot, ott a kutyát sem zavarja és abban futtatom az eclipse-t. Sok dologra jó, PHP-re nem annyira.
Esetleg, ha nincsenek túl nagy igényeid, a kdevelop is jó lehet, ez tudtommal C++ alapú, nem kell neki java.
(Help! A kdevelop a bővebb vagy a szűkebb változat??)

nano? Lehet, hogy a gvim is sokat lendítene a jelenlegi helyzeten? ;)

Java miatt virtuális gép + eclipse? Egy kissé overkill ez az adott problémára.
Amit nem értek még mindig, hogy mi ez a hatalmas félelem a java-tól. Nagy? Bugos? Vagy mi van?

Ha meg nem akarod "feltelepíteni" a java-t, akármi okból, még mindig megadatik a lehetőség, hogy a JRE-t (Java Runtime Environment) az adott program alá rakod fel csak. Leszeded a targz vagy zip verziót mindkettőből, kicsomagolod azonos könyvtárba mindkettőt, aztán az eclipse.ini-ben beállítod, hol találja a jvm-et. Az IDEA-s csávók vicces módon már eleve így szállítják az eszközeiket (IDEA, PHPStorm, stb), nem kell "telepíteni".

Túl sok a java-ban a biztonsági lyuk. Linuxon, vm-ben, ahonnan nen nagyon járok a netre, kevésbé zavar, mint windows-on, ahol fogalmam sincs, hány helyre eszi be a fene. Egyébként linuxon játszom "fejlesztőt", ezért a linuxos guest kellett, de eredetileg Windows-on futtattam az eclipse-et. Aztán előjött valami hiba, ami ellen csak a java eltávolítása védett a hírek szerint, akkor átköltöztem linuxra, egy virtualbox guestbe.

Kissé szemellenzős ez a hozzáállás. Mellesleg a JVM-ben nincs több security probléma, mint bármilyen más hasonló szoftverben. A probléma a böngésző beépüléssel van, illetve azzal, hogy a homogenitás miatt (értsd: bármilyen böngésző alatt bármilyen OS-en) ugyanazok a sechole-ok vannak.
ami ellen csak a java eltávolítása védett a hírek szerint
Ja, én is olvastam ilyen cikkeket, bulvársajtóban. Szaksajtóban általában pontosabban le tudják írni, hogy mi az ok. Ismétlem: a böngésző plugin kikapcsolása megoldja az összes ilyen jellegű problémát, vagy a java mindig frissen tartása, vagy (és most jön a meglepetés) pedig ha NEM az Oracle-es Java-t használod, hanem a minden linuxban elérhető open-jdk-t. A böngésző plugint (icedtea) nem kötelező felrakni sem.
Másik megoldás, hogy a korábban írt módon az adott alkalmazás alá csomagolod a JRE-t. Ekkor sem a böngésződ, sem a többi alkalmazás nem fog értesülni arról, hogy van JRE a gépeden.

Tévedés ne essék, nem vagyok Java evangelikus. Csak a sötétséget szeretném eloszlatni némi igen súlyos tévhittel kapcsolatban.

Épp ott volt a probléma, hogy önmagában a plugin tiltása nem oldotta meg a gondot.
Ha van kedved keresd meg, szvsz a hup.hu c. bulvárlap is megemlítette.
Java-t másra nem használtam, akkor meg minek?
Az meg, hogy minden platformon ugyanazok a hibák vannak... elvette a kedvem attól, hogy a továbbiakban komolyan vegyem amit írsz.
Ja, az meg külön izgalmas, hogy arról beszélünk, miért szedtem le a Windows-ról a javat, te meg ajánlod a linuxos verziókat. :)))

Lineknél egy párat?
Mert ha a böngésző plugin nincs feltelepítve akkor ott nincs is biztonsági probléma. Márpedig azt nem kötelező feltelepíteni.

Attól, hogy egy könyvtárban ott a jre az még nem biztonsági probléma. Ez pont ugyan olyan, mint ahogy fent lehet a php is egy könyvtárban az attól még nem biztonsági probléma.

Igen, 10 éve fejlesztek java-ban, bizonyára teljesen tudatlan vagyok hozzá. A biztonsági problémák 100% az volt, hogy java applet-en keresztül sikerült kinyúlni
a felhasználó rendszerébe, kitörni a sandbox-ból. Ezeket a problémákat egyrészt fixálták, másrészt a kevés banki oldaltól eltekintve nyugodtan le lehet kapcsolni
a java plugin-t, és akkor nincs ilyen probléma. Rövidesen úgyis repül a mindenféle plugin támogatás a böngészőkből, szóval ez a probléma hamarosan meg fog oldódni.

Ha alkalmazásként indítod, akkor csontra ugyanolyan alkalmazás, mint bármilyen másik, pont ugyanolyan jogosultságokkal, és pont ugyanolyan "törhetőséggel". Nem értem
a nagy java ellenességet, semmivel nem teszi sebezhetőbbé a gépet, mint bármely más program. Nem fut emelt jogosultságokkal, és valójában buffer overflow-t sem lehet
neki csinálni, jvm-et crash-eltetni, és abból valami hasznot húzni nem nagyon láttam eddig példát.

Az, hogy fejlesztesz benne semmit nem jelent. (sajnos)
Lusta vagyok több energiát fektetni a keresésbe, sajnos nem mentettem el egyetlen linket sem a szóban forgó, "hiába tiltod a plugint, akkor is sérülékeny marad a böngésződ" bugról szóló cikkekhez. De nem ok nélkül kaptam le azonnal a javat.
És még mindig ott tartok: ha nem használom semmi másra, fejlesztgetni meg amúgy is linuxon, virtualboxban, akkor minek nekem a java windows-ra?

Majd ha végre rászánom magam és csináltatok új szemüveget és azzal még esetleg hosszabb szövegeket is el tudok olvasni, akkor meg fogom keresni azt a pár, engem rendkívüli módon kiakasztó java hibát, amik fokozatosan vették el a kedvem attól, hogy kliens oldalon használni akarjam.

Most végigtúrtam a netet, de ilyet nem találtam. Ha letiltod a plugint, akkor a böngésző amikor megtalálja az applet tag-et, el sem indít semmit, ha pedig
be van kapcsolva, akkor is először mutat egy komponens helyet, amire ha kézzel rákattintasz, csak akkor fog a plugin elindulni.

Win7 - hogy tudom lekérdezni, mikor, mit telepítettem, illetve távolítottam el? (úgy értem: az event logot leszámítva, azt viszonylag rendszeresen takarítom)
Ha ez megvan, akkor közelítőleg meg tudom mondani, mikori bugok közt kell keresni, mert akkortájt szedtem le a java-t :)

Erről a szerver oldai RCE-ről viszont kérek linket, mert eddig amit én láttam ott a sec hole-ok nem magában a java-ban vannak/voltak hanem a java altal futtatott alkalmazásokban. ( Az alkalmazás lehet egy nem megfelőlen beállított tomcat/glassfish/jboss vagy egy deploy-ált war is sőt, akár egy swing-es desktop app.)

BTW ha egy user-ként futatott jre-ből sikerül root / NT Authority System jogot szerezni, akkor ahhoz már semmi köze a java- nak.

A lent emlegetett doksiban van ra par scenario, de ezeken kivul is akad olyan, hogy egy java-s app elfogad java kodot, es megbizik a securitymanager-ben, hogy nem fog semmi rosszat csinalni (pl. apache derby) - ez pedig pont ugy tamadhato, mint a kliensoldali parja.

"BTW ha egy user-ként futatott jre-ből sikerül root / NT Authority System jogot szerezni"

Az nem RCE, hanem privilege escalation.

"akkor ahhoz már semmi köze a java- nak"

.. kiveve, ha egy local system-kent futo java appon keresztul sikerult (volt mar ilyen, localhoston ott figyelt a jmx remote).

--
"You're NOT paranoid, we really are out to get you!"

Azt hiszem, ez kavart be: Egyébként linuxon játszom "fejlesztőt"
De ha nem akarsz Java-t használni, tőlem ne tedd, mondom, hogy nem meggyőzni akarlak. Mindössze a topicindító számára szerettem volna világossá tenni, hogy a te itteni hozzászólásod nélkülöz némi racionalitást. A személyeskedést nem szeretem, és igyekszem elkerülni.
Részemről itt a vége.

Na, akkor mégegyszer: nem a kisujjamból szoptam sem azt, hogy a javaban kliens oldalon kicsit több a sec.hole, mint az indokolt lenne, sem azt, hogy a telepített, de letiltott java plugin is biztonsági kockázatot jelentett egy adott verziónál.

És bocs, de ha valaki komolyan elhiszi, hogy attól, hogy java, a sec.hole-ok platformfüggetlenné válnak, annak a véleményén max. mosolyogni tudok.

ui: ha valaki tudja, pontosan melyik volt az a hiba, amire azt írták, hogy kizárólag az eltávolítás segít... google-n egyelőre nem találom. :(

"A probléma (...) illetve azzal, hogy a homogenitás miatt (értsd: bármilyen böngésző alatt bármilyen OS-en) ugyanazok a sechole-ok vannak."

Nem, a problema az (volt), hogy:
a.) tenyleg egy rakas hibat talaltak benne (a security-explorations-os sracok, akiknek a kutatasa utan raugrott mindenki, kapasbol vagy 50-et)
b.) jelentos reszuk eleg low-hanging volt, ami egy eros pozitiv indikator a tovabbi hibak elofordulasi valoszinusegere
c.) egy csomo kikerult 0daykent
d.) ezek a hibak rendkivul jol hasznalhatoak a tamado szempontjabol, mivel semmilyen mitigacios technika nincs (nem volt) rajuk. Pl. mire egy IE double-freebol rendes exploitot faragsz (megkerulve a DEP-et, ASLR-t, heap hardeninget, integrity level-eket, etc), az brutal munka. Egy ilyen java sandbox escape exploit sokkal-sokkal egyszerubb, es 100%-ig megbizhato.

Ettol fuggetlenul persze igaz, hogy ha nem erheto el halozatrol (mint browser plugin vagy mint halozati service), akkor sok biztonsagi problemat nem fog okozni.

--
"You're NOT paranoid, we really are out to get you!"

Letoltod a tomoritett jdk-t es kicsomagolod. Nem epul be sehova es nem talalja meg semmi (csak az IDE, ha annak memgondod hol van).
Windowson letoltod a jdk installert es telepites kozben kiveszed a pipat a JRE telepites mellol. Nem epul be a plugin a bongeszobe, mert fel sem telepul (mint ahogy a pulbikus jre sem). IDE-nek meg igy is eleg.

Mindegy... rághatjuk a gumicsontot, de attól kezdve, hogy a letiltott plugin is képes lehet(ett) gondot okozni, inkább nem akarok windows-ra javat. Ennyi.
Ha szükségem lenne rá, akkor biztosan kitalálnám, hogy hogy rakjam fel, hogy legalább viszonylag nyugodt legyek felőle, de így, hogy nem is kell, minek erőlködjek?

( laja | 2014. 08. 11., h – 22:22 )

Hali!

Szerintem ha a version control kitételt elengeded, akkor már elég sok editor/IDE közül válogathatsz (geany elég lightweight); az én szerkesztőmben bár be van kapcsolva a mercurial plugin - inkább command line-ból kommitolok, pullolok, merge-elek. De hacsak nem egy pycharm vagy egy eclipse (pydev) mellett döntesz, pythonhoz nem kapsz sokkal több segítséget máshol sem. Mondjuk a spyder nevű szerkesztő egész használható volt, a ninja-ide meg valami modern izé, de pár éve nem láttam már ezeket, most nem tudom hogy állnak. Igazából addig ment a keresgélés, amíg meg nem álltam az eclipse-nél meg a pycharm-nál, most már végre koncentrálhatok a kódolásra is. :)

( lx | 2014. 08. 11., h – 23:00 )

Akinek hajdan tetszett a Borland Turbo C/Pascal editora, vagy a Dos Navigatoré, az hamar megkedveli az FTE-t.

Ubuntura van csomagja, ami frissebb (?, legalábbis nagyobb verziójú, mint a sourceforge-os források).

Itt a syn hl az, ami nyelvekben korlátos, de (a menüje szerint) cvs-t, svn-t tud.

Ahogy elnézem, ez nem üti a vim-et (:syntax on). Még egy hasznos tulajdonsága: vim xy.c +110 --> 110. sorra álva nyitja a text editort.
Egyéb hasonlóan egyszerű, de szintaktika kiemelést ismerő: mc belső text editora (Beállítások->Alapbeállítások->Belső szövegszerkesztő)

Persze, de annak ellenére, hogy jómagam éppen a vim miatt hagytam ott minden egyebet, jellemzőem nem ajánlgatom, mert aki még nem hallott róla, annak frusztrálóak az első napok (eppen a "Tanuljunk meg gwbasicben multiplatformos HD FPS játékokat írni monociklis, tízbuzogányos zsonglőrattrakció közben 24 óra alatt"-korban); aki meg hallott róla, és mégis keres, azt minek idegeljem.

És igen, az mc és mcedit együtt a makrókkal és agyonokosítható menükkel jó IDE-közeli érzést teremthet.

( winben | 2014. 08. 12., k – 08:34 )

Ha java aztán mégis játszana esetleg: én NetBeans-t használok.
De általában (mindenki más) Eclipse-et, de szerintem az szar (egyéni szubjektív vélemény).

-------------
Command line Russian roulette:
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*

Winben blogja

Reklámmentes képfelt

( fdavid | 2014. 08. 12., k – 08:48 )

Ezekre nezz ra:
Code::blocks
QtCreator

Cserebe jol hasznalhatoak, nem javasak, nem allnak a fejleszto utjaba eroltetett koncepciokkal, es alatalaban barmilyen nyelvben valo programozasahoz az alapfunkciok megvannak. Nyilvan letezik nyelvspecifikusan par dolog, ami konnyebbe teheti a eletet, de azert ahogy en kiveszem, itt azert inkabb csak par ezer sorrol van szo.

( adamsaghy | 2014. 08. 12., k – 09:38 )

Egyszer volt, hogy hirtelen kellett egy jó editor Linux alá, hogy piszkáljak PHP-t, MySQL-t és JavaScript-et. A Geany meglepően jól muzsikált a kezeim alatt, relatíve rövid idő alatt.

( uid_194 | 2014. 08. 12., k – 09:57 )

Emacs.

Nem Java alapu, Git / SVN tamogatas van, syntax highlight kb mindenhez van, automatikus kiegeszites is rengeteg nyelvhez, minden ertelmes distroban benne van.

--
|8]

( kisauto | 2014. 08. 12., k – 22:11 )

kenyelmes...

https://icecoder.net

de az is igaz, hogy -szerintem- nem ezt keresed, ellenben biztositja, hogy ott es akkor kodolj amikor akarsz.
en ugy csinaltam, hogy a serveren levo home -om van beallitva. ha egy halozatban vagyok, akkor szinkronizal, de ennek semmi koze ugye az ice coderhez :)
svn / git coming soon /remelhetoleg