Na těch screenshotech je vidět, že zkompilovaná jádra nejsou úplně stejná, asi to Dustin nemá ještě úplně zvládnuté.
Pořád mi nějak není jasné, k čemu to vlastně bude. Všechny klasické a oblíbené přední open source programy pro Linux, jako je Apache, PostgresQL, ale i Blender, Inkscape, Audacity nebo Flightgear, mají nativní verze pro Windows a takovouhle kompatibilní vrstvu nepotřebují. Na druhou stranu některé novější projekty, jako Docker, LXD apod. jsou Linux-only protože používají specificky linuxuvé API a v Ubuntu pro Windows fungovat nebudou. Ono toho je vlastně docela dost, co nefunguje ani pod mnohem starší a zralejší kompatibilní vrstvou pro FreeBSD. Takže nevím, co tím vlastně soudruzi z Redmondu sledují.
Microsoft straca vyvojarov
Stackoverflow Developer Survey Results 2016
VIII. Desktop Operating SystemMac OS X 26.2%
Linux 21.7%47,9% vyvojarov nepouziva Windows.v roku 2013Mac OS X 18.7%
Linux 19.9%
Other 1,0%
teda len 39,6 http://stackoverflow.com/research/developer-survey-2016
Analytici v MS zistili, že Linux a OS X majú spoločný bash, tak manažér nariadil dať bash do Windows, lebo toto je, podľa neho, dôvod odchodu vývojárov, ale keď to budú mať vo Windows neodídu..
To je jen anketa mezi uživateli serveru, na kterém se "vývojáři" ptají, jak v JavaScriptu nahradit podtržítka za mezery, plusy za mezery a mezery za středníky. Ano, tohle jsou opravdu tři různé dotazy, a podobných trivialit je tam většina. Nečinil bych z toho závěr, že MS ztrácí vývojáře.
BTW bash se dal triviálně nainstalovat i pod Windows Services for UNIX.
To ale zachovali
Linux subsystem could cause Windows 10 Anniversary Update to eat itself
The main problem stems from the fact that the two kernels have direct access to each other - no hypervisors, just two systems with identical access.
It's a bit of a crazy face-palm moment, really. Who did it not occur to that Windows and Linux apps could be modified by each other, bypassing the patches put in place natively?
Code injection is just one example of how a Windows program could attack a Linux app. Once the code is injected, if the infected Linux application makes a call back to Windows, it will be trusted and could trigger some proper borkage.
http://www.theinquirer.net/inquirer/news/2467416/linux-subsystem-could-cause-windows-10-anniversary-update-to-eat-itself
To je kompatibilita s DOSmi..
Ten vámi citovaný článek má pár problémů. Hlavní problém je v tom, že Windows se Subsystem for Linux (WSL) mají jen jeden kernel. Linuxové procesy běží v pico procesu, který veškeré syscalls směřuje na pico provider (kernel driver), který buď linuxový syscall přeloží na windowsí, nebo ho sám obslouží. Chris Merriman z theinquirer.net by si měl aktualizovat znalosti, nebo si alespoň přečíst článek, na který odkazuje.
Dále souhlas, že aplikace pro Window může ovlivnit aplikaci pro Linux a případně naopak, pokud na to má práva. Jenže ona i aplikace pro Windows může ovlivnit jinou aplikaci pro Windows, a aplikace pro Linux jinou aplikaci pro Linux.
Samozřejmě že WSL není tak izolovaný, jako virtuální stroj přes Hyper-V. Je izolovaný řekněme jako containers, což má výrazně nižší režii.
Riziko vidím spíš v tom, že WSL zvětšuje attack surface. Jenže to se dá říct i o DB serveru nebo jakémkoliv jiném kusu SW. WSL navíc není by default nainstalovaný, a pochybuji že si ho zapne větší procento uživatelů. Ve výsledku tedy pro útočníky nebude zajímavý, zvlášť když mají k dispozici věčně děravé browsery, uživatelé jsou ochotni spustit zavirované přílohy a dokonce si rozbalit zavirovanou přílohu heslem přiloženým v mailu.
Ad To je kompatibilita s DOSmi - co se tím snažíte říct?
Zdroje:
https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/
https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/
https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-calls/
je tam aj ta, ale nie len ta skupina
uly 29, 2015
The most popular programming languages on StackOverflow
na 4. mieste je c#
http://blog.revolutionanalytics.com/2015/07/the-most-popular-programming-languages-on-stackoverflow.html
Stack overflow pouizva ako relevantny zdroj aj IEEE
IEEE Top Programming Languages: Design, Methods, and Data Sources
The IEEE Spectrum Top Programming Languages app synthesizes 12 metrics from 10 sources to arrive at an overall ranking of language popularity.
jeden z tych 10 zdrojov jew aj Stackoverflow
http://spectrum.ieee.org/ns/IEEE_TPL/methods.html
A potom je najdoveryhodnejsi hoax
Washington DC – The IEEE have produced a report today where they strongly recommend that from now on, the discipline of Computer Programming should be officially renamed to “Googling Stackoverflow”.
“We are recommending a root-and-branch name change to this discipline”, said President of the IEEE, Thomas M. Conte. “We are even going to change the official name of the IEEE Computer Society to the IEEE Quick Look At StackOverflow Society”.
“We are furthermore recommending that all universities across the planet should cease to award Bachelors degrees, Masters or PhDs in computer programming or software engineering and instead they should award these degrees in Googling Stackoverflow.”
http://www.theallium.com/engineering/computer-programming-to-be-officially-renamed-googling-stackoverflow/
Lebo to zodpoveda realite, ako programuju dnesni studenti..
Programátorské schopnosti absolventov klesajú, problémom je Java
Publikované pred 8 rokmi: 17.01.2008 / Marek Tyler, čítaní: 42858
vytlačiť
poslať e-mailom
ohodnotiť
Dvaja profesori z New York University sa v obšírnejšej rozprave zaoberali problémom, ktorý trápi mnohých zamestnávateľov v IT priemysle: programátorské schopnosti nových absolventov počítačových vied sa postupne znižujú. Podľa nich za to môžu úvodné kurzy Javy a skriptovacích jazykov.
Vývoj programovacích schopností vo viacerých jazykoch potom študentov učí automaticky používať veľké knižnice a špeciálne balíky s kódom, akoby programovali z predpripraveného receptu[kuchárskej knihy]. Výsledným negatívom pre softvérový priemysel je nedostatočná zručnosť, najmä pre bezpečnostné a ochranné účely, ktorá je navyše prakticky na úrovni toho, čo ponúka outsourcingový priemysel.
http://old.itnews.sk/spravy/produkty/2008-01-17/c87894-programatorske-schopnosti-absolventov-klesaju-problemom-je-java
A potom googling stack overflow vyjadruje realitu masovej tvorby SW.
Uz ma tieto zbytocne dissy na javu unavuju. Ako by v inych jazykoch neboli kniznice a frameworky. Uz aj v "blbom" ANSI C je kopec hotovych veci. (Co je podla mna dobre, mam rad libky pre ansi c)
Java umoznuje lepsie rozmyslat o modularite aplikacie, nenuti cloveka pisat spagety. Pre to je taka popularna, nie preto, ze by ju tlacili na silu studentom.
V robote som mal uz v jave ulohy, kde sa navrhoval novy algoritmus. Prototyp sa robil v jave, do inych jazykov sa to prepisovalo az potom, lebo java ma rozumnu uroven abstrakcie, dobre sa debuguje, a nestane sa ze by niekam do neznama uletel pointer a pripadne sposobil segfault.
Java je najpopularnejsi jazyk, tak v nej asi bude aj najviac zaciatocnikov. Robim v jave 12 rokov, zazil som vselico.
Na zaver tu necham toto: http://www.pbm.com/~lindahl/real.programmers.html
To myslíš sebe? Dotkl jsi se pár důležitých témat ale jaksi ty důvody k nim kulhají.
"Java umoznuje lepsie rozmyslat o modularite aplikacie, nenuti cloveka pisat spagety"
To se děje v každím 2. jazyku. Ale i v javě se dá napsat špageta, třeba 50k řádků do main{} nebo vše do jedné třídy a jedné metody. Takže Javou to nebude, ale tím vlastně +1 pro tebe ;-)
"V robote som mal uz v jave ulohy, kde sa navrhoval novy algoritmus"
To se občas programátorovi stane.
"Prototyp sa robil v jave, do inych jazykov sa to prepisovalo az potom, lebo java ma rozumnu uroven abstrakcie, dobre sa debuguje, a nestane sa ze by niekam do neznama uletel pointer a pripadne sposobil segfault."
Ano, ale prototypování se dělá hlavně v jazyku, který dokonale ovládáš, aby to bylo rychlé a bylo možno vyřešit co nejzasvěceněji a nejefektivněji ty nejproblémovější místa. K čemu ti pomůže, že v prototypu v javě ti to nehhodí segfault ale pak to přepíšeš do jiného jazyka, kde segfault hrozí? To ti asi moc nepomůže, že to máš nejprve v javě.
"Java je najpopularnejsi jazyk, tak v nej asi bude aj najviac zaciatocnikov. Robim v jave 12 rokov, zazil som vselico."
No, nejpopulárnější v nějakém oboru. Ve webařině třeba asi ne.
"http://www.pbm.com/~lindahl/real.programmers.html"
Pěkná blbost.
Ok. Hlavně mi šlo o to, že "objektový jazyk" s balíčky nezabrání programátorovi prasit špagety - ať už kratší nebo delší. Nevím o tom, že by na to java měla nějakou podporu. Samozřejmě hinty v IDE nebo nějaký validátor určitě existovat bude - to už ale nevím. Prostě atomicitu podle mne nezajišťuje jazyk, ale styl psaní - tedy při psaní vlastních funkcí - volání knihoven do jisté míry atomicitu do kódu vnáší samo o sobě.
Ne modularitu jsem na mysli neměl.
https://cs.wikipedia.org/wiki/Atomicita
Radši netipuj. Evidentně ti to moc nejde.
Protože jsme se bavili o špageti kódu a atomicita je jedna z věcí, která tomu odporuje, protože dělí kód na menší funkční celky.
Já to jen zmínil v textu, ale "balki" se toho chytl, protože při tom jeho ťápání zťápal dohromady vytvoření prototypu v javě a návrh algoritmu (jak o tom pak psal tak asi nekde na papíře) a tak mu nezbylo než se něčeho chytit. No a tak jsem mu hodil link a už jsem troll . . . jednoduché
A jaký je rozdíl mezi "nalinkováním" a "aktivním nalinkováním"?
"Atomicita neboli nedělitelnost je důležitá vlastnost v programování. Znamená, že daná činnost (operace) se provede najednou, nemůže být přerušena něčím jiným a později dokončena"
Ano, samozřejmě je o způsobu vykonání kódu, ale to že je celek nedělitelný a vykonává se hned a celý, neznamená jenom u otevření souborů a úpravy souborů. Jako atomickou operaci beru taky třeba zavolání funkce, která se vykoná a nemůže být ničím přerušena - třeba vyhozením vyjímky - a často jsou takovéto kusy kódu poslední nedělitelné celky, kterých ale špageti kódem nedosnáhnu. Naopak ano. A proto atomicita přispívá k nepsání špageti kódu. Pletu se? Možná. Možná jenom podle Vás, možná úplně. To ovšem ale není důvod označovat mě za trolla nebo vytahovat "Grammar nazi" doktrínu.
O modulech jsem nemluvil. Nikde.
Ako pise pan Satai nizsie, volanie metody (respektive funkcie, aby som neslovickaril) nie je atomicke. Vykonavana metoda (funkcia) moze byt prerusena vo vykonavani na ktoromkolvek mieste. (prerusena znamena, ze sa po chvili znova spusti). Preto je treba uplatnovat rozne strategie synchronizacie pristupu k zdielanym zdrojom, aby sa data aplikacie nedoje**li. O tom sa daju pisat cele litanie, rieseni je vela. Kazde riesenia ma svoje vyhody a nevyhody. Mate rad wikipediu, tak pre inspiraciu tu mate link https://en.wikipedia.org/wiki/Synchronization_(computer_science)
Ako sa to robi v jave https://docs.oracle.com/javase/tutorial/essential/concurrency/sync.html
Tak samozřejmě debuggerem může, ale to může být taky přes gdb na úrovni processoru, takže bys atomickou měl akorát tak 1 instrukci assembleru.
Wikipedii rád nijak extra nemám, není to 100% relevantní zdroj, ale tak na obecně se hodí.
Ako sa to robí v Javě mě ani nějak nezajímá, protože už v ní nedělám ani to neplánuju, ostatně při spuštnění jednoduché funkce není sync potřeba, protože ne každá funkce musí manipulovat se sdílenými zdroji nebo do nich někde hrabat a pokud jako sdílený zdroj bereš i zdrojový kód, tak ten lze stejně nakonec spustit jenom jako současný a nebo nový. Žádnou poloverzi nespustíš.
Co píše Nekola je k ničemu, jsou to jenom přiblblé poznámky, kterýma přicmrndává tu a tam, občas tam a ještě někde. Takový naivní pokus o samozvaného moderátora pravdy v rádoby sarkastickém duchu.
"K čemu ti pomůže, že v prototypu v javě ti to nehhodí segfault ale pak to přepíšeš do jiného jazyka, kde segfault hrozí? To ti asi moc nepomůže, že to máš nejprve v javě."
Pomoze to dost, lebo ked vymyslas algoritmus, tak posledne co chces, je riesit low level zalezitosti. Ide o to, ze algoritmus, je skor predpis vypoctu, nez implementacia. To dosial maju s tym niektori problem oddelit algoritmus od implementacie. Ked je uz predpis, tak je jedno, ze to hodi 50 segfaultov v c-cku, ono sa to po par iteraciach uz upravi. Ked uz je to zapatentovane a je hotova referencna implementacia, moze sa to prepisovat bars aj do brainfucku 3 roky.
"To se děje v každím 2. jazyku. Ale i v javě se dá napsat špageta, třeba 50k řádků do main{} nebo vše do jedné třídy a jedné metody. Takže Javou to nebude, ale tím vlastně +1 pro tebe ;-)"
Ide o to, ze java hadze najmenej modularite polena pod nohy (spolu s c# co je copycat java). Nie nadarmo v jave vznikalo aspektovo-orientovane programovanie, a prispela k popularite a zreformovaniu component-based programovania.
"Pomoze to dost, lebo ked vymyslas algoritmus, tak posledne co chces, je riesit low level zalezitosti. ..."
Ano, ale to že ti to jede v javě, neznamená že ti to pojede jinde. A pokud ti to nemá jet třeba v C z nějakého důvodu, tak to nepojede, i kdyby jsi v javě napsal prototyp 130x. A nebo ty segfaulty vychytáš, ale to bys vychytal i bez prototypu v javě. Celé je to ale tím, že prototyp se dělá buď jako proof of concept, preview pro zákazníka, případně pro odhady náročnosti a časů nebo nějaká tato kombinace. Ne proto, že když to jede v javě, pojede to i jinde a když to neuděláš prvně v javě, tak to v ničem jiném normálně nepojede.
Argumentu o "snadném debugování" rozumím, ale stejně tak si někdo oblíbí třeba jiný skvělý jazyk.
"Ide o to, ze java hadze najmenej modularite polena pod nohy (spolu s c# co je copycat java)"
O tom by se polemizovat dalo. Existuje spousta jazyků, kterým stačí pro modularitu jenom něco nakopírovat do složky a zavolat a akční a dynamické jsou taky a ani se nemusí nic předkompilovávat a aktualizovat JARka + dobrý debugger není jenom v javě. Ale tohle je asi jedno, hlavně aby v tom člověk uměl . . .
"Ano, ale to že ti to jede v javě, neznamená že ti to pojede jinde."
To je celkom zaujimave tvrdenie, neviem, ale co som sa ucil na vysokej a strednej skole algoritmizaciu, tak algoritmy boli jazykovo nezavisle. Je celkom vtipne tvrdit, ze co sa da v jazyku A, neda sa v jazyku B. Kedze turing-complete jazyky su vypoctovo ekvivalentne.
" Celé je to ale tím, že prototyp se dělá buď jako proof of concept, preview pro zákazníka, případně pro odhady náročnosti a časů nebo nějaká tato kombinace. Ne proto, že když to jede v javě, pojede to i jinde a když to neuděláš prvně v javě, tak to v ničem jiném normálně nepojede."
No java ma garantovane celkom slusne standardne api a memory management, typovu bezpecnost, takze je to velmi vhodny jazyk na prototypovanie. Bohuzial sa mi stalo uz, ze prototypy isli do produkcie, ale napriek tomu to bezalo slusne.
"To je celkom zaujimave tvrdenie, neviem, ale co som sa ucil na vysokej a strednej skole algoritmizaciu"
Ano, ale ty jsi mlluvil o prototypu v javě, ne o algoritmu v nějakém návrhu nebo pseudokódu.
"No java ma garantovane celkom slusne standardne api a memory management, typovu bezpecnost, takze je to velmi vhodny jazyk na prototypovanie . . . "
No proč ne? Klidně. Asi bude záležet co je to za úlohou. Třeba když jsem minule potřeboval ověřit nějaké stahování podkladů s reg výrazem, tak jsem s výhodou použil 1 php script - bez zájmu o "memory management, typovu bezpecnost", kompilace (nebo jak se to v javě přesně jmenuje), atd - a rychlým přístupem do databáze a soustředil jsem se pohodlně jenom na ten reg. výraz.
"Ano, ale ty jsi mlluvil o prototypu v javě, ne o algoritmu v nějakém návrhu nebo pseudokódu."
Zmysel prototypu je nieco nahodit, a po niekolkych iteraciach sa dopracovat k rieseniu. Ano, je pekne navrhovat na papier, ale papier znesie vsetko. Z toho dovodu sa robi prototyp, ktory umoznuje navrh efektivne upravit. Ak je prototyp dostatocne kvalitny, pouzije sa, inac sa zahodi a reimplementuje sa nanovo. Nie vsetko sa podari hned, niekedy treba spravit viac iteracii.
Casy, ked sa chodilo podla vodopadoveho modelu su davno prec.
Nema to nahodou take neco spolecneho s tim, ze MS Visual Studio zacina byt pekny paskvil? Posledni verze je tragicky pomala, navic MS obcas neco zmeni, takze nekdy neco nejde buildnout, pripadne tam treba prilinkuje profiling, ktery vola servery microsoftu (z 3rd party aplikace !!!), apod.
Nedavno jsem zkousel prelozit jeden nas projekt pod poslednim Visual C++ a musel jsem asi 2 hodiny opravovat kod, ve smyslu zmizelych POSIX funkci (prejmenovany na _jmenofce) a ruznych dalsich zmen, kdy neco proste ponovu nejde prelozit a clovek nad tim jen krouti hlavou. Ano, pozapinal jsem vsechny mozne pragmy aby to bylo co nejkompatibilnejsi s legacy kodem, zjevne to je problem co trapi mnoho lidi.
HelloWorld bych moc neresil, i kdyz cosi to take rika. Kazdopadne "mensi" projekt ze starsiho VS ktery mel cca 150MB ma po konverzi a kompilaci v novem hodne pres 500MB, mozna to bylo dokonce 700MB. Delaji to nejake ladici informace. Projekt se samozrejme cleanoval pred nabobtnanim, takze ne - neni to tim, ze by tam zustal bordel z predchozi verze.
pro windows nativní MiKTeX má ten musixtex taky, když by to bylo náhodou potřeba
http://miktex.org/packages/musixtex
Ty .msi balíčky mají digitální podpisy. Resp. je mít můžou, a není dobrý nápad instalovat z nepodepsaných balíčků.
Instalace z repozitáře je fajn, ale problém je v tom, že v něm najdete jen to co vám autor distra připraví. A většinu věcí, které opravdu stojí za to instalovat, v repozitáři distra nenajdete. Zkuste si v něm najít Oracle 12c (ne ořezanou Express edici), Siebel, Dassault Systemes CATIA, Adobe Photoshop, nebo třeba jen české účetnictví a mzdy. V lepším případě budete hledat "trapné" balíčky pro vaší verzi vašeho distra na webu výrobce. V horším případě dojde na tarball a kompilaci, nebo daný produkt vůbec není k dispozici. Takže repozitář vašeho distra je nakonec jen sbírka freewaru. A takových se po netu válí spousta: softpedia.com, download.cnet.com, en.softonic.com a řada dalších.
Vzpomínám, že před lety mi tady lidé říkali, že Windows je z dlouhodobého hlediska odepsaný, protože má špatnou (zastaralou, neflexibilní, atd) architekturu. No a teď na Windows běží nemodifikované linuxí aplikace, a přitom jsme neslyšeli, že by kvůli toho museli převrátit Windows naruby.
odepsanej system se chyta stebla no a ? :) ty linux aplikace umoznuuje jen v terminalu, naprotii tomu GNU/Linux ma podobnej subsystem WINE, take nebylo potreba Linux prevracet naruby a dokonce WINE pousti i nemodifikovane Windwos apliakce co pouzivaji graficke rozhrani, neni tak problem pustit narocne nemodifikovane Windows aplikace (Adobe Photoshop, MS Office) nebo hry...
btw: jeste si zapomel ze Windows 10 jsou prulomove, protoe "Prikazovy radek" podporuje ANSI barvicky, nebo ze pri maximalnizaci se uz maxializuje a ne ze se natahne na vejsku ale stahne na sirku.... ze mu to ale drvalo par desetileti.. to je detail ze? :-D