Ubuntu 16.10 lokalizáció?

Tegnap upgradeltem, és gond volt a hálózattal. Így aztán keresni kezdtem az okokat. Többek között: 


ironcat@ipd:~$ ping -i .5 192.168.1.1
ping: bad timing interval

Mi van? Nincs azzal semmi baj. Vagy mégis? 


ironcat@ipd:~$ ping -i ,5 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
…

Tanulság? Nincs. Ezzel még sokat fogok szívni, mire megszokom.

( wachag | 2016. 10. 19., sze – 15:49 )

Ó, ez csudajó móka. Pl. a Xilinx SoPC tervezője (lényegében custom processzoros rendszert rakhatsz össze) ilyenek miatt úgy el tud szállni, mint a győzelmi zászló. Javítás? Sose lesz.

( rpsoft v | 2016. 10. 19., sze – 16:15 )

Ez milyen locale beállítás mellett jött elő? [Milyen locale-ben beszél angolul, de vár tizedesvesszőt (nem tizedespontot)?]

( anr | 2016. 10. 19., sze – 16:42 )

ezert kell minden lokalizalast en-us-ra allitani
az legalabb megszokhato

--
Live free, or I f'ing kill you.

( egmont | 2016. 10. 19., sze – 22:09 )

Bug. Reportold. Hivatkozz pl. a sleep parancsra (coreutils). A parancs kimenete lehet locale-függő, a neminteraktív bemenet, parancssor stb. nem.

Kevés shell scriptet írtam, de egyiket se készítettem fel arra, hogy locale függő paramétereket adjak neki. De még a kimenet parse-olást se tudom hogy lehet értelmesen megcsinálni ha nem tudom milyen szövegrészletekre számítsak.

De jó lenne ha az stdout/stderr mellett lenne egy extra adatcsatorna ahova értelmesen strukturálva, kiszámítható, és szoftver által feldolgozandó formátumban dobná ki az alkalmazás az adatokat.

Én nem utálom, igazából nem is használtam soha. Annyit tudok róla, hogy alkalmazások tudnak egymással kommunikálni vele, de csak azok, amik támogatják. Ez már egy probléma. Kicsit belelapoztam a leírásába, úgy látom ez inkább desktop alkalmazások és szolgáltatások közti kommunikációra való, nem kifejezetten arra, ahogy én elképzelnék egy ilyen adatcsatornát.

Amit én elképzelek az tényleg csak az stdout speciális változata lenne, amiben az adatstruktúra fix. Ugyanúgy lehetne egymásba pipe-olni, az eredményt felhasználni script változóban (akár okosan, mondjuk

A=`stat valami.txt`
echo A[mtime]

Oké, hogy a stat pont ad lehetőséget arra, hogy okosan lekérdezzek egyes értékeket, ez jutott most eszembe :)

> De jó lenne ha az stdout/stderr mellett lenne egy extra adatcsatorna ahova értelmesen strukturálva, kiszámítható, és szoftver által feldolgozandó formátumban dobná ki az alkalmazás az adatokat.

Külön csatorna nincs rá (nem is tudom hogy jó lenne-e), parancssori kapcsolók (vagy végszükség esetén LC_bigyó változók) vannak amelyek az output formátumot megváltoztathatják.

Igen, de arra nem lehet építeni, hogy minden alkalmazás megoldja valahogy, mert abból az van, ami most van, hogy továbbra is kell tudni minden alkalmazásról hogy egyáltalán támogat-e valami hasonlót, ha igen, akkor milyen formában, milyen adatok nyerhetők ki vele, szivat-e az alkalmazás a ponttal, vesszővel, stb.

Ha lenne egy elvárás a formátumot illetően, és lenne egy standard toolset a kimenet feldolgozására, teszemazt hogy objektumként vagy listaként lehessen kezelni azt a kimenetet szerintem hasznos lenne. A lényeg, hogy a feldolgozást ne minden egyes scriptben kézzel kelljen implementálni adott alkalmazáshoz igazítva.

"De jó lenne ha az stdout/stderr mellett lenne egy extra adatcsatorna ahova értelmesen strukturálva, kiszámítható, és szoftver által feldolgozandó formátumban dobná ki az alkalmazás az adatokat."

Windows-on a PowerShell. Idővel tán Linuxon is.

Üdv,
Marci
A Microsoftnál dolgozom.

"De jó lenne ha az stdout/stderr mellett lenne egy extra adatcsatorna ahova értelmesen strukturálva, kiszámítható, és szoftver által feldolgozandó formátumban dobná ki az alkalmazás az adatokat."

Többek között valami ilyesmiért született meg a PowerShell is. De azt mint tudjuk fúj, csak mert MS.

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

"A parancs kimenete lehet locale-függő, a neminteraktív bemenet, parancssor stb. nem."

Ezzel az utolsó félmondattal kissé megleptél. Ez számomra azt jelenti, hogy ha a szoftver úgy van megírva, hogy pl. STDIN-t is feldolgoz, akkor a feldolgozást külön meg kell csinálni az isatty(0) igaz és hamis esetére is? Like (nem). Én pl. sokszor csinálok olyat, amiben gyorsan lekezelem a van-nincs-paraméter helyzetet, aztán a többit meg egységesen oldom meg: 


case $# in
0) ;;
1 ) 
exec 0 < "$1"
;;
esac
do-my-job # from STDIN

fentiek szerint ez nem jó, mert ha paraméterként adom meg a feldolgozandó fájlt, abban locale-független módon (gondolom LANG=C formában) kellene legyen egy szám - merugye neminteraktív, míg ha billentyűzetről jön, akkor ott meg aktuális LANG szerint???? Vagy valamit nagyon félreértek.

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

Jó, nyilván nem olyan cuccokra gondolok, mint pl. a "grep", ahol nem lehet külön értelmezni a két koncepciót. De olyanoknál, mint pl. valaki a "stat"-ot hozta fel, meg sok egyéb, ahol "szépen" van megformázva az output, kifejezetten az emberi olvasást megkönnyítendő, ott elég vacak megközelítés megpróbálni ezt a formátumot tovább feldolgozni. A proginak kell ilyenkor valahogyan megmondani, hogy humánbarát helyett feldolgozásbarát output formátumot produkáljon.

Szerintem nem ördögtől való gondolat, hogy az legyen idővel.
Szabad szoftver így, legfeljebb hittani akadálya lehet a dolognak.

Kíváncsi vagyok hogyan is szerzed meg Linuxon a default gateway IP-címét legegyszerűbben?
PowerShellben Windowson ennyi: 

(Get-NetIPConfiguration | Foreach IPv4DefaultGateway).NextHop

Üdv,
Marci

Nem tudom, hogy megy-e Windows 7-en. De nem kéne a "széltét" a "hosszával" hasonlítani: ha egyidős de különféle Linux disztribúciókat hasonlítunk össze különböző korú Windowsokkal, az nem teljesen korrekt. Még akkor sem korrekt, ha valójában a mindennapi gyakorlat során pont ez a változatosság, ami az egyszeri rendszergazda elé kerül. Ugyanis szerintem nem fair elvárni a Microsofttól, hogy miért nincs benne a hét évvel ezelőtt kiadott termékében a mai korszerű funkcionalitás, közben ugyanezt a Linuxoktól meg nem várja el senki...

És valóban azon sem kötözködnék, hogy melyik disztróban van vagy nincs az adott segédprogram. Ha nincs, tessék feltenni. Különben mindjárt ott tartunk, hogy írjunk olyan scripteket, ami a világ összes shelljében jól fut, bármiféle OS alatt.

Üdv,
Marci

Akkor én peches vagyok: sem ilyen networkctl nincs nekem, sem a Win7-es PowerShell-em nem tud ilyet: 


PS C:\Users\Nevem> Get-NetIPConfiguration
The term 'Get-NetIPConfiguration' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spell
a path was included, verify that the path is correct and try again.

OK, de hogy lesz belőle csak egy IP-cím, mint PowerShellben? 

> (Get-NetIPConfiguration | Foreach IPv4DefaultGateway).NextHop
192.168.0.1

szerk.: gondolom a 

networkctl status | grep Gateway | awk '{ printf $2; }'

a legcsinosabb, ugye? Mert a 

cut

-tal meg a 

tr

-el bíbelődni nem olyan elegáns. 

sed

-del sem oly olvasható. De érdekel, van szebb?

Üdv,
Marci

OK, LEVEL 1 COMPLETED. :)
Abban ugye egyetértünk, hogy sokkal korszerűbb, hiba- és változástűrőbb dolog egy parancs kimenetét strukturált adat formájában átadni a következő feldolgozónak és szükség esetén a legvégén szöveggé alakítani (PowerShell), semmint a parancs eredményét mindig szöveggé lapítani majd a következő állomáson újra keresztben-hosszában felaprítani (*nix shellek)?

Üdv,
Marci

Egyetértünk. De erre a Powershell sose lesz megoldás. Ne érts félre, nem kifejezetten ezzel a szoftverrel van problémám. Egy másik shell ha hasonló funkcióval rendelkezne az sem lenne sikeres a probléma megoldásában. Egy shell nem fogja megoldani ezt, ha mégis megpróbálja jön majd a másik, aki máshogy oldja meg, jön a harmadik... stb.

Windows alatt is csak azért működik frankón, mert a PS lényegében "A" shell.

A megoldást abban látnám, ha az stdlib része lenne ennek a kezelése. Az alkalmazások erre tudnának építeni, a fejlesztők számítani a funkcionalitás meglétére és egységességére, és adatot cserélni a shellel, vagy egymással.

"A megoldást abban látnám, ha az stdlib része lenne ennek a kezelése."

Egyetértünk. Nem teljesen elképzelhetetlen, hogy ez az objektum-csővezeték beépítésre kerüljön.
Ahhoz sajnos nem vagyok eléggé művelt ideológiailag, hogy megállapítsam: milyen viszonyban áll ez a DBUS-szal.

Üdv,
Marci

Tudod mi a problema a PowerShellel? Hogy kell neki:
- .NET Framework
- Valami hardver absztrakcios layer, amihez API szinten fordulhat, WinRM/WMI/Systemd vagy barmi egyeb
- Egy kazal memoria
- Es egy eleg komoly CPU

Na, emiatt a PowerShell sosem lesz default shell Linuxon, itt ugyanis eleg fontos szempont a default shell kivalasztasanal, hogy
- minel kevesebb libtol fuggjon (Ncurses, Readline, aztan nagyjabol ez a sor vege)
- borzalmasan szar allapotu rendszerben is uzemkepes legyen (egy bash-nek semmire nincs szuksege, akkor is elindul, ha csak kernel van es semmi mas)
- jol hasznalhato legyen beagyazott kornyezetek eseteben is
- es nagyon kicsi legyen a footprintje, hogy egy szetterhelt szerveren is tudj shellt inditani

Nem veletlen, hogy a Microsoft sem lepte meg mind a mai napig, hogy a PS legyen a default shell, ha valaminek muszaj folyamatosan futnia (lsd meg: Server Core), az a CMD shell (bar a legujabb, 2013(?) szervert nem lattam meg, ketlem, hogy maskepp lenne), espedig azert, mert ez van a legkozelebb a Linuxos shellekhez mind fuggosegben, mind fogyasztasban. Minden ennel magasabb absztrakcio osszehasonlithatatlanul tobb szamitasi kapacitast es memoriat visz el.

Arrol nem is beszelve, hogy egy PowerShell olyan esetekben hasznalhato tool, ahol van az esetet lefedo pluginje telepitve (hiszen ez az egesz objektum-pipe csak cmdletek es scriptek kozott mukodik, vagyis a shellen belul, egy notepad.exe sosem fog elfogadni egy System.IO.File objektumot parameterkent, mert ahhoz mar at kellene nyulni a ket program memoriateruletei kozott). Ha valamiert nincs ilyen plugin, vagy epp nincs telepitve, PS-ben is pont ugyanugy fogsz kimeneteket parzolgatni, mint barmelyik masik shellben, csak raadasul a PS-ben az ehhez valo egesz tooling sokkal gyengebb.
--
Blog | @hron84
Üzemeltető macik

"- .NET Framework"

Oszt' akkor mi van?

"- Valami hardver absztrakcios layer, amihez API szinten fordulhat, WinRM/WMI/Systemd vagy barmi egyeb"

Mert Linuxon aztán minden program közvetlen basztatja a hardvert, mint régen DOS-on, mi?

"- Egy kazal memoria"

Ne vicceljünk már. Mekkora az a kazal? Mit számít az közepes kategóriájú mobiltelefon felett?

"- Es egy eleg komoly CPU"

Mert aztán szöveget oda-vissza parseolgatni és alakítgatni, valamint hatszázcsillió billió cat, sed, awk hívást közbeiktatni aztán roppant memória és CPU kímélő.

"- minel kevesebb libtol fuggjon (Ncurses, Readline, aztan nagyjabol ez a sor vege)"

Ennek a listának azért utánanéznék mégegyszer. Debianban egy bash+coreutils is 14 csomagra depel. Aztán jön az első program, aminek a gettext is kell és máris bőven 20 felett vagyunk.

"hiszen ez az egesz objektum-pipe csak cmdletek es scriptek kozott mukodik, vagyis a shellen belul, egy notepad.exe sosem fog elfogadni egy System.IO.File objektumot parameterkent, mert ahhoz mar at kellene nyulni a ket program memoriateruletei kozott"

Mert elég nagy baromság is lenne egy System.IO.File objektumot átadni egyik programból a másiknak, főleg, hogy ott a System.IO.FileInfo. (Bár annak is esetleg egy másolatát adhatná oda, semmint osztott objektum. Elvégre security megfontolások is léteznek a világon.)

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

"Mert Linuxon aztán minden program közvetlen basztatja a hardvert, mint régen DOS-on, mi?"

Nem, Linuxon nyersben dolgozunk az eszközfájlokkal, aztán majd lesz valami. Lásd még random kezelés, v4l, stb. Micsoda absztrakció!

"Ne vicceljünk már. Mekkora az a kazal? Mit számít az közepes kategóriájú mobiltelefon felett?"

Az megvan, hogy például a bash nem csak mobiltelefonokban van, hanem beágyazott rendszerekben is, ahol nem ritka az egy gigabájt alatti memória?

"Mert aztán szöveget oda-vissza parseolgatni és alakítgatni, valamint hatszázcsillió billió cat, sed, awk hívást közbeiktatni aztán roppant memória és CPU kímélő."

Mintha a PowerShell nem szövegeket parsolgatna, hanem kis unikornisok dolgoznák fel benne a szöveget. Ugyan már, tudsz te ennél jobbat is.

"Debianban egy bash+coreutils is 14 csomagra depel. Aztán jön az első program, aminek a gettext is kell és máris bőven 20 felett vagyunk." 


[ggarami@sunshine Downloads ] $ ldd /bin/bash                                                                                                     (rvm:ruby-2.3.1@fetchmonkey)
	linux-vdso.so.1 =>  (0x00007ffdce547000)
	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fb9fc570000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb9fc36c000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb9fbfa2000)
	/lib64/ld-linux-x86-64.so.2 (0x000055cd1d5ab000)
[ggarami@sunshine Downloads ] $ ldd /bin/cp                                                                                                       (rvm:ruby-2.3.1@fetchmonkey)
	linux-vdso.so.1 =>  (0x00007ffd1211c000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f9d6c7ab000)
	libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f9d6c5a3000)
	libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f9d6c39d000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9d6bfd4000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f9d6bd64000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9d6bb5f000)
	/lib64/ld-linux-x86-64.so.2 (0x000056347a6f1000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9d6b942000)

A cp esetében a libacl, libattr és libselinux függőségek teljes mértékben opcionálisak, elhagyhatóak. Hogy ezt hány csomagba vágták szét Debianék, az engem egy ponton túl nagyon kevéssé izgat, és ez a beszélgetés túl van azon a ponton. Ha megnézed, a Glibc, Ncurses, PCRE hármason kívül ezek nem függnek komolyabban semmire. Az, hogy az apt-cache showpkg mit mond, az nem érv.
--
Blog | @hron84
Üzemeltető macik

"eszközfájlokkal"

Na és az mi az isten, ha nem egy absztrakció?

"aztán majd lesz valami"

Ja, jobb esetben a cellux kitart. Rosszabb esetben nem. Bravo.

"hanem beágyazott rendszerekben is"

Előbb még halódó szervereket emlegettél...

"Mintha a PowerShell nem szövegeket parsolgatna" 

PS C:\> (Get-ChildItem | Select-Object -First 1).GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     DirectoryInfo                            System.IO.FileSystemInfo

PS C:\> (Get-ChildItem | Foreach LastWriteTime | Select-Object -First 1).GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     DateTime                                 System.ValueType

"A cp esetében a libacl, libattr és libselinux függőségek teljes mértékben opcionálisak, "

Aztán valamiért mégiscsak ott van. De te még előbb kettő függőséget említesz. Itt már többet látok.

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

Vicces pont a datetime-t elohozni. Fogadok, hogy a diszken nem egy DateTime objektum van, hanem valami 4-8 bajtos datumabrazolas, amit valahogy magikus modon DateTime objektumma kell alakitani. Ja, varjal, nem is, az a magikus mod az a parsolas.

Raadasul a FileSystemInfo eleve tobb, szinten nem objektum-formatumu adat objektumma alakitasarol szol, ami szinten parsolas. Az egesz informatika masrol sem szol, mint bajtsorozatok parsolasarol, ezt neked, mint fejlesztonek igazan tudnod kellene.

Raadasul a rendszerek egymas kozott nem egyszer XML-t, JSON-t, SOAP uzeneteket, HTTP kereseket, stb-ket valtanak, ami baromira nem mas, mint szovegparsolas a legmagasabb szinten, fuggetlenul attol, hogya vegen HTTWebPRequest meg HTTPResponseMessage objektumok lesznek belole.

"Aztán valamiért mégiscsak ott van. De te még előbb kettő függőséget említesz. Itt már többet látok."

Az a problema, hogy nem tudom eldonteni, hogy te tenyleg ennyire sotet vagy ebben a temaban, es segitenem kellene oszlatni a soteteseget, vagy ekkora tulok troll vagy, es inkabb beken hagynom. Fejlesztokent sosem talalkoztal meg az opcionalis fuggoseg fogalmaval? Egyaltalan, maga az opcionalis szo mond neked valamit? Igen, b+, ott van, mert azon a rendszeren, amin eppen neztem, ott volt, es hirtelen nem kezdtem el a te ket szep szemedert olyan rendszer utan kajtatni, ahol nincs jelen ez a fuggoseg, de ettol meg tiz ev tapasztalata mondatja velem, hogy egyebkent ennek nem feltetlen kell ott lennie, es lattam mar tobb szaz olyan rendszert, ahol nem volt ott. "Valamiert megiscsak ott van", igen, mert a csomagot fordito egyen ezen a rendszeren epp ilyen opciokkal forditotta a binarist, de ettol meg lehet maskepp is, a cp-nek mint parancsnak nem feltetlenul kutya kotelessege kezelni se a SELinux attributumokat, se az ACL-eket, magahoz a munkahoz, amit elvegez (fajlok masolasa) egyikre sincsen szuksege. Es ha mondjuk egy kicsit utanajarnal, hogy mirol megy a beszelgetes, ahelyett, hogy csak idebofogsz dolgokat, akkor rajohetnel, hogy mekkora hulyesegeket mondasz. De hat ehhez mar dolgozni kellene, az meg nyilvan budos.

De tudod mit, hagyjuk is abba ezt a beszelgetest, mert baromi nehez egy vakkal beszelgetni az alma pirossagi fokairol. Legyen igazad, en ostoba vagyok, es te vagy a helikopter. Lehet felszallni.
--
Blog | @hron84
Üzemeltető macik

Szerintem azért nem mindegy, hogy az elején parse-olunk és a végén formázunk vagy pedig a csővezeték minden állomásán parse-olunk és formázunk.

Tényleg, a hagyományos Unix/Linux shell eszközökkel hogyan is kezeled az "XML-t, JSON-t, SOAP uzeneteket"? Ez szerintem épp a PowerShell melletti erős érv...

Üdv,
Marci

"Ez szerintem épp a PowerShell melletti erős érv..."

Ez szerintem épp amellett érv, hogy rendszerszinten legyen egy elvárt formátum az adatcserére, és ez ne shellfüggően legyen implementálva. Lehet az json is, xml is, a fenét se érdekel, ha egységes, lehet építeni rá hogy ugyanaz lesz mindenhol, és a parse-olást nem az alkalmazások és shell scriptek csinálják egyénileg, hanem kész tool vagy lib van rá.

"kész tool vagy lib van rá." -- az egyik ilyet .Net Core-nak nevezzük, ami egy MIT licencű szabad szoftver a GitHubon. Ezt használja a PowerShell is, tehát nem shellfüggő az implementáció.

(Félreértésveszély: fentebb az XML, json stb. nem a rendszeren belüli adatcsere formátumaként kerültek szóba.)

Üdv,
Marci

JSON-hoz es XML-hez is van tool Linux ala (JSON-hoz a jq, XML-hez is van valami util, fejbol meg nem mondom a nevet, mert ketszer kellett vele dolgoznom, de XPath-et elfogad), es ezzel mindenki le van fedve. Raadasul mindket util fuggosegi es memory footprintje eleg kicsi, az XPath-eshez is csak a libxml2 kellett, a jq meg onjaro, beepitett (meglepoen furge) JSON parserrel.

Ha bantoan oszinte akarok lenni, akkor btw Linux alatt JSON-bol/XML-bol konnyebb kiparzolni lassan az infokat, mint a mindenfele outputokbol sedelni. No persze, ha valaki elsutne azt a poent, hogy legyne minden appnak JSON/XML kimenete, a Linux vilag kiterne a hitebol, de hat ez van. Ettol fuggetlenul nem hiszek ezekben az objektum alapu kommunikaciokban, eleg sok infrastrukturalis es security problemat felvet a dolog. A PowerShell azert mas, mert o mindent belul, internalisan intez, raadasul a Windows filozofiajatol nem teljesen idegenek a monolitikus, multi-responsibility alkalmazasok, am Linuxon nagyon idegen test az egesz, a systemd -t is utaljak nagyon, hogy kezd monolitikussa es tobbfokuszuva valni, csak azert van ugymond sikere, mert a disztrogyartok elkezdtek lenyomni az emberek torkan. De ez meg meg tud maradni lathatatlannak (oke, mostly), de egy shell, az jo esellyel nem menne at. Az nem lesz lathatatlan soha.
--
Blog | @hron84
Üzemeltető macik

"JSON-hoz es XML-hez is van tool Linux ala" -- ... és Windows alá is. Nem erről beszélünk.

"A PowerShell azert mas, mert o mindent belul, internalisan intez" --
Én úgy látom, hogy még nem "ment át" a fejlesztők koncepciója feléd.
Ebben a cikkben van egy beágyazott video, javaslom szánj rá kis időt és nézz meg két és fél percet 18:54-től.

Üdv,
Marci

Koszi a linket, este majd megnezem a videot, de szerintem megint elfelejtettel rakerdezni, mire gondolok.

Az objektum alapu pipe azert tud mukdoni, mert az egesz egy folyamaton belul zajlik, nem ket kulonallo program kozott. A PowerShell infrastrkuturalis felepitese olyan, hogy csak azokhoz a dolgokhoz tud fancy objektum-pipe tamogatast adni, amihez van beepulo pluginje, cmdletje, akarmiletje, ez kulso folyamatokkal sosem fog mukodni, ahogy Windowson se mukodik. Egy bash/coreutils paros ehhez kepest sokkal rugalmasabb, mert bar szovegeket kell parsolni hozza, barmilyen, literally barmilyen kornyezethez, toolsethez hozza tud idomulni, a shell hasznalhatosagat nem korlatozza be, hogy te most eppen FreeBSD rendszeren dolgozol MIPS architekturan, es GPIO-n keresztul vezerelsz LED-eket. Ahhoz, hogy a PowerShell ehhez teljeserteku tamogatast tudjon adni, ahhoz:
- Tamogatnia kell a FreeBSD-t, mint platformot
- Kell valamifele pluginszeruseg a GPIO absztrakciojahoz
- Ezen felul a LED vezerles absztrakciojahoz is, ezen belul tamogatni kell azt, hogy a LEDController GPIO portot is tudjon fogadni API szinten
- Es mindezeknek egyszerre kell jelen lenniuk

Ez egy egyszeru feladat, megis 4 tenyezonek kell jelen lennie a shellen belul. Ezzel szemben egy bash script szamara egyvalami kell: hogy legyen egy "gpio get/set" parancs, az osszes tobbit meg lehet oldani scripten belulrol, de egyebkent ez meg nem a shell fuggosege.

Abban a pillanatban, hogy nekem C# kodokat kell irnom, meg DLL-eket forditanom egy adott taszk kivitelezesehez (ha a fenti dolgokat magam akarom implementalni), azon a ponton a Bash elkepzelhetetlen elonyre tett szert.
--
Blog | @hron84
Üzemeltető macik

"Abban a pillanatban, hogy nekem C# kodokat kell irnom, meg DLL-eket forditanom egy adott taszk kivitelezesehez (ha a fenti dolgokat magam akarom implementalni), azon a ponton a Bash elkepzelhetetlen elonyre tett szert. "

vs

csilliónyi 3rd party tool megírása random nyelveken, random libekkel, random API hívásokkal. Tényleg nem ugyanazt a problémát oldod meg, valóban nem. Még csak véletlenül sem.

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

" 3rd party tool megírása random nyelveken, random libekkel, random API hívásokkal."

Ezeket nem en irom meg. Egyiket sem. Ha en valamit megirok, akkor azt nem random nyelveken, hanem bash-ban vagy legfeljebb Rubyban teszem, nem random libekkel, hanem sajat fuggvenykonyvtarakkal (if any), es egyaltalan nem random API hivasokkal.
--
Blog | @hron84
Üzemeltető macik

"diszken "

Ki a faszt érdekel, hogy a disken mi van? Miután egyszer megkaptam, nekem DateTime-m van és végig az is marad. (Szerencsére a .NET-ben nem álltak neki 26 féle DateTime osztályt csinálni, mint Java-ban.)

"SOAP"

Breaking news: Ha SOAP-on átdobok egy DateTime-t, akkor a hívó és a küldő oldalon is DateTime lesz. Közte XML lesz belőle? Vagy füstjelek? Kit érdekel, komolyan. Lényeg az, hogy mindig egy strukturált, jól és _egyértelműen_ beazonosítható adatom van, nem valami karakterkupacom.

"Az a problema, hogy nem tudom eldonteni, hogy [random személyeskedés]"

Az a probléma, hogy te vagy túl hülye ahhoz, hogy felfogd, hogy függőségek így is úgy is lesznek és kurvára nem érdemes rajta rugózni, hogy most egy .NET framework vagy n+1 külön függőséged van. Breaking news: .NET frameworkből sem töltődik be mindig minden.

"Legyen igazad, en ostoba vagyok, es te vagy a helikopter. Lehet felszallni."

Tükörbe próbáltál már nézni?

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


root@ubuntu:/home/ubuntu/Downloads# apt-cache showpkg powershell
...
Dependencies: 
6.0.0-alpha.11-1ubuntu1.16.04.1 - libc6 (0 (null)) libcurl3 (0 (null)) libgcc1 (0 (null)) libssl1.0.0 (0 (null)) libstdc++6 (0 (null)) libtinfo5 (0 (null)) libunwind8 (0 (null)) libuuid1 (0 (null)) zlib1g (0 (null)) libicu55 (0 (null)) 

root@ubuntu:/home/ubuntu/Downloads# apt-cache showpkg bash
Dependencies: 
4.3-14ubuntu1.1 - dash (2 0.5.5.1-2.2) libc6 (2 2.15) libtinfo5 (2 6) base-files (2 2.1.12) debianutils (2 2.15) bash-completion (3 20060301-0) bash-completion (2 20060301-0) bash-doc (0 (null)) bash-completion (3 20060301-0) bash-doc (1 2.05-1)

Hol itt a bash jelentős előnye a függőségek terén?

Üdv,
Marci

Ja, igazad van, nem kell neki .NET framework, mert... dobperges... a csomag maga tartalmaz rogton egyet! Ami azert jo, mert siman lehet, hogy el fog maradni az itt levo Mono a rendszerben telepitettol, mind verzioban mind pedig serulekenysegek/bugfixek teren.

Egyebkent en nem a showpkg kimenetet szoktam nezni, hanem letoltom a csomagot, es belevizualok, hogy mik vannak benne. Ebben kerlek ket kazal DLL van, ami Linux alatt onalloan annyira nem uzemkepes.

De kerlek, ervelj meg. Csak ne akard hulyenek nezni a masikat, mert az annyira nem noveli a hitelessegedet. Koszike.
--
Blog | @hron84
Üzemeltető macik

Látom, megint elevenbe találtam. :)
Kérlek, olvasd újra a hozzászólásokat, Te kezdtél arról beszélni, hogy "nem kell neki .Net Framework", ilyet én nem mondtam.
Amúgy tényleg Mono van a csomagban? Én azt hittem, hogy CoreCLR, pedig nem is "vizuáltam bele"...
Hogy személyeskedni miért kezdesz ("ne akard hulyenek nezni a masikat"), fogalmam sincs.
Kérdeztem, hogy hol a bash előnye a függőségek terén? Erre te válasz helyett a PowerShell csomag tartalmáról beszélsz. Annak nincs köze a függőségekhez.

Üdv,
Marci

Segitek: A PowerShell nevezetu szoftver fuggosegeirol beszelunk, es nem a powershell nevu csomag fuggosegeirol. Erzed, mi a kulonbseg a ketto kozt? Attol, mert a PowerShell csomag beepitetten hoz egy CoreCLR/Mono/whatever (nem, nem neztem meg kozelebbrol, milyen DLL-ek vannak benne, egyet kicsomagoltam, es .NET-esnek ismerte fel a rendszer) bele van csomagolva a csomagba, attol meg a PowerShellnek, mint szoftvernek (es nem mint powershell csomagnak) szuksege van ra, fugg tole. A Bash, mint szoftver fuggosegeit ismertettem, es az a lista joval kisebb, mint a PowerShelle.

De mondok mast. Ott van peldaul a VMware vSphere Client, ketto darab fuggosege van neki, a Visual Studio C++ 2005 (talan? a verziot nem tudom pontosan) Runtime es a Visual J# Runtime. Mind a kettonek a telepitoje benne van a vSphere Client telepito EXE-jeben. Mondhatjuk, hogy a vSphere nem fugg semmitol? Ha kitorlom/uninstallalaom a J# runtime-t, akkor is uzemkepes lesz? Nem lesz, azert, mert maga a szoftver fugg tole, az, hogy a csomagban jon, irrelevans. Csak csomagolas kerdese, hogy belecsomagolod a fuggosegeket, vagy kulon csomagban szallitod. Attol, mert benne van egy csomagban, meg nem lesz a szoftver resze.

Tudom, hogy rettenetesen jo marketingfogas az "apt-cache showpkg" kimenetere hagyatkozni a szoftver tenyleges ismerete helyett, de kerlek, ne nekem probald eladni a termeket. 10 eve gyurom a Linuxot, tudom, hogy mi hajtja.
--
Blog | @hron84
Üzemeltető macik

Hat peldaul a PowerShell sajat dokumentaciojat, ahol nem is egy ponton utalnak ra, hogy a PowerShell amugy a .NET Core libraryra hagyatkozik. Persze, ehhez el kell olvasni az egeszet, eleg szaraz es unalmas szoveg, ezt alairom.

De igazabol meg erre sincs szukseg, egy kis jozan paraszti eszet kell vinni a dologba: ha Windowson .NET cuccok kellenek a PowerShell hasznalatahoz (marpedig XP/2003 ota az kell, meg eleve, integralodik a .NET frameworkkel, eleg csunya melysegekben, lasd get-member, .GetType(), new-object es tsai, plusz az osszes PowerShell plugin .NET CLR DLL), akkor ez Linuxon sincs maskepp. Allitolag te meg ismered a Windowst illetve a PowerShell-t, azt gondoltam, ebbol konnyen ki lehet kovetkeztetni, hogy ha valaminek kozos a forraskodja 2 platformon, akkor Linuxon nem fog hirtelen onjaro lenni a cucc.
--
Blog | @hron84
Üzemeltető macik

Kérlek, olvasd újra a hozzászólásokat, Te kezdtél arról beszélni, hogy "nem kell neki .Net Framework", ilyet én nem mondtam. Én arra kérdeztem rá imént, hogy milyen parancs kimenete mutatja Számodra hitelesen a függőségeket, hogy a bash-al összevethető legyen? ldd? Vagy mi?

Üdv,
Marci

Te kezdtél arról beszélni, hogy "nem kell neki .Net Framework", ilyet én nem mondtam.

Hat, inkabb neked kellene ujraolvasni a hozzaszolasokat, en pont az ellenkezojet bizonygatom egy ideje, te meg idepasztaztad nekem az "apt-cache showpkg powershell" parancs kimenetet, bizonyitani, hogy a PowerShell es a bash fuggosegei ugyanolyanok. Amikor finoman felhivtam a figyelmedet, hogy attol, mert a PowerShell csomag, mint olyan, beepitve hoz magaval egy komplett .NET frameworkot, akkor meg elkezdtel azon lovagolni, hogy milyen parancs mutatja meg a fuggosegeket.

Ezen felul bemutattam (direkt a prompttal egyutt pasztaztam, hogy visszakovetheto legyen az, amit csinalok, es kiprobalhato, esetleg mas binarisokkal is), hogy en hogyan nezem meg egy program fuggosegeit (az ominozus ldd parancs).

Ezen felul, ezt az egesz vitat lezarhatna az, ha nem az apt-cache showpkg -val foglalkoznal, hanem peldaul feltelepitened azt a tetves csomagot a Linuxodra, es megnezned, hogy milyen fajlokat telepit (segitek, Ubuntu alatt a "dpkg -L powershell" parancs lesz segitsegedre, bar ezt ketto perc kiguglizni), es lass csodat, nem egy nativ Linuxos binarist fogsz latni, hanem egy DLL-ekkel surun teletuzdelt fajllistat. Azt pedig okitasodul kozlom, hogy Linuxon nem kifejezetten a DLL a legelterjedtebb binaris formatum.

Valaki egyebkent segitsen mar, tenyleg ennyire bonyolult utanajarni dolgoknak? Esetleg en vagyok tulkepzett a temaban, hogy letoltom es belenezek Midnight Commanderrel egy DEB csomag tartalmaba mielott barmit kijelentenek rola? Vagy esetleg az szokatlan, hogy en utanaolvasok, utananezek annak, hogy mi kell egy szoftver forditasahoz, es kitalalom, hogy ha a forditas soran kell neki a .NET Framework, akkor nem valoszinu, hogy a futashoz nem kell? Azt mar meg sem emlitem, hogy a PowerShell egyebkent (most mar) reszben nyilt forrasu cucc, bele lehet nezni a forrasaba (sot, ezt sem kell, a GitHub keszsegesen osszefoglalja a nyelvstatisztikat elore), es lathato, hogy 92.4%-ban C#-ban irodott, ami koztudomasulag olyan nyelv, amirol nemigen forditanak nativ binarisokat.
--
Blog | @hron84
Üzemeltető macik

Úgy tűnik, valamiért teljesen félreértesz. Tudtam, hogy kell neki a .Net Framework és azt is, hogy hozza magával: sose beszéltem másról. Ellenben Te megpróbáltad a számba adni: "Ja, igazad van, nem kell neki .NET framework, mert... dobperges... ". Ezt utasítom vissza azóta folyamatosan.
Egy félreértés volt köztünk a topikban: én a PowerShell csomag függőségeiről beszéltem, Te meg a powershell program library-függőségeiről.

A PowerShell a megjelenése óta fel van telepítve nálam, virtuális gépben Linuxra és WSL-re is.

Itt az ldd kimenete, ha Neked az számít: 


$ ldd /bin/bash
        linux-vdso.so.1 =>  (0x00007fffe019a000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f5630ad0000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f56308c0000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f56304e0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5630e00000)
$ ldd /usr/bin/powershell
        linux-vdso.so.1 =>  (0x00007ffff201e000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0e6da40000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0e6d820000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0e6d500000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0e6d1f0000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0e6cfd0000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0e6cbf0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0e6de00000)

"PowerShell egyebkent (most mar) reszben nyilt forrasu cucc" -- Nem részben, egészben.

Üdv,
Marci

Nem kotozkodeskent mondom, de a /usr/bin/powershell amugy pont csak egy wrapper, ami elinditja az egeszet.

"Úgy tűnik, valamiért teljesen félreértesz. Tudtam, hogy kell neki a .Net Framework és azt is, hogy hozza magával: sose beszéltem másról. Ellenben Te megpróbáltad a számba adni: "Ja, igazad van, nem kell neki .NET framework, mert... dobperges... ". Ezt utasítom vissza azóta folyamatosan"

Jo, porgessuk vissza az ido kereket, hogy tisztan lasd, mi a problemam ezzel az egesz beszelgetessel, mert ugy latom, suketek parbeszede zajlik koztunk, ami nem vicces.

Innen indultunk (ezt most csak toredekesen idezem):

Na, emiatt a PowerShell sosem lesz default shell Linuxon, itt ugyanis eleg fontos szempont a default shell kivalasztasanal, hogy
- minel kevesebb libtol fuggjon (Ncurses, Readline, aztan nagyjabol ez a sor vege)

Amire a te reakciod:

root@ubuntu:/home/ubuntu/Downloads# apt-cache showpkg powershell
...
Dependencies:
6.0.0-alpha.11-1ubuntu1.16.04.1 - libc6 (0 (null)) libcurl3 (0 (null)) libgcc1 (0 (null)) libssl1.0.0 (0 (null)) libstdc++6 (0 (null)) libtinfo5 (0 (null)) libunwind8 (0 (null)) libuuid1 (0 (null)) zlib1g (0 (null)) libicu55 (0 (null))

root@ubuntu:/home/ubuntu/Downloads# apt-cache showpkg bash
Dependencies:
4.3-14ubuntu1.1 - dash (2 0.5.5.1-2.2) libc6 (2 2.15) libtinfo5 (2 6) base-files (2 2.1.12) debianutils (2 2.15) bash-completion (3 20060301-0) bash-completion (2 20060301-0) bash-doc (0 (null)) bash-completion (3 20060301-0) bash-doc (1 2.05-1)

Hol itt a bash jelentős előnye a függőségek terén?

Mar megbocsass, de en nem adtam a szadba semmit. Ezzel a kommenteddel te allitottad implicite, hogy a bash es a PowerShell fuggosegei kozott nincs erdemi kulonbseg. En pedig ravilagitottam, hogy igenis van, mert a PowerShel-nek kell .NET framework, ami a bash-nak sosem kellett, es ez a bash elonye a PowerShellhez kepest, mert nem fugg egy viszonylag bloated frameworktol.

Amikor ravilagitottam, hogy a csomag fuggosege nem igazan valid erv, azzal jottel, hogy

Kérdeztem, hogy hol a bash előnye a függőségek terén? Erre te válasz helyett a PowerShell csomag tartalmáról beszélsz. Annak nincs köze a függőségekhez.

Ez igy elegge offenziv valasz volt ahhoz kepest, hogy en csak azt kezdtem el pedzegetni, hogy a PowerShell igenis fugg a .NET Frameworktol, amit te megprobaltal elkenni. Attol, mert belepakoljak a csomagba, attol meg a PowerShell igenis .NET fuggo, a Bash pedig nem az. Es az sem igaz, hogy egy csomag tartalmanak ne lenne koze a fuggosegekhez, az osszes nagyobb gyarto (VMware, Oracle, Dell, IBM, stb) belepakolja az epp aktualis fuggosegeket a csomagba, mert nem akarjak a sajat release ciklusukat a fuggosegeik ciklusahoz igazitani, marpedig a zart forras miatt muszaj az ABI kompatibilitast megorizni valahogyan.

De tudod mit Marci, en nem akarok veled vitatkozni. Valoszinuleg az a problema, hogy en mivel 10 eve vagyok a szakmaban, kisse elobbre gondolkodok, mint te, jobban latom az egesz kepet, es jobban ertem, hogy mi tortenik a hatterben, cserebe borzalmasan rosszul magyarazok. Nem veletlen, hogy soha nem mentem az oktatasnak a kozelebe se (marmint, mint karrier), mert alkalmatlan vagyok erre.
--
Blog | @hron84
Üzemeltető macik

"Ezzel a kommenteddel te allitottad implicite, hogy a bash es a PowerShell fuggosegei kozott nincs erdemi kulonbseg. " -- Pontosabban, Te a kérdésemet állításnak vetted. Én azonban nem állítottam, kérdeztem (félreértve, hogy csomag vagy library függőségre gondoltál): "Hol itt a bash jelentős előnye a függőségek terén?" Szerettem volna megérteni az álláspontodat.

"amit te megprobaltal elkenni" -- légy szíves, ne csináld ezt.

"Ez igy elegge offenziv valasz volt" -- Másképp látom. Én csomagfüggőségekről (nem library függőségekről) beszélek és valóban: egy csomag beltartalmának nincs köze a csomagfüggőségekhez. Az ez utáni hozzászólásodban tisztázod, hogy milyen függőségekről beszélsz.

"Valoszinuleg az a problema, hogy en mivel 10 eve vagyok a szakmaban, kisse elobbre gondolkodok, mint te, jobban latom az egesz kepet, es jobban ertem, hogy mi tortenik a hatterben" -- Valószínűleg.

Üdv,
Marci

Mivel a szal elejen azt sem tudtam, hogy a PowerShellbol letezik Ubuntu csomag (ezt a hirt abbol vettem le, hogy megmutattad az "apt-cache showpkg" kimenetet), eszembe se jutott, hogy csomagfuggosegekrol beszeljek, a legutolso hirem errol a szoftverrol az, hogy letrejott egy GitHub repo ra. Altalanossagban veve, ha valahol azt mondja valaki, hogy X fugg Y-tol, akkor az X nevu szoftverrol es nem az x nevu csomagrol beszelunk. Legalabbis, az informatikaban ez volt az alapvetes ugy 10+ eve, amikor en ezt tanultam. Aztan lehet, hogy azota fordult a vilag, majd megprobalok utanamenni, es legkozelebb meg egyertelmubb lenni. Csak mindig attol felek, hogy akkor meg azt hiszed, hulyenek tartalak, hogy ennyire szajbaragos vagyok.
--
Blog | @hron84
Üzemeltető macik

"a Bash pedig nem az. "

Cserébe akármit akarsz csinálni, szükség lesz csilliónyi más toolra és máris ott vagyunk, hogy tökugyanazok a kódok ott lesznek a rendszerben ilyen vagy olyan formában. Na ezért mondom, hogy kurvára érdektelen az, hogy függ-e a .NET frameworktől vagy sem. Ha nem érted meg, hogy egy csupasz bash használhatatlan önmagában, mert még egy fájl másolásához is a /bin/cp kell, akkor nincs nagyon miről beszélnünk.

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

"DLL "

Remélem az megvan, hogy a .so és a (natív) .dll egyébként olyan sokban nem különbözik a headereket leszámítva? (Segítek: mindkettő az adott architektúra utasításait tartalmazza.) Remélem az is megvan, hogy egyébként semmi akadálya nincs annak, hogy a .so -t .dll-nek nevezd el, vagy akár implementáld Linuxon a Win32-es hívási rendszert.

És remélem az is megvan, hogy a .NET-es assemblyknek nagyjából 0 köze van a régi natív dll-ekhez és sokkal közelebb áll egy .jar fájlhoz, mintsem egy .so-hoz vagy egy .dll-hez. De lovagolj még tovább az érdektelen fasságon.

"nativ binarisokat"

És az kit érdekel, hogy natív vagy sem? (Egyébként breaking news: [url=https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110).aspx].NET NAtive[/url].

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

Es ez a .NET Native ez mennyire van elterjedve a .NET programozok koreben? Most mar minden program .NET Native-ban fog kijonni? Csak hogy a link relevanciajat belojem.

A .DLL vs .so kerdesre meg reagalni se ohajtok. Idecibaltal valamit, aminek aztan vilagon semmi koze a temahoz. De egyebkent koszi a fejtagitast.

Es kesz, ezzel befejeztem, ebben a szalban a tovabbiakban csak Marcinak reagalok.
--
Blog | @hron84
Üzemeltető macik

Jó, segítek lefordítani: rajdtad kívül senkit nem érdekel, hogy hány függősége van és, hogy egyébként hány részből áll a .NET FW. Azért vannak ezek a frameworkok, hogy ne kelljen csillió-billió extra libet összeharácsolni.

Segítek: libc is ugyanilyen framework, csak sokkal kevesebb dolgot tartalmaz.

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

Ez teny, es nem is a .NET Framework letet vitatjuk, hanem azt, hogy egy olyan shellnek, aminek ennyire nagy es komplex frameworkre van szuksege, van-e eselye default shelle valni egy olyan platformon, ahol a libc fuggosegen kivul nagyon-nagyon keves dologra van a legtobb shellnek es parancsnak szuksege. De persze ez inkabb uzemeltetoi problema, semmint fejlesztoi, ertheto, hogy nem annyira latod a kulonbsegeket.
--
Blog | @hron84
Üzemeltető macik

Ahhoz nekem is erős fantáziára van szükségem, hogy interaktív default shellnek vizionáljam a közeljövőben a PowerShellt Linuxra. Pláne, hogy -- ahogy említetted -- még Windowson sem az. :)
Viszont a cattle jellegű üzemeltetésnél és felügyeletnél, devops szcenáriókban szerintem jóval hamarabb lehet szerepe a multiplatformos működése meg korszerű és gazdag könyvtár-támogatása miatt.
Ott még az sem akkora tragédia, ha egy elzsibbadt szerveren kevéssé jut erőforráshoz: ha nem válaszol a gép, az automatizáció kinyírja.

Gyanúmat erősíti a bejelentés blogbejegyzése. Ezeken akadt meg a szemem (önkényesen):
-how Microsoft Operations Management Suite can enhance the PowerShell experience
-use the same tools, and the same people, to manage everything from anywhere
-heterogeneous automation and configuration management
-extending the PowerShell Remoting Protocol (MS-PSRP) to use OpenSSH as a native transport
-OMS Automation elevates PowerShell and Desired State Configuration (DSC) with a highly available and scalable management service from Azure
-graphically author and manage all PowerShell resources

Üdv,
Marci

Mert egy ennyire nagy és komplex frameworkből ugye mindig mindent betölt az ember? Egyébként magam részéről nem látok drasztikus különbséget a függőségeken való rugózás esetén. Szvsz. kurvamindegy, hogy egy shell scriptből indított program húzza be a zlib-et meg a random regexp libraryt, vagy ugyanezt a .NET frameworkből húzza be. (Illetve nem, mert mikor egy külső program teszi, ott indítasz egy új progarmot, ami akár elég költséges is lehet.)

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

( NevemTeve | 2016. 10. 25., k – 09:13 )

Off: szvsz nem vagyunk már messze attól az állapottól, hogy a vezető linuxos disztrókra figyelmeztető feliratot kelljen tenni: "Windows-szerű termék, nyomokban Unixot tartalmazhat. Ne használja, ha allergiás a systemd-re"