Koji operativni sistem je najbolji?

[Dersu Uzala]

A Windows kaska za MAC-OS-om i kopira isti od starta; a MAC-OS je, gle cuda, takodje *nix (UNIX-like) OS. Sta cemo sad?

 

Linus je ako me secanje ne vara napisao nekih 5% koda koji su dospeli u moderni, danasnji Linux kernel. Ostalo je izbaceno/promenjeno. Pri tome je on pokrao sve koncepte iz MINIX-a, Linux mu je kao neki studentski rad. U razvojnom smislu, mnogo je bitniji taj Tenenbaum, kako li se vec speluje, tvorac MINIX-a i mnogi drugi pre Torvaldsa, koji nije nista drugo neko 'relativno neuspesan' Bill Gates. Uzeo je tudj produkt, furao ga kao svoj jedno vreme, zdipio kintu za neka 'autorska prava' i otisao u legendu (kako za koga).

 

 

Mac-OS, ako mislis na onaj prvi, 'klasican', je baziran na privatnoj (proprietary) tehnologiji koja nema nikakve dodirne tacke sa Unixom i slicnim sistemima. Mac OSX je s druge strane baziran na NeXTSTEP OS-u koji je baziran na Mach kernelu i besplatnim BSD softverskim bibliotekama, uglavnom za ulazno/izlazne operacije. Mach kernel je opet baziran na Accent kernelu ali to je druga prica. Mach kernel je 'drop-in' zamena za stari Unix kernel ali radi bitno drukcije i podrzava IPC (Inter-Process-Communication) i RPC (Remote Procedure Call) sisteme za prenos poruka izmedju aplikacija, i aplikacija i sistema. Takvi sistemi, za razliku od originalnih Nixova koriste deljenu memoriju i portove za prenos poruka. Kod Nixova je sve bio fajl ali su i oni danas apgrejdovani. Inace Mac OSX ne koristi taj Mach kernel na kome je NeXtSTEP baziran, oni su otkupili neki treci kernel koji se zove XNU (skracenica od 'X is Not Unix). Ne zezam se.

 

I XNU je hibridan kernel kao i Windows kernel, znaci kombinovan mikro i monolitni kernel.

 

 

[Dersu Uzala]

Zato sto je doticni OS najrasprostranjeniji na planeti-sto je logicno

Nema to nikakve veze sa "standardizacijom" i nepostojanjem Visual Studio-a vec sa time sto se velikim(i malim)kompanijma koje prave softver ne isplati(jos uvek)da svoje pulene izdaju i za linux koji nema jos uvek dovoljan market share da bi ulozeno krenuo da se obrce

Da kojim slucajem Linux drzi jedno 20% market share-a za njega bi postojale sve(ili najmanju ruku veci deo)aplikacija kao i za Windoze

 

 

O ovome zasto je doticni narasprostranjeniji se sve zna, ali ajmo ponovo.

 

Imaginos je i ovoga puta u pravu (dokle bre ako Boga znades), aplikacije I standardizacija su dovele Windows u trenutnu poziciju, sto ce reci de fakto najrasprostranjeniju OS platformu na planeti Zemlji.

 

Kako?

 

Evo ovako. Kad se rodio Windows 1.0, nije postojala ni jedna jedina 3rd party aplikacija za njega. Stavise ni Microsoft nije ship-ovao ne znam kakve aplikacije sa istim. Notepad i tako to. Office jos nije postojao. Mislim da je bila neka prva verzija Word-a, mozda i Excela, ili je to bilo oko Windows verzije 2.0, ne secam se vise. Uglavnom, sijaset nekih Control Panel apleta (CPL), podrska za mrezu (ubitacan Novell IPX/SPX, kasnije sa famoznim NetBEUI i slicnim marifetlucima). Vrlo siromasno sve u svemu, iz prostog razloga sto u to vreme nije bilo toliko programera kao danas, pogotovu ne C i asemblerskih programera u kojim su prve verzije Prozora napisane.

 

U to vreme, ranih osamdesetih, postojao je DOS i niz drugih alternativa. Postojalo je par komercijalnih poslovnih i drugih aplikacija za DOS, neke od poznatijih su VisiCalc, SideKick i AMI Pro. Stavise mnoge od tih aplikacija su pravljene po uzoru na postojece aplikacije sa drugih sistema ukljucujuci i Atari i Amiga masine. Na zalost, Atari i Amiga su imali jako slabu prodju u Americi u to vreme, i vecina aplikativnih programera se i dalje bavilo statijaznam COBOL-om, FORTRAN-om pod mainframe i mini racunarskim okruzenjima. Ej, to je tada bila kevanija i pri tome portabilan kod. uzmes COBOL ili FORTRAN program, zviznes ga kroz drugi kompajler napravljen da kompajlira za dati procesor i voila. Radi. Malo je vise zezanja bilo oko ulazno-izlaznih operacija ali se to prekrpi (IBM SUPERZAP-om recimo).

 

Elem, tog dana kad je izasao Windows, imao je kao i Linux svojevremeno 0% trzista. Sta sad? MS je vec radio i na verziji 2.0 i sta sve ne, ali dzaba ako se to ne prodaje. A sto bi se prodavalo kad sem sto lepo izgleda ne radi ama bas nista. Mozes da blenes u system clock par sati, kao jeee, igras se sa font menadzerom (cca pet-sest, ima se moze se) i slicne nebuloze.

 

Jednog dana, Bill sedeo u kadi i padne mu na pamet Eureka. Umesto da se MS cima oko aplikacija, a vec su imali sijaset u povoju, loptu prebaciti na drugu polovinu terena, komercijalnim programerima, hobistima, zenama, deci, svima.

 

Postojao je medjutim stanoviti problemcic. Niko ne zna da programira u asembleru i C-u sem sistemskih inzenjera. Koji vec rade za MS i ove druge firme. Malo je programera i inace. Na zalost, Windows je tako sazdan, da si u startu mogao samo da se udenes u njegovu vecnu DO/WHILE petlju po vrlo strogim pravilima igre. Prvo, posto iskusni aplikativni programeri nisu bili u fazonu da opet uce neke nove kerefeke hvala lepo, trebalo je nauciti buduce programere sta je to 'message oriented event driven' sistem. Za masu programera novitet, u poredjenju sa sekvencijalnim pristupom...program pita nesto, pa radi nesto, pa pita nesto, pa radi nesto, pa pita nesto, pa radi nesto, pa pita nesto. Sta bre ako nisam tu? Preko noci, biznis ne moze da ceka...nocne smene su kostale firme ihaha. I tome se dohakalo preko batch datoteka ali nije to jedina poenta.

 

Dalje, kad jednom i savladas taj pristup, jedino mos' da programiras program za Windows u asembleru i C/C++. Postojala je Mikromekana DOS igracka koja se zvase Mikromekani Profesionalni Razvojni Sistem (Professional Development System). Zvuci, a?

 

Nesto kao Visual Studio danas, s tim sto je sljakalo pod DOS-om i imalo ugradjeni text editor, kompajler i linker za C/C++ i MacroAssembler (obican brate asembler gde mozes da kreiras makro instrukcije kao funkcije, dajes im imena mesto da pamtis na kojoj adresi ti pocinje memorijska matrica nekog string-a. S-u-l-u-d-o narode, suludo. Nikako ne smemo zaboraviti ni prvobitnu verziju SDK (Software Development Kit-a) za Windows, gde je more C i asemblerskih rutina, i ti brale crtas po ekranu samo tako, saljes nesto na I/O, u fajl sistem, te stvari. To otprilike radi ovako: startujes makinu, udjes u DOS prompt(no), otkucas PDS i on lansira isti. BANG i otvori se text editor, haha...nije bas edlin, viselinijski, onako lep i plav ali si mogao (ako si car i imas EGA/VGA karticu) da vidis pojedine stvari i u boji, dakako. Stavise, kada se malo kasnije pojavio interaktivni simbolicki debugger u PDS-u, o Mojsije, mogao si da koristis dva monitora, preko dve kartice, jedna svakako monohromatska a druga ili EGA ili VGA. Zasto, zato sto BIOS-i u tim karticama imadose fiksne adrese koje su mapirane u sistemski memorijski prostor i Hercules/mono bese na &B800 a ove druge na &C800 ako me sjecanje ne vara. Da ne bi bilo kolizije. Kad si napisao ponos i diku, nazad u DOS, startuj linker da poveze to tvoje programce sa dinamickim bibliotekama (ako nisi jadan importovao ceo njihov source kod i napravio program od 120kb koji sve sto radi kaze 'Hello World' ali bilo je i toga). Komandne linije od dva tri reda. Onda kresnes Win, pronadjes diku tamo gde si ga ostavio, File...Run (oli double-click) i ako se ista desi dobro je. Obicno se desi blue screen of death kad si jos omladinac. Sta zna omladinac sta je DLL entry point... Interaktivni simbolicki debugger (onaj sto pored asemblera i stanja svih registara prikazuje i izvorni kod, da ne kazem source simbole) sa dva monitora...mirikl. Napises asemblerski program koji crta kvadrat i to jednakostranicni, i pritiskas F11 a on docrta po jedan piksel u tvoj kvadrat. Posle ga ofarbas, pa ga farbas s leva nadesno, obrnuto, odozgo na gore, dijagonalno, koncentricno, i generalno osecas se kao baja. Mnogi koncepti bivaju jasniji.

 

Digresiram...situacija je krenula na bolje, sve vise ljudi se zainteresovalo, izlaze tu i tamo koliko-toliko korisni (i isto toliko stabilni) 3rd party programi. U isto vreme, dosta korisnika se vec navuklo na ISAM (Index Sequential Acces Method) baze podataka, dosta je bilo vise text-fajlova, a i spori su za citanje i pisanje. Prvo Btrieve potom razni drugi, dBase, FoxBase, DataFlex i raja se navukla, biznis ne moze da zivi bez kojekakvih baza. Mikromekani se dosetise jadu i promptno pazarise FoxBase i preimenovase u FoxPro sa cuvenom Rushmore tehnologijom upita. Trebace. To je bilo kompletno okurezenje za pisanje baza podataka sa sve sovjim jezikom, vrlo slicnim dBase-u. Kasnije su smislili MS Access, licencirali Sybase-ovu tehnologiju i prekrstili u SQL Server. Dodali VB kao opciju (Bill-u je uvek lezao BASIC na srcu). VB je vec bio pun pogodak. Najvise je nekako bilo BASIC programera u to vreme, a i najlaksi je za pocetnike, znaci za regrutovanje armije. Mnoge stvari nisi mogao da odradis u VB-u u poredjenju sa C/C++, ali si mogao da napises vrlo obimne i efikasne aplikacije koje nisu krahirale u toj meri jer ti mnoge stvari koje bi mogle da naruse stabilnost sistema jednostavno nisu dostupne. Bar ne u pocetku, posle je i to omoguceno i opet pocese da padaju mnogi programi i vuku za sobom sistem.

 

Sve to vreme Mikromekani su skontali da tim trecepozivcima (3rd party) treba maksimalna podrska, inace sto bi se oni cimali. Dan danas MS ima daleko najbolju podrsku za developere. Daleko. Daleeeeeeeko. Poceli su jos na Compuservu, delili savete, besplatan kod i primere, odgovarali na pitanja. To je preraslo u MSDN (Microsoft Developer Network). Akademiji su poceli i oni da dele besplatan softver i to cine dan danas. Stavise danas dele besplatno alate za razvoj svima (one Express verzije). Get your feet wet, pa ako ti ide i prodas neko znanje, od tih para kupis profi verzije i naplacujes usluge jos skuplje.

 

Njihov sajt je jos pre par godina generisao nekih 3 miliona stranica, tog reda velicine. 3 miliona stranica informacija kako se to radi. Nije sala.

 

U toku citavog tog perioda, kako Daemon navede, smisljali su nove, bolje standarde, pa onda ko u korpu za djubre, pa nove jos bolje. Ili su mozda trebali da ostanu na DDE (Dynamic Data Exchange). Njihovi koncepti su 'bleeding edge', jer prate sta se desava i po najvecim firmama, i onim najmanjim. I po akademiji. Ugraditi sve te opcije u jedan OS je pomalo pretenciozno i zato sistem mora da bude scalable, srazmeran, da moze da se izbaci sve sto ne treba i po potrebi ubaci nazad kad zatreba. To sto khm-khm povremeno igraju neke monopolisticke igre...pa monopol su bili sve ove godine.

 

Da rezimiram, nije ovde mesto ni vreme da detaljisem sve te MS tehnologije i zasto je neka novija bolja od neke starije, poenta je da nikad ne spavaju. I sve sto im je u koristi prenesu raji. Nije im sve u koristi da prenesu jer bi onda nekakav Linus seo i pokrao ih i potpisao to 'Lindows'. A brate i posteno su platili sve ove likove koji su im smislili sve te tehnologije, sto sad da dele bas svo znanje dzaba. Plati pa klati, ej pa i Unix System V je kostao 25,000$ licenca (sa izvornim kodom i manualima metar i po visokim). Pupin je toliko platio '87. I mogao si da ga preinacis do mile volje za internu upotrebu ali nisi mogao da ga tako preinacenog prodajes sve da je i bolji od originala. Zna se sta je red.

 

Bottom line, sto kazu Ameri, toliko je programera radilo aplikacije za Windows, cak i razvojne alate za Windows koji eto nisu Mikrosoftovi, da si mogao da fino programiras do mile volje i stoga hiljade i hiljade (mislim da je napisano preko 100,000 komercijalnih) Windows aplikacija. Kad imas toliko aplikacija, onda se vise ni ne postavlja pitanje dobavljanja Windows-a.

 

Pametni ili ako hoces poslovni ljudi se prvo raspitaju za aplikacije, sve sto im treba za biznis i kad ih izaberu jer im rade posao i culi su da jebu kevu, svi ih koriste, moci ce da opste elektronski sa drugim biznisima, onda se pitanje platforme ni ne postavlja. Sve imaju Windows logo, prema tome rade na istom prema tome, davaj. To su ti razlozi zasto je Windows Numero Uno.

 

 

 

Ruku na srce, vec sam to spomenuo na drugom mestu, kad Linux distributeri i ostala bratija zaintrigiraju 3rd party programere da mu posvete vise vremena, tako sto ce distribuirati bolje alate i mocnija okruzenja, i Linux i ti drugi sistemi ce postati mnogo znacajniji igraci u toj nekoj globalnoj igri. To se vec i desava, i postoje znacajni pomaci i u standardizaciji (oksimoron kad je u pitanju Linux jer se stice utisak da svi beze od standardizacija) i u razvoju tih mocnih paketa od strane mocnih softverskih kuca. Ali kaskaju nekih 5-7 godina iza Mikrosofta, a to su svetlosne godine u ovoj industriji. U stvari je Mikrosoft taj, kao poslednjih godina IBM (ali da li samo da naude Mikrosoftu) koji bi trebalo da otvori neke stvari i napravi ih dostupnim drugim trzistima i tehnologijama, preko naravno razumnih licenci. Jer vecina .NET programera koje bar ja znam recimo zele da im se aplikacije izvrsavaju i na Linuxu, transparentno. Znaci Mono projekat. Ali Mono je 'otkupio' Novell pokusavajuci da se digne iz mrtvih. I sad ako ti ja dam tehnologiju, hoce li mi se to sutra olupati o glavu nekako? Hoces li ti ili neko drugi zloupotrebiti moju sopstvenu tehnologiju protiv mene? Retoricko pitanje, ne mislim ni na koga sa foruma, eh.

 

Znaci ovako stoje stvari:

 

1) Napravis kick ass OS sa jako sexy ugradjenim tehnologijama

2) Napravis jako sexy alate za razvijanje na istom (ej, i tvoji programeri In Da House ce to ceniti, ti isti koji crnce da napisu taj OS)

3) Napravis suludu podrsku za te razvojne alate.

4) Napravis i komercijalne aplikacije u kojima zelis da dominiras i za koje znas da trebaju biznisima (po mogucstvu velikim) ko lebac.

5) Sve sto ne napravis ti, napravi ti armija od 3-4 miliona programera sirom sveta ( a Windows programera ima tu negde ako ne i vise)

6) Odjednom krene da se prodaje OS ko alva.

7) Sad stvari krecu obrnuto...

8) Posto ti se OS prodaje ko alva normalno je da ima sve vise aplikacija za tvoj OS

9) A da bi se te iste aplikacije, u jos lepsem i novijem ruhu nekako zbudzile, prodaje se jos vise (novih) verzija tvojih (i tudjih) jako sexy razvojnih alata.

10) Pravis jos jacu verziju OS-a u nadi da ce se jos bolje prodavati...

11) A za razvoj na istom su potrebni jos vise sexy razvojni alati

.

.

.

 

 

 

 

Prosto.

 

 

Nego, ne znam da li sam dovoljno argumentovao?

 

[Dawn Daemon]

Kako i navedoh u prethodnom postu, JAva kao jezicka specifikacija sasvim lepo radi kad je kompajlirana u objektni kod, bilo preko prekompajlera bilo preko JIT (Just-In-Time) kompajlera. Java bytecode interpreter je ona druga, katastrofalna prica.

 

SUN Java i IBM Java su JIT. O cemu onda tacno pricas? Koji se to bytecode interpreter koristi ovih dana za Javu?

 

I sad komentarisanje C je native, nije posteno da se porede JIT i prekompajlirani i slicno... Prica je bila o tome kako C (ne JIT C) radi mnoooogo brze od Jave, bla, bla, truc, truc (da citiram Hendriksa )

Edited May 20, 2008 by Dawn Daemon

[Dersu Uzala]

Ne verujem da iko vise koristi bytecode interpreter. Taj interpreter je bio los glas. Ali sa druge strane kako rekoh, nije fer da onda porede neki gcc C prekompajler sa komercijalnim stejt-of-di-art Java JIT kompajlerom.

 

Drugo, treba pronaci set nekih zajednickih testova za tehnologije koje se testiraju. Java ne podrzava pointere ali ima GC. C/C++ kad nisu menadovan (.NET) kod, obrnuto. Onda merimo babe i zabe. Medjutim cak i kad bi prihvatili takvo resenje, postavlja se pitanje koliko je i to relevantno jer ti kao programer mozes da pronadjes alternativno resenje u Javi da odradis isti posao kao u C/C++. I obrnuto. Kao sto je i ukazano u clanku.

 

Edit: u stvari pitanje je koliko je onog starog byte-code interpetiranog koda portovano na JIT platformu. To kosta. Ali verujem da svako ko ima imalo mozga i nesto kinte radi na tome ako vec nije odradio. Inace, postoji jedan program koji koristi Sun-ovu JVM i koristio sam ga jedno vreme. To je program koji su napisali Entetainment Partners i koriste ga svi Holivudski studiji. Zove se Movie Magic. Katastrofalne performanse. Tragedija. UI, tojest windowing system pogotovu. Da nije tragicno bilo bi komicno. Mi smo bili napisali konkurentsku verziju (koju i danas imam ali nije komercijalno prodata jos) koja radi 4-5 puta brze. Po onoj 'user perceived speed'. A da, u C++/MFC/SQL Server/IIS/XML/SOAP

Edited May 20, 2008 by Odliveni Mozak

[Dawn Daemon]

Ok, ko je zapoceo pricu na temu 'java je spora', i ko je podrzao tu pricu, kad je to 'merenje baba i zaba'?

[Dersu Uzala]

Ne'am pojma. Nije ni bitno. zgodna je za mnoge stvari i moja prva ljubav od ovih OO jezika (Smalltalk ne mogu da svarim organski, iako je u stvari majka Mara). Nego, bejahu kazem i nativni, alo nativni kompajleri (prekompajleri) za Javu. Pogodi ko je pravio jedan od njih? Prekompajler je doduse pomalo pogresan termin jer je prekompilacija proces kod nativne kompilacije, ali sad sta da se radi.

Edited May 20, 2008 by Odliveni Mozak

[niking]

da li iams ikakav link za Movie magic Budgeting i Scheduling?

[Dersu Uzala]

www.entertainmentpartners.com

 

Ove nove verzije su Java (EP Budgeting & EP Scheduling). Stare verzije su pisane u C-u sa CodeWarrior-om.

 

 

-----------------------------------

 

 

Interesantno stivo:

 

 

The Tragedy of Microsoft and Java

by Howard Gilbert

Technology and Planning, Yale University

05 Feb, 2003

 

It could have been worse, but then they would have had to hire more lawyers.

 

Each Java program runs in an environment called the "Java Virtual Machine". As the name suggests, the JVM creates a special environment isolated from the rest of the operating system. Sun regards this isolation as a feature. It preserves the purity of Java and ensures that Java programs cannot become dependent on features available in only one operating system. However, Java programs also cannot communicate with programs running outside the JVM.

 

There is an exception to the isolation. The Java 2 Extended Edition (J2EE) standard defines a special Java environment hosted by a Application Server that becomes a "container" for network services implemented in Java. A particular type of Java class, the "Enterprise Java Bean" (EJB) exposes services and data that can be accessed by other programs running on the same machine or elsewhere in the network. Other Java programs can call the EJB through a Java-only service called RMI. Applications written in other programming languages use CORBA.

 

Now suppose that someone created an standard JVM that could turn any Java class into an EJB just by adding a comment to the source file. Not a big expensive Application Server that costs tens of thousands of dollars, but an ordinary Java runtime that runs ordinary applications and is given away free to everyone. Any program written in any language could call Java code for services, and Java code could easily call other programs on the same or on other machines in the network. Suppose they did it back in 1998, back before there was a Java 2 let alone an Extended Edition.

 

That is what Microsoft did. In early 1996 they signed an agreement with Sun and began a large scale investment of money and manpower to create what they regarded as the best Java development and execution environment possible. However, Microsoft's view of that environment was different from Sun's view. Microsoft wanted Java to be the most powerful language possible. Certainly the people working on Microsoft Java (if not those working on Visual Basic) wanted Java to be the best language for developing Windows applications. To achieve that they made modifications to the JVM that anticipated some of the ideas Sun would later apply to J2EE. However, Microsoft based its design on the standards it had already adopted for all its other products. Thus the Microsoft JVM communicated to other programs using COM instead of CORBA.

 

This made Sun angry. Sun wanted to retain control over Java and had philosophical disagreements over the direction of the Microsoft changes. Initially, Sun came to the table with a fully implemented compiler (written itself in Java), a runtime environment (the Java Virtual Machine or JVM), and a set of class libraries. Sun wanted to leverage its copyright ownership of this initial bundle of code to force compatibility of all versions of Java running on all systems.

 

Copyright protects an expression of an idea but not the idea itself. If the behavior of a language can be completely described, nothing in the law will prevent someone else from creating an independent implementation of the language and possibly alternate versions. In practice, however, the large and inadequately documented Class library posed a more serious problem than the language itself. Sun expected that Microsoft would be stuck optimizing the speed of the runtime system while Sun could control the content of the Class libraries that really shaped the language.

 

By bridging the closed Java runtime environment to the rest of the operating system, Microsoft had completely upset that calculation. With the Microsoft tools, a developer could turn Word, Excel, or Media Player into what appeared to be a Java Class. Microsoft had make Java a powerful Windows development language, but that was not what Sun had in mind. Rather than accept the evolutionary change, Sun went to court.

 

Ownership

Nobody has ever tried to assert ownership of a programming language. Most programming languages have an original inventor: FORTRAN (Backus), COBOL (Hopper), APL (Iverson), LISP (McCarthy), BASIC (Kemeny), Pascal (Wirth), C (Ritchie), C++ (Stroustrup). Once the language is launched, however, others are free to build on it and create new variations.

 

The strongest attempt to control a language was the Department of Defense management of Ada. They developed an independent battery of compatibility tests and a certification program. The purpose was to insure that previously developed Ada components could be reused on new systems and hardware. Nobody could add extensions to the Ada language, but the only enforcement mechanism was to drop certification and prohibit the use of the registered trademark name "Ada" on the result. So, for example, the Oracle programming language PL/SQL could be based on Ada as long as it didn't use the name.

 

Sun also trademarked the name "Java" as it applied to programming languages. This did not effect Microsoft as long as it called its languages J++ or J#. As to whether Sun had more control over Microsoft's development, that depended on how you read the contract.

 

History

In March, 1996 Microsoft and Sun signed a five year license agreement. Under this agreement Microsoft was allowed to distribute the Sun compiler, runtime, and class libraries and to create new code based on and incorporating Sun copyrighted material. Sun required any new Microsoft code to pass compatibility tests to insure that standard Java programs would run on the Microsoft platform. Periodically Sun could provide new versions of Java and corresponding new compatibility tests.

 

Java 1.0 was essentially a Beta release. Based on testing and feedback, Sun made some important changes to the language (inner classes, Reader and Writer I/O, reflection, RMI, JavaBeans, and a completely new Native Interface) and brought out Java 1.1.

 

Microsoft also updated its Java runtime and tools to support both the structural changes to the language (such as inner classes) and the changes to the class libraries. Nobody doubts that Microsoft's Java runtime fully and compatibly supported the execution of Java 1.1 programs. However, Microsoft claimed that it was not required to ship every new feature that Sun wanted to add to the class library.

 

The problems with Java 1.0 had been clear to everyone. While Sun was busy fixing these problems one way, Microsoft had solved some of them a different way. Whether it was allowed to do that or not depended on how you read the contract. What was certainly clear is that Microsoft and Sun had completely different views of the future of Java.

 

Microsoft regarded Java as just another programming language. It was more sophisticated (with integrated threading and networking) than Visual Basic, yet easier to learn and use than C++. Microsoft expected Java to join the other programming languages in the developer's tool bag. Since the value of any language was determined by the domain of applications it could tackle, Microsoft wanted to make Java the most powerful and flexible language it could be.

Sun, on the other hand, began to regard Java as an application programming platform that would replace all other programming languages and even some operating systems. The original slogan had been "Write once, run anywhere." Over time this drifted into having a second meaning, "Run anywhere, run everywhere." Sun did not want Java to be any more powerful on Windows than it was on all other systems.

If Microsoft had let the conflict develop slowly and naturally, the outcome might have been different. Instead, a few managers decided to pick a fight with Sun. They decided to omit the class libraries for Remote Method Invocation (RMI) and to disable generation of output for the new version of the Java Native Interface (JNI). A customer could not use RMI to communicate between Java programs on Windows and Unix. Similarly, a C language program written to extend Java would not operate correctly in the Microsoft environment.

 

Microsoft could argue that it provided other ways to do the same things. That might be a reasonable defense if Microsoft had been required to do some work to convert these things to Windows. Instead, it was clear that Microsoft had directed its effort to remove features that Sun provided in working form. When the courts ordered Microsoft to restore these features, it took only a week to add them back in.

 

The legal outcome of the subsequent court cases would have been different if Sun only objected to additional useful features added by Microsoft. Instead, the decision by a few managers to intentionally cripple features in their own product also undermined several years of work by dedicated Microsoft programmers. Once the courts uncovered cases of obvious anticompetitive behavior, they were inclined to imagine further problems where none really existed.

 

In retrospect, the most serious mistake made by both companies was to not include an arbitration clause in the 1996 license agreement. The remedy described in the contract was for either side to claim money damages in "a court of competent jurisdiction." Given that the license ran for only five years, and subsequent events show that it takes about five years to bring a case to trial, the courts did not provide an adequate forum for the resolution of any dispute over terms. Instead, the recent history of computer industry litigation has shown that, in the Federal Court system, the term "competent jurisdiction" is an oxymoron.

 

Sun went into Federal court claiming broad copyright control over every aspect of Java. The courts pointed out that Sun had granted Microsoft a license to use its material and that this was a dispute over that contract. So Sun then claimed that its intent under the contract was to preclude Microsoft from doing anything with Java of which Sun did not approve. Some injunctions issued in November 1998 essentially froze all Java development inside Microsoft. The case then dragged on for three years without ever coming to trial. By then, the five year license agreement had expired.

 

Microsoft accepted defeat from Sun's legal maneuvering. In Jan. 2001 it signed a second contract under which it paid Sun $20 million just to be able to continue to distribute its current version of Java long enough to give existing users a chance to convert to something else. Otherwise, Microsoft agreed to have nothing further to do with the Java platform, JVM, or class libraries.

 

Religious Differences

Starting with Version 1.2 ("Java 2"), Sun began to aggressively fill in standard class library interfaces to all the standard and most optional services supplied by an operating system. A Java program obtained database services through JDBC (whether the database was Oracle, DB2, or SQL Server), directory services from JNDI (whether the directory is generic LDAP, Active Directory, or Novell), Cryptography from JCE, and so on. The interfaces remained the same even if their implementation was different on various systems or devices.

 

Microsoft's COM strategy provided a different interface to most of the same services. COM services were available to and could be shared among components written in any language. For example, using the database service named "ADO" a Visual Basic program could select and connect to a database server. It could then pass this connection to a Perl program that would generate a SELECT statement to query the database. The results returned by the query could then be used by a Delphi program to draw conclusions.

 

Sun's lawyers would like to portray Microsoft as a greedy monopolist defending its iron fisted control of the computer industry from a new technological threat. The reality is quite different. There are some parallels between the Microsoft-Sun clash of cultures to the tensions faced by cohesive immigrant groups like Orthodox Jews or Moslems. On one side there is a secular, cosmopolitan melting pot culture that tolerates diversity, but only within a broad agreed set of shared values. Ethnic food is interesting, but we regard arranged marriages are "barbaric". Meanwhile the immigrant group imported a tight cultural and religious set of values that regards the larger secular community as decadent and insists on maintaining the purity of its separate existence.

 

Microsoft had adopted a strategy where each language could have its adherents and special features. Diversity was an important objective. Java, on the other hand, was intended to remain separate, retain its special integrity, and even advocated a slogan of "100% Pure." Each side could plausibly view its own position as enlightened. The first step in understanding the problem is not to impose your own bias and try to pass judgment on who is "right" and "wrong".

 

Component Architecture

Starting with COM and now extending to its .NET Framework, the Microsoft strategy has been to enable a "component architecture". A customer could write a block of code that performed a particular programming or business function in any language he chose. This component could then be stored in a library where it could be used by any other program written in any other language.

 

The most important programming done in corporate America today is not written in any generally recognized programming language. Financial projections and budget decisions are coded in spreadsheets that run under Excel. Load the spreadsheet, plug in some numbers, and the results appear magically in some specific rows and columns. Following traditional software engineering, a company is supposed to hire a systems analyst to convert the logic in the spreadsheet into a "real program" written in a "real programming language." However, if the spreadsheet is well written, an alternative strategy is to put it in a library and let other programs use it directly through services exposed by Excel.

 

Any programming language that has been adapted to COM, including Borland Delphi or ActiveState Perl, can ask Windows to load a copy of Excel as a COM server. It can then ask Excel to load a specific spreadsheet file, then to plug values into specific cells, then recalculate results, and finally report back the new value in other cells.

 

Data in the COM environment is logically shared by all the components written in all the languages. For example, Excel could be loaded by Visual Basic, a Delphi program could then calculate one value and plug it into a specific cell, a Perl program could calculate another value and plug it into a different cell, and the results could be extracted and used by JavaScript logic.

 

When Microsoft licensed Java from Sun, its highest priority was to integrate Java into its overall component architecture. If Microsoft had not done this, it would have essentially been abandoning its entire strategy for future product development. Asking Microsoft to abandon COM (and its successor, the .NET Framework) would be like asking Sun to abandon Unix.

 

To allow Java to participate in this common environment, Microsoft had to make some extensions to Java. Most of the extensions where hidden in comment fields that any other Java compiler would ignore. However, Windows required a different approach to event handling that could only be accomplished with a new keyword, "delegate", that created a special type of class.

 

And 100% Pure Java program that worked on any other version of Java 1.1 also ran on Microsoft's Java. Microsoft did allow someone to write a Java program that only ran on Windows, but this only appeared to be a compatibility problem. Programs that add users or groups to Active Directory or automate the Mail Merge function in Word were only going to run in Windows anyway. Microsoft allowed these programs to be written in Java. Otherwise, the programs would have to be written in VB, Delphi, or JavaScript.

 

J(mumble)

Microsoft was still dedicated to a application development strategy based on components written in many programming languages. Legally, it was now prevented from making the Java platform part of that strategy. However, Microsoft was completely familiar with Java and was not prevented from borrowing any good ideas.

 

Most of the technologies in Java had been around for decades. "Intermediate language" was a feature of UCSD Pascal in the 1970s. Memory management through "garbage collection" was invented in the '50s. Java's contribution was to combine and use these technologies in a new way and demonstrate their ability to solve new problems introduced by the Internet and the Web.

 

Through COM, Microsoft allowed program components written in different languages to talk to each other. However, each language retained its own standard library and runtime support. When a program used a standard language service (write, writeln, put, print, println) it called a different library for each language.

 

Microsoft now proposed to do something radically different. It would start with the basic execution model of the Java Virtual Machine. It would extend that design to include all of the features included in any modern programming language. From this it would create a Common Language Runtime (CLR) that could support all programming languages from the same library. It would then make this specification public, so any other vendor could adapt their programming system to run in the new environment.

 

There are about 60 programming languages that have been adapted to produce Java bytecode and run in the Java Virtual Machine. Such conversions are hampered, however, by the Sun decision to limit its runtime support to the features that were defined in the Java language. For example, Java doesn't have unsigned byte or integer values. Any language whose standard requires bytes to be unsigned integers can't operate in the JVM. Microsoft's Common Language Runtime has all the data types defined by any language.

 

In converting to the CLR, some 1950's languages have to catch up to the new century. Now that every country in the world is interconnected by high speed networks, no programming language can afford to be stuck with plain US ASCII characters. All languages have to adapt to Unicode characters and adopt some level of sensitivity to internationalization.

 

The new Microsoft runtime is called the .NET Framework. Microsoft created versions of Visual Basic and JavaScript that ran in the Framework. It also created a compiler (called "J#", pronounced "J-Sharp") that accepted a program written in the Java syntax but generating output for the Framework instead of a JVM.

 

The .NET Framework and the Java Virtual Machine are two distinct runtime environments. This is what Sun demanded as settlement of its court case. They cannot communicate directly any more, as the old Microsoft JVM was able to do. Of course .NET and Java can exchange data and requests at the highest possible level through Web Services and XML, but that is relatively inefficient and must be reserved for low-volume traffic.

 

The Sandbox

Previous programming languages were compiled to machine instructions for a particular family of CPU chips. For Windows, the compiler would produce instructions for the Intel processor family (386, 486, Pentium). A compiler for the Macintosh would produce instructions for the PowerPC chip.

 

At the machine instruction level, each piece of data in the application is given an address. Different applications run in different "address spaces" so an application cannot access data belonging to the operating system or to another application. However, every library, language, or component that is part of the application shares a common area of data. A program can be written to calculate any or all possible addresses and therefore access any data belonging to any part of the application.

 

System services to open files or connect to network resources can be called by any routine. A conventional program is only limited by the permissions given to the userid under which the program is run.

 

Java programs, and programs written for the .NET Framwork, are not compiled to machine instructions. Instead, the compiler produces code in what is called an "intermediate language". For Java the intermediate language is called "byte code". In .NET it is called MSIL (pronounced "missile"). The program is packaged, distributed, and installed in intermediate language format. Only when it begins to execute does the runtime system translate the intermediate language into real machine instructions.

 

The structure of the intermediate language and the tests made during the final translation insure that the program is well behaved and only uses memory properly. In particular, a routine can only access data that belongs to it or to which it has been granted access by another routine. Programs cannot access arbitrary locations in memory, nor can they run off the end of an array, buffer, or string. If a routine declares data to be "private" it can reasonably expect that other routines will not be able to access the value of that data.

 

This architecture protects program components from each other and protects the system (or a generic hosting application like a browser or Web server) from even malicious code generated by a programmer. Programmers call this environment "the Sandbox" although it is sometimes referred to more accurately (though less sensitively) as "the Padded Cell".

 

The Native Interface

Intermediate language cannot contain calls to the operating system or to any other external service. A "100% Pure Java" program can only call other Java code in the class libraries.

 

Obviously there must be some way for the library classes to eventually call the operating system. In particular, the routines of the java.io.* package have to be able to open files, list directories, and read and write data on disk. The routines of the java.net.* package have to be able to connect to remote hosts and transmit data over the network. Pure Java cannot do this, so Java allows some routines to be implemented in C through the Java Native Interface or JNI.

 

To use JNI, a programmer creates just the signature of a Java function. The function has a name, return data type, and some number of declared arguments. Instead of coding the body of the function, the programmer just adds the keyword "native" to its declaration.

 

When the Java compiler encounters a "native" function, it generates an indication to the JVM that any call to the function should be routed to an external function written in C and stored in a particular DLL. Of course the programmer still has to write the C source. A Java utility processes the output of the compiler and from it generates the skeleton definition of the C program. The programmer must then fill in the skeleton with the actual code.

 

A "100% Pure Java" source file produces only an output *.class file. That file can be stored on disk or zipped up into a JAR archive. It can be installed on hard disk or be fetched on demand across the network. Because it contains only intermediate language, this code runs entirely in the Sandbox.

 

Any source file that includes "native" routines must eventually produce both a *.class file and a DLL. A DLL cannot be downloaded from a Web server. Generally the class file and DLL are both installed on hard disk and they may have to be put in special restricted directories. The DLL files that support standard Java library services (the file services of java.io and the network services of java.net for example) are distributed with the Sun Java runtime are are installed in the \jre\bin subdirectory of the Java install directory.

 

Since JNI starts with Java source, anything produced by this system is Java-friendly. A "native" routine accepts ordinary Java arguments with standard Java data types. This places the burden on the C implementation to translate between the Java data types and any other format the operating system expects to use. On Unix, for example, the Java Unicode String values must typically be converted to null terminated ASCII byte strings to be passed to the operating system, and return values may have to be translated back.

 

Java Isn't Everything

The people at Sun who designed Java came out of the Unix tradition. Unix has its own creation myth. In the 1960s Bell Labs got suckered into a project to create a vast new operating system called Multics. Multics was written in a powerful higher level language called PL/I that contains all the features of all previous languages. Similarly, the operating system was designed with all the features that anyone had ever considered putting in an OS. The resulting mess was too big, too slow, and unusable.

 

The refugees from this disaster regrouped and decided to create a smaller, simpler system. Instead of PL/I, they created a minimal programming language called C. While Multics had many ways to solve a problem, Unix would have only one option for any service you might need. This became the doctrine of "Less is More."

 

Unix was fine when it was used in the environment for which it was originally designed: timesharing on minicomputers. Being small and easy to understand, the core of Unix could also be easily adapted to any single new environment you wanted to support. The problem came after hundreds of separate simple extensions had been developed and people now wanted to integrate them all together. Slowly it became clear that some of the most basic architectural decisions made in Unix were short sighted. The designers at Bell Labs had specifically decided that Unix didn't need multithreading, but in the modern era of network based Web, application, and database servers it is clear that no system can perform properly without threads.

 

Paradoxically, the Unix philosophy "overdid" the idea of Less. The people who designed Java had not yet accepted this criticism. They still believed that "Less is More" was one of the Six Commandments, and that adding additional features to a language is one of the Four Deadly Sins.

 

Anyone is free to impose their personal aesthetics on a language. However, if you intend to claim that your language is the basis for all future computing, then you have to temper your personal preferences with a proper respect for the opinions of all the people who worked long and hard on previous computer languages. Once Sun developers created Java to their own idiosyncratic tastes, they have no right to expect everyone else to convert all programs to it.

 

The most obvious omission was unsigned integers. A more fundamental omission was the "enumeration". Its not just that enumerations are part of every language from Pascal through Ada to C++. They are also basic elements in language-independent interface definition and schema standards.

 

Since there is no direct way to map many existing industry standards into Java, the JNI was designed to put the burden on the other side. It doesn't start with the external standard. You have to start with Java source. You have to define the interface or format in a way that is friendly to Java, then figure out how to do the mapping. The burden is placed on the C code to translate between the external interface and the new Java version.

 

Sun regards this as a feature rather than a problem. The "write once, run anywhere" philosophy encourages anyone seeking to extend the Java programming language to ignore the idiosyncrasies of any particular operating system. Services should be defined in an idealized and Java-centric programming model, preferably beginning with the letter "J" (JDBC, JNDI, JAAS, JAXP). If this interface can only be implemented using native code, then ideally the same interface will be implemented on every operating system using appropriate code native to each system.

 

Automatic Extension on Demand

There are thousands of individual functions in the Windows programming interface, and an unlimited number of COM components. It would be prohibitively expensive to build custom interfaces to each service in advance. The strategy adopted by Microsoft in Visual Basic was to generate the equivalent of a "native" interface on demand for any particular system service or COM component the user might request.

 

The Java standard doesn't preclude automatic generation of native extensions. However, to do this with JNI, a tool would have to analyze the system interface or COM component, perform the mapping from external data types to Java data types, generate the Java source with the "native" keyword, compile it, generate the C source and compile it. If Microsoft had been willing to jump through all these hoops, Sun would have nothing to complain about.

 

However, Microsoft decided that its version of Java would meet everyone else half way. Most of the time the extensions that Microsoft created could be hidden as compiler directives that, from the point of view of Java syntax, were comments. Run through another Java compiler and they would be ignored.

 

However, Java has to be a bit more cooperative when it comes to "callbacks" and "event handling". In many cases the Java program must provide external software with more than parameters. It must also supply routines that the external code can call to signal events, indicate errors, or request additional instructions. Communication between components is a two way street. So Microsoft created a more flexible system in which Java itself had to give a little.

 

Data Structures

Every programming language has a feature that allows a block of related information to be packed together in a single program unit. In different languages these can be called structures, structs, or records. A Java class that contains only variable data fields (and no routines) is almost like a C struct, but it carries some additional baggage that makes it incompatible.

 

Consider the Windows routine GetSystemInfo. It passes back a SYSTEM_INFO data structure. Right now the most interesting variable in the structure is the number of CPUs (in a server or workstation that allows multiple CPUs). Another field in the structure will allow a program to distinguish a system using the new 64-bit Intel Itanium or AMD Opteron CPU chip from one using a conventional 32-bit Pentium or Athlon CPU.

 

/**

* @dll.struct()

*/

public static class SYSTEM_INFO {

public short wProcessorArchitecture;

public short wReserved;

public int dwPageSize;

public int lpMinimumApplicationAddress;

public int lpMaximumApplicationAddress;

public int dwActiveProcessorMask;

public int dwNumberOfProcessors;

public int dwProcessorType;

public int dwAllocationGranularity;

public short wProcessorLevel;

public short wProcessorRevision;

}

So Microsoft created a directive that would allow the compiler to create the same type of data structure used by other languages. The programmer creates a Java class that contains only data fields. In front of the class definition there is a comment statement with the special string "@dll.struct()". This tells the Microsoft compiler to generate a data structure without any of the usual Java object overhead. The program can create an instance of this object, use it to interact with the system, and access the value of the variable fields. It can also be passed as an argument to "native" routines that intend to pass it on, unmodified, to operating system routines that expect a C "struct".

 

Only the Microsoft compiler recognizes this directive. If this code is compiled on any other Java system, the SYSTEM_INFO structure is generated as an ordinary Java class. The program remains valid and produces correct Java. It is unlikely that this part of the program would be useful on other systems, however, because the SYSTEM_INFO structure is only meaningful on Windows.

 

DLL Functions

There already is a GetSystemInfo function in the Windows operating system. It is a C subroutine located in a system DLL. You could create a proper JNI routine to access it. However, once the Java program has created the data structures and types that the routine expects, it is possible to call it directly.

 

/**

* @dll.import("KERNEL32", auto)

*/

public static native void GetSystemInfo(SYSTEM_INFO lpSystemInfo);

This Java source defines a "native" routine called GetSystemInfo that is passed an instance of the SYSTEM_INFO class defined above. The "@dll.import" tells the Java compiler to automatically generate a "native" code linkage to an existing C routine in the KERNEL32.DLL library. The Java programmer doesn't have to run any utilities or write any custom C code. He doesn't even have to know C. The Microsoft compiler does all the work and links things up.

 

If this code is compiled by any other Java compiler, the comment is ignored. The "native" keyword tell the compiler to generate a JNI linkage. The class will not execute until some C language code is generated to resolve the native function.

 

The presence of compiler directives in the comments does not break Java language compatibility. It is unlikely that this code would ever be implemented on other systems, but that is because it calls a Windows system service that doesn't make sense on other systems.

 

Delegate

Over the last decade every Unix vendor has been adding multithreading to the original Unix design. Since threads were an afterthought, they are not part of the interface to any system service. Threads are rather light-weight and interchangeable. Within an application, each thread can do anything another thread can do.

 

Many resources have to be "serialized". This should not come as a surprise to Java programmers, since Java has always had a serialized attribute so that a block of code is executed by only one thread at a time.

 

An alternative design, which has been around since the earliest computer systems, is to assign certain blocks of data or system interfaces to the control of a single thread. If any other code running under a different thread needs access to the resource, it must ask the controlling thread to perform the operation and return the results. This is like asking the teller at the bank to withdraw money from your account rather than just walking into the vault and trying to do it yourself.

 

The original Windows architecture was influenced by a broad view of operating systems and not the narrow and ideological perspective of Unix. Threads were always a part of the Windows design, and it was natural to assign control of some system interfaces to particular threads. When a user interface window is created on the screen, ownership of the window is assigned to the thread that created it. It is up to that thread to populate the window with user interface elements (menus, toolbars, buttons, sliders, and text). If two different threads tried to add or remove user elements in the same window at the same time they could damage the interface. Furthermore, all events generated by user activity in the window (mouse clicks, key strokes) are processed by the thread that owns the window.

 

Similarly, the thread that creates a COM interface to an external component is responsible for all subsequent communication. So when a thread loads an external copy of Excel, only that thread can instruct Excel to load a spreadsheet, plug numbers into the cells, recalculate, and the return the results. [Athough paradoxically a second thread (or another program) can establish a second connection to the same copy of Excel loaded by the first thread. The two threads can concurrently transmit commands to Excel on the two connections. Each thread is still limited to using only the connection it created, even though both connections terminate at the same copy of Excel.]

 

In Java all objects are shared in common by all threads. A button on the user interface or a session to an external program are represented by objects that can be used by any thread. To avoid conflict, elements should be "synchronized" so only one thread uses them at a time.

 

The difference between the two system designs was not something that Microsoft could squeeze in with compiler directives hidden in a comment statement. This required a new keyword to create a new type of object.

 

In Microsoft Java, a "delegate" is a special type of object. The delegate is created by a thread and is associated with a routine that handles events. The delegate is then passed as the callback function or event handler in COM or Windows system services.

 

In Sun Java, an object waits for an event. The object has an event handling routine. When a thread comes along to signal the event, it calls the event handling routine itself. In human terms, it is as if a hotel guest walked up to the Bell Captain's desk looking for help with luggage, rang the bell (signaling the event), then changed into a bellhop uniform to put the luggage on the cart and carry it to the room, returned to the Bell Captain's desk, changed back to the original clothes, and then proceeded to the room as a guest.

 

Under Microsoft's extensions to Java, the delegate waits for the event. When the delegate is triggered, the calling thread is temporarily suspended while the event handling routine runs under the thread that created the delegate object. In this version of the previous example, the guest rings the bell. A bellhop (thread) waiting at the desk takes the luggage up to the room while the guest waits. The bellhop returns to the desk to wait for another request, and this releases the waiting guest to follow his luggage up to the room.

 

The idea that particular threads wait on events has been part of operating system designs since the first IBM mainframe operating systems in 1965. It was a basic feature of the multithreaded design of the Ada programming language. Only a narrow minded dedication to the philosophy of "Less is More" combined with the observation that Sun's own Solaris operating system doesn't need this feature can explain the omission of the delegate (or an equivalent concept) from the Java standard.

 

Variant

Java is a "strongly typed" and compiled language. The Java programmer declares the type of each variable. An integer variable can be assigned a value of 365, a floating point variable can be assigned 3.14159, and a String variable can be assigned the value "a priest, a barber, and a horse walk into a bar ..."

 

Other languages (notably JavaScript, REXX, and Perl) are weakly typed and interpreted. Any variable can be assigned any number or string value. The type of the value isn't checked until it is used. If it is used as a number, it better be a number or something that can be converted to one.

 

Excel spreadsheet cells are an obvious example of weak typing. You can enter numbers or text into a cell. Excel doesn't care if a cell has text as long as the cell ID is not used in the formula that calculates a value for another cell.

 

If Java is to interoperate through COM with these other languages and applications, then it needed a generic object that can hold all types of data. Microsoft added a Variant class it its library. A Variant is an Object that can contain values that are integer, float, string, or boolean. Such a structure is not unprecedented. JDBC ResultSet objects encapsulate the column variables returned from a query. Each column can be fetched in various formats (getInt, getLong, getDate, getString). Variants and the classes that support them serve no useful purpose for a pure Java program, but they help to bridge the gap between Java and the other languages that cannot make up their mind about how to treat data.

 

The Judges Just Don't Get It

Microsoft wanted Java to be the best possible language, as defined by its language architecture. Sun had a different point of view. The Sun perspective didn't become objectively the "right" criterion just because Sun invented Java, or because Microsoft has monopoly power in PC operating systems. Instead, both vendors are right.

 

The two versions of Java can be installed on any machine. They contain no conflicting components. You run the Sun compiler with "javac" and the Microsoft compiler with "jvc". You run a Java program under the Sun runtime with the "java" command and under the Microsoft runtime with the "jview" command. The decision to use one version of Java or the other is made application by application. The programmer may force a selection, or it may be left to the user who runs the program.

 

It is not, however, just a choice between Sun and Microsoft. Specific applications are distributed with a particular Java runtime because they have been designed for a particular configuration. A program may require JRE 1.3.1 or 1.4.0. IBM has its version of the Java runtime. Oracle distributes different versions of Java with the database, application server, and application clients.

 

All of these versions of Java are "right" for a user who needs that particular collection of features. The Microsoft JVM is the only choice if you want to use Java to control and automate an Excel operation. The Sun or Microsoft JVM are needed to get current class libraries like the "collections" framework.

 

What is clearly wrong by any measure is to deny programmers the right to make their own decision to select the best tool for the application they are designing. Yet that is the thrust of the Sun legal effort and it has been endorsed by every Judge to who the case has been presented. Any careful analysis of judicial opinions in these matters, however, make it clear that none of these Judges has ever really understood the technology, how it works, why it was created, or what it is used for. Consider the bizarrely one-sided and technically incoherent description generated by Judge Jackson in his findings in the Federal antitrust case:

 

In a further effort intended to increase the incompatibility between Java applications written for its Windows JVM and other Windows JVMs, and to increase the difficulty of porting Java applications from the Windows environment to other platforms, Microsoft designed its Java developer tools to encourage developers to write their Java applications using certain "keywords" and "compiler directives" that could only be executed properly by Microsoft's version of the Java runtime environment for Windows. [394 in Findings of Fact]

 

Microsoft certainly created keywords and directives. As was previously pointed out, the compiler directives were buried in comment fields that are ignored by other Java compilers, and any failure of the program to run on other systems was due to the intentional use of a Windows system service and not due to a reaction of the other system to the directive. They delegate keyword would generate a syntax error on other systems, but again this is only used when you are talking to a COM component that doesn't run on any other system.

 

The Microsoft extensions allowed programmers who wanted to write Windows-only programs to write them in Java. If the extensions were not provided by Microsoft, these programs would have been written in Visual Basic or Delphi. They could never be written in 100% pure Sun Java.

 

Was this War Really Necessary?

In its most recent court case, Sun portrays a conflict between Java and the .NET Framework for "mindshare" in the developer community. This is a two horse race that will decide the future of the industry.

 

Competition is good. We who use and develop applications within the technology benefit when there are two alternatives each with strengths and weaknesses. However, the advantage of choice disappears when we are asked to convert 100% of our development to ether alternative.

 

Microsoft has the most general solution and a very powerful collection of initial building blocks. The strength of this offering, however, is compromised by the same poor management decisions that got Microsoft in trouble over Java. Whenever Microsoft has an offering in any area of technology, they target their development specifically to their own product and often fail to support generic standards. Because Microsoft's Active Directory is based on the LDAP protocol, for example, Microsoft programming technology fails to operate correctly with any other LDAP server. Microsoft support for Exchange similarly drives out any support or testing of other E-Mail standards. Java has much better support for industry-wide standards.

 

Java and the .NET Framework will continue to interoperate. The emerging technology of Web Services guarantees a high level component architecture where both platforms can exchange data and requests. This will be adequate for some purposes, but it is not efficient.

 

Competition is good, War is bad. It is particularly bad for the civilians who get caught in the middle. Microsoft may have instigated the war with its silly provocative decisions on RMI and JNI. Sun then initiated formal hostilities. The fighting may have cooled off some in recent months, but now the innocent programmers in other companies and universities must deal with the scorched earth that was left behind.

 

If Microsoft had been allowed to continue Java development, we can project their previous work onto the current technology. They would have been able to update their Java runtime to support current generation class libraries (collections, internationalization, etc.). Microsoft might have updated Java's COM support to also include .NET Remoting for high performance interoperability with components written in other languages. Then people could write in any language, on any platform, with any services they chose.

 

Instead, there is a wall between Java and .NET that cannot easily be scaled. You have to decide to use either Java or .NET technology. The only communication between the two is provided by Web Services. This complicates program design, creates two distinct sets of programming skills, and fragments any libraries of tested reusable components.

 

 

Jos jedno:

 

 

 

Home -> Why Java Will Always Be Slower than C++

 

Why Java Will Always Be Slower than C++

by Dejan Jelovic

 

 

 

"Java is high performance. By high performance we mean adequate. By adequate we mean slow." - Mr. Bunny

 

 

 

Anybody that has ever used a non-trivial Java program or has programmed in Java knows that Java is slower than native programs written in C++. This is a fact of life, something that we accept when we use Java.

 

However, many folks would like to convince us that this is just a temporary condition. Java is not slow by design, they say. Instead, it is slow because today's JIT implementations are relatively young and don't do all the optimizations they could.

 

This is incorrect. No matter how good the JITs get, Java will always be slower than C++.

 

The Idea

People who claim that Java can be as fast as C++ or even faster often base their opinion on the idea that more disciplined languages give the compiler more room for optimization. So, unless you are going to hand-optimize the whole program, the compiler will do a better job overall.

 

This is true. Fortran still kicks C++'s ass in numeric computing because it is more disciplined. With no fear of pointer aliasing the compiler can optimize better. The only way that C++ can rival the speed of Fortran is with a cleverly designed active library like Blitz++.

 

However, in order to achieve overall results like that, the language must be designed to give the compiler room for optimization. Unfortunately, Java was not designed that way. So no matter how smart the compilers get, Java will never approach the speed of C++.

 

The Benchmarks

Perversely, the only area in which Java can be as fast as C++ is a typical benchmark. If you need to calculate Nth Fibonacci number or run Linpack, there is no reason why Java cannot be as fast as C++. As long as all the computation stays in one class and uses only primitive data types like int and double, the Java compiler is on equal footing with the C++ compiler.

 

The Real World

The moment you start using objects in your program, Java looses the potential for optimization. This section lists some of the reasons why.

 

1. All Objects are Allocated on the Heap

Java only allocates primitive data types like int and double and object references on the stack. All objects are allocated on the heap.

 

For large objects which usually have identity semantics, this is not a handicap. C++ programmers will also allocate these objects on the heap. However, for small objects with value semantics, this is a major performance killer.

 

What small objects? For me these are iterators. I use a lot of them in my designs. Someone else may use complex numbers. A 3D programmer may use a vector or a point class. People dealing with time series data will use a time class. Anybody using these will definitely hate trading a zero-time stack allocation for a constant-time heap allocation. Put that in a loop and that becomes O (n) vs. zero. Add another loop and you get O (n^2) vs. again, zero.

 

2. Lots of Casts

With the advent of templates, good C++ programmers have been able to avoid casts almost completely in high-level programs. Unfortunately, Java doesn't have templates, so Java code is typically full of casts.

 

What does that mean for performance? Well, all casts in Java are dynamic casts, which are expensive. How expensive? Consider how you would implement a dynamic cast:

 

The fastest thing you could do is assign a number to each class and then have a matrix that tells if any two classes are related, and if they are, what is the offset that needs to be added to the pointer in order to make the cast. In that case, the pseudo-code for the cast would look something like this:

 

DestinationClass makeCast (Object o, Class destinationClass) {

Class sourceClass = o.getClass (); // JIT compile-time

int sourceClassId = sourceClass.getId (); // JIT compile-time

 

int destinationId = destinationClass.getId ();

 

int offset = ourTable [sourceClassId][destinationClassId];

 

if (offset != ILLEGAL_OFFSET_VALUE) {

return <object o adjusted for offset>;

}

else {

throw new IllegalCastException ();

}

}

Quite a lot of code, this little cast! And this here is a rosy picture - using a matrix to represent class relationships takes up a lot of memory and no sane compiler out there would do that. Instead, they will either use a map or walk the inheritance hierarchy - both of which will slow things down even further.

 

3. Increased Memory Use

Java programs use about double the memory of comparable C++ programs to store the data. There are three reasons for this:

 

Programs that utilize automatic garbage collection typically use about 50% more memory that programs that do manual memory management.

Many of the objects that would be allocated on stack in C++ will be allocated on the heap in Java.

Java objects will be larger, due to all objects having a virtual table plus support for synchronization primitives.

A larger memory footprint increases the probability that parts of the program will be swapped out to the disk. And swap file usage kills the speed like nothing else.

 

4. Lack of Control over Details

Java was intentionally designed to be a simple language. Many of the features available in C++ that give the programmer control over details were intentionally stripped away.

 

For example, in C++ one can implement schemes that improve the locality of reference. Or allocate and free many objects at once. Or play pointer tricks to make member access faster. Etc.

 

None of these schemes are available in Java.

 

5. No High-Level Optimizations

Programmers deal with high-level concepts. Unlike them, compilers deal exclusively with low-level ones. To a programmer, a class named Matrix represents a different high-level concept from a class named Vector. To a compiler, those names are only entries in the symbol table. What it cares about are the functions that those classes contain, and the statements inside those functions.

 

Now think about this: say you implement the function exp (double x, double y) that raises x to the exponent y. Can a compiler, just by looking at the statements in that function, figure out that exp (exp (x, 2), 0.5) can be optimized by simply replacing it with x? Of course not!

 

All the optimizations that a compiler can do are done at the statement level, and they are built into the compiler. So although the programmer might know that two functions are symmetric and cancel each other now, or that the order of some function calls is irrelevant in some place, unless the compiler can figure it out by looking at the statements, the optimization will not be done.

 

So, if a high-level optimization is to be done, there has to be a way for the programmer to specify the high-level optimization rules for the compiler.

 

No popular programming language/system does this today. At least not in the totally open sense, like what the Microsoft's Intentional Programming project promises. However, in C++ you can do template metaprogramming to implement optimizations that deal with high-level objects. Temporary elimination, partial evaluation, symmetric function call removal and other optimizations can be implemented using templates. Of course, not all high-level optimizations can be done this way. And implementing some of these things can be cumbersome. But a lot can be done, and people have implemented some snazzy libraries using these techniques.

 

Unfortunately, Java doesn't have any metaprogramming facilities, and thus high-level optimizations are not possible in Java.

 

So...

Java, with the current language features, will never be as fast as C++. This pretty much means that it's not a sensible choice for high-performance software and the highly competitive COTS arena. But its small learning curve, its forgiveness, and its large standard library make it a good choice for some small and medium-sized in-house and custom-built software.

 

 

 

 

 

Notes

1. James Gosling has proposed a number of language features that would help improve Java performance. You can find the text here. Unfortunately, the Java language has not changed for four years, so it doesn't seem like these will be implemented any time soon.

2. The most promising effort to bring generic types to Java is Generic Java. Unfortunately, GJ works by removing all type information when it compiles the program, so what the execution environment sees is the end is again the slow casts.

 

3. The Garbage Collection FAQ contains the information that garbage collections is slower than customized allocator (point 4 in the above text).

 

4. There is a paper that claims that Garbage Collection Can Be Faster than Stack Allocation. But the requirement is that there is seven times more physical memory than what the program actually uses. Plus, it describes a stop-and-copy collector and doesn't take concurrency into account. [Peter Drayton: FWIW, this is an over-simplification of the paper, which provides a means of calculating what the cross-over point is, but doesn't claim that 7 is a universal cross-over point: it is merely the crossover point he derives using the sample inputs in the paper.]

 

 

 

 

 

Feedback

I received a lot of feedback about this article. Here are the typical comments, together with my answers:

 

"You forgot to mention that all methods in Java are virtual, because nobody is using the final keyword."

 

The fact that people are not using the final keyword is not a problem with the language, but with the programmers using it. Also, virtual functions calls in general are not problematic because of the call overhead, but because of lost optimization opportunities. But since JITs know how to inline across virtual function boundaries, this is not a big deal.

 

Java can be faster than C++ because JITs can inline over virtual function boundaries.

 

C++ can also be compiled using JITs. Check out the C++ compiler in .NET.

 

In the end, speed doesn't matter. Computers spend most of their time waiting on our input.

 

Speed still maters. I still wait for my laptop to boot up. I wait for my compiler. I wait on Word when I have a long document.

 

I work in the financial markets industry. Sometimes I have to run a simulation over a huge data set. Speed matters in those cases.

 

It is possible for a JIT to allocate some objects on a stack.

 

Sure. Some.

 

Your casting pseudo-code is naive. For classes a check can be made based on inheritance depth.

 

First, that's only a tad faster than the matrix lookup.

 

Second, that works only for classes, which make up what percentage of casts? Low-level details are usually implemented through interfaces.

 

So we should all use assembly, ha!?

 

No. We should all use languages that make sense for a given project. Java is great because it has a large standard library that makes many common tasks easy. It's more portable than any other popular language (but not 100% portable - different platforms fire events at different times and in different order). It has garbage collection that makes memory management simpler and some constructs like closures possible.

 

But, at the same time, Java, just like any other language, has some deficiencies. It has no support for types with value semantics. Its synchronization constructs are not efficient enough. Its standard library relies on checked exceptions which are evil because they push implementation details into interfaces. Its performance could be better. The math library has some annoying problems. Etc.

 

Are these deficiencies a big deal? It depends on what you are building. So know a few languages and pick the one that, together with the compiler and available libraries, makes sense for a given project.

 

 

 

 

 

 

--------------------------------------------------------------------------------

 

Content of this site is © Dejan Jelovic. All rights reserved.

 

[niking]

ah da, ti si u Americi i imas mogucnost i novca da kupis softver

[Dersu Uzala]

Tu ljudi imaju vise softvera instaliranog po kompjuteru nego your truly. Drugo, ja sav softver za razvoj dobijem od firme. Ja cuh da je MS softver jeftiniji u Jugi nego u Americi. Znacajno.

[TtuEd]

Inace Mac OSX ne koristi taj Mach kernel na kome je NeXtSTEP baziran, oni su otkupili neki treci kernel koji se zove XNU (skracenica od 'X is Not Unix). Ne zezam se.

 

I XNU je hibridan kernel kao i Windows kernel, znaci kombinovan mikro i monolitni kernel.

Nije skracenica nego akronim - XNU is Not Unix, isto kao sto GNU znaci GNU is Not Unix. Nije UNIX naravno, ali jeste UNIX-like. Anyway, to cut the long story short, Mac OS X jeste UNIX-like OS.

[voodoo_]

To je tačno, danas se ne gleda da li je nešto Unix prema tome da li je bazirano na nekom od prastarih kernela, nego da li je kompatibilan sa Single Unix specifikacijom.

[Dersu Uzala]

Vas dvojica bas resili da terate mak na konac.

 

Prvo akronim i znaci skracenica. A znaci od 1943 u engleskom jeziku (ako pogledas webster recnik online) i srkacenica formirana od pocetnih slova neke reci, ili prvih slova reci ako ih ima vise. Drugo u duhu naseg jezika, mi ne koristimo rec akronim vec skracenica.

 

Trece, kompatibilnost sa Unix-om (sa kojim to Unix-om) je nebitna, to jest nemoguca, rekao bih. Single Unix specifikacija ne znaci nista u pogledu toga da li ce neki sistem DANAS kako kazes biti nazivan Unix sistemom. Ako procitas malo bolje njihov sajt, videces da je da bi neki sistem bio zvan Unix sistemom, mora da bude licenciran i registrovan od iste organizacije. A da bi bio licenciran i registrovan od te organizacije, kod tog sistema mora da bude strogi derivat izvornog Unix koda. Kompatibilnost? Definisi kompatibilnost izmedju OS-eva? Niti rade na istom hardveru niti vrse isti posao na isti nacin, jedino mogu da u izvesnoj meri komuniciraju. Preko nekih definisanih interfejsa. Pa sta, to rade i Windows i Unix. Jelto sad znaci da je i Windows Unix kompatibilan sistem?

 

Uostalom jedino Mac OS 10.5 Leopard sa Intel-based masina je certifikovan Single Unix specifikacijom. Pitam se zasto bas taj Intel baziran produkat.

Edited May 20, 2008 by Odliveni Mozak

[imaginos]

Jelto sad znaci da je i Windows Unix kompatibilan sistem?

a posix? ;-)

 

http://getwiki.net/-Microsoft_Windows_Services_for_UNIX

Microsoft which provides a Unix subsystem and other parts of a full Unix environment on Windows NT and its successors. The subsystem included is called Interix.

 

Like the Microsoft POSIX subsystem in Windows NT, Interix is not an emulation of a Unix kernel, but rather an implementation of a user-mode subsystem running directly on top of the Windows NT kernel.

 

edit. itd: http://articles.techrepublic.com.com/5100-...11-5047677.html

 

 

 

p.s. izvinjavam se auditorijumu sto kasnim za odgovorima, ali nisam vas zaboravio, ne brinite. ;-)

Edited May 20, 2008 by imaginos

[Dersu Uzala]

Posix

 

Nisam hteo tu ni da zalazim. Nego ni Linux nema Single Unix sertifikaciju jerbo nije derivat Unix specifikacije i izvornog koda, vec mimikuje funkcionalnost istog.

 

Kad vec spomenu Microsoft (i Posix) jasno ti je da je vlasnik prve verzije Xenix-a Microsoft. Ja sam nesto kratko petljao sa Microsoft Xenix/286. Kad su poceli da petljau oko OS/2 sa IBM-om preneli su vlasnistvo Xenix-a SCO-u, koji im je i radio portove za PDP-11, Zilogove procesore i Intel x86. Xenix je uzgred pravi Unix. Licenciran pa portovan.

 

Sto me navodi da ispravim sam sebe. Negde spomenuh da nisi mogao da kupis Unix licencu (izvorni kod), preinacis je ili samo promenis ime proizvodu i prodajes kao svoj brend. Pravila igre su ocigledno bila malo zajebanija. Ne samo Microsoft, vec i svi ovi drugi Unix derivati su licencirani i verovatno extendovani pa portovani na druge procesore. I prodaju se pod trejdmark imenima tih likova koji su ih portovali i platili licencu. Nije mi sad bas jasno da li si morao da portujes prvo da bi stekao pravo da zoves tu varijantu Unix-a svojim imenom (a la DEC Ultrix, HP-UX, IBM AIX, Microsoft/SCO Xenix). Verovatno je u tome fora, sto ce reci ako ne postoji verzija Unix-a prtovana za tu platformu, mozes da kupis licencu i da portujes kod i prodajes ga kao svoj ali ne mozes jednostavno da kupis licencu, preimenujes produkt i prodajes ga pod svojim imenom.

 

Morao bih da pitam ove likove sto se od '47. bave tim stvarima.

Edited May 20, 2008 by Odliveni Mozak

[Nisko_Se_Mazim]

Windows: A thirty-two bit extension and GUI shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor and sold by a two-bit company that can't stand one bit of competition.

 

 

Salu na stranu

 

Lepo izlaganje Odliveni medjutim ja iz njega zakljucujem ono sto sam rekao u jednom pasusu

 

Da je broj softvera(ukljucujuci i devele alate)za neki OS direktno uslovljen zastupljenoscu istog

 

I naravno da je Windwos 5-7 godina ispred linux-a

Treba samo da se setimo kada se pojavio Win 95 koji je napravio pravu malu revoluciju na polju desktopa i na sta ja tada licio linux ciji je kernel napisan samo 3 godine pre

Pa da ne zaboravimo i drugacije koncepte oba sistema-Win je od samog pocekta bio zamisljen kao sarena zezancija za desktop dok je linux svoj malo agresivniji proboj na desktop zapoceo tek pocetkom 2000-te kada smo imali vec i Win 98 i Win2k i WinXP koji se pojavio nesto kasnije

Edited May 21, 2008 by Full_Metal_Yakuza

[Nisko_Se_Mazim]

I cisto da iznesem jedno svoje zanimljivo zapazanje

 

Kada sam pricao o zastupljenosti linux-a i pominjao neinformisanost,preinstalirane OS-ove uz konfiguracije i dugogodisnje predrasude u vezi linux-a na pamet mi ja pao Ubuntu koji je ubedljivo najpopularnija distribucija trenutno a verovatno i svih vremena

Jedan moj drugar je rekao da je upravo Cannonical sa svojim shipit-om(slanje cd-ova besplatno na adresu u bilo koju zemlju) i dobro organizovanim marketingom dobrim delom zasluzan sto je masa ljudi uopste saznala/probala linux(nevezano za Ubuntu kao distro)i postala svesna uopste njegovog postojanja

A tome treba da dodamo i od skora preinstaliran Ubuntu koji nudi Dell na svojim kompjuterima/notebook-ovima

To su neki od razloga zasto je Ubuntu tako popularan

Iz iskustva znam(koristio sve verzije od 4.10 do 8.04)da taj distro nije nista specijalno-ne kazem da je los ali niti je nesto preterano gori ili losiji od ostalih i nema nista u sebi sto vec nemaju npr PCLOS ili SUSE vec je u pitanju jedan najobicniji dejavu(Debian Unstable tacnije)koji je samo lepuskasto upakovan

Dakle Ubuntu nije popularan zahvaljujuci bezrezerevnim vrlinama svog distroa

Pa sta li je u pitanju?

 

Evo vam i jedan insteresantni link,overite

 

http://linux.dootzky.com/

Edited May 21, 2008 by Full_Metal_Yakuza

[AstralliS]

Evo vam i jedan insteresantni link,overite

 

http://linux.dootzky.com/

 

Ima mene na toj mapi, tamo dole južno.

[Dersu Uzala]

Lepo izlaganje Odliveni medjutim ja iz njega zakljucujem ono sto sam rekao u jednom pasusu

 

Da je broj softvera(ukljucujuci i devele alate)za neki OS direktno uslovljen zastupljenoscu istog

 

nemam nista protiv da imas drugacije misljenje, ali argumentuj zaboga...Kako je to "broj softvera(ukljucujuci i devele alate)za neki OS direktno uslovljen zastupljenoscu istog"? Kako se to desilo? Kako je doslo do toga? Ne moras ni svojim recima, daj neki link...Samo da se nekako objasnimo. Ok je je da tvrdis, u jednoj recenici, ali potkrepi nas malo i nekim linkom (rakija je isto ok)...kako mislis da ja to skapiram? Kad skapiram, mozda mogu i da prihvatim. Nisi li ti taj koji religiozno apeluje za traktate i argumente?

Edited May 22, 2008 by Odliveni Mozak

[Dersu Uzala]

Evo vam i jedan insteresantni link,overite

 

http://linux.dootzky.com/

 

Ja sam zapadnije...ili istocnije...sve zavisi na koju nogu covek ustane.

Edited May 22, 2008 by Odliveni Mozak

[Sloba]

I cisto da iznesem jedno svoje zanimljivo zapazanje

 

Kada sam pricao o zastupljenosti linux-a i pominjao neinformisanost,preinstalirane OS-ove uz konfiguracije i dugogodisnje predrasude u vezi linux-a na pamet mi ja pao Ubuntu koji je ubedljivo najpopularnija distribucija trenutno a verovatno i svih vremena

Jedan moj drugar je rekao da je upravo Cannonical sa svojim shipit-om(slanje cd-ova besplatno na adresu u bilo koju zemlju) i dobro organizovanim marketingom dobrim delom zasluzan sto je masa ljudi uopste saznala/probala linux(nevezano za Ubuntu kao distro)i postala svesna uopste njegovog postojanja

A tome treba da dodamo i od skora preinstaliran Ubuntu koji nudi Dell na svojim kompjuterima/notebook-ovima

To su neki od razloga zasto je Ubuntu tako popularan

Iz iskustva znam(koristio sve verzije od 4.10 do 8.04)da taj distro nije nista specijalno-ne kazem da je los ali niti je nesto preterano gori ili losiji od ostalih i nema nista u sebi sto vec nemaju npr PCLOS ili SUSE vec je u pitanju jedan najobicniji dejavu(Debian Unstable tacnije)koji je samo lepuskasto upakovan

Dakle Ubuntu nije popularan zahvaljujuci bezrezerevnim vrlinama svog distroa

Pa sta li je u pitanju?

 

Evo vam i jedan insteresantni link,overite

 

http://linux.dootzky.com/

Vala bash Canonical Ltd je puk`o kintu na reklamu boli glava.Da su ulozili te pare u MC Guntzy-a ovaj bi vec uveliko zasenio vec zaboravljenog Micheal Jackson-a .Sa druge strane RH i Mandriva ili ti mandrake odavno naplacuju svoj trud.Linux mozda jeste dzabe i sve je bolji i jednostavniji za obican svet ali mnogo ce jos vremena proci da wine emulira adobe-a i ostale programe bez kojih se ne moze.Nemo` samo neko Gimp da mi spominje daleko je to od adobe-a jos...slazem se da je desktop moguce bolje podesiti na lindzi nego na windowsu i da se moze svasta budziti ali jednostavno podrska sa ozbiljnijim programima ne postoji jos.Uspeo sam pogledati BRLCAD, daleko je to od autocad-a a sa instalacijom sam se namucio samo tako...Linux ce i dalje biti OS za mrezadzije ali globalnu upotrebu ce doziveti tek kada jos dobudzi Cedegu i kada digne wine na visi nivo ili nadje zamenu za adobe corel cad i jos para programa bez kojih obican covek ne moze da zamisli rad. A sto se tice Ubuntu-a jbg spakovali su ga lepo i imaju repo-e sa svim stvarima koji su aktuelni, mnogo ljudi radi na njemu i ulazu mnogo u reklamu i eto uspeha.Mada ja mislim da je RH daleko najpoznatiji i najpopularniji.Nisam cuo za Ubuntu sertfikate jos ali za RH sam cuo odavno...Konzola je konzola a shell je shell...

[voodoo_]

Photoshop 7/CS1/CS2 inače najnormalnije radi na Wineu, ako te neko pita

Za uzak skup najkorišćenijih office i dizajnerskih programa (i World of Warcraft i Counter-Strike ), posao odlično radi CrossOver Linux (verzija Winea tvikovana za ove programe).

 

[AstralliS]

Još kad bi i Dreamweaver uspeo da pokrenem kroz Wine, zju.

[imaginos]

A Windows kaska za MAC-OS-om i kopira isti od starta; a MAC-OS je, gle cuda, takodje *nix (UNIX-like) OS. Sta cemo sad?

bas me zanima koja je to metrika po kojoj windows kaska za macos-om? da nije mozda market share? mogucnost igranja igrica? ;-) izbor softvera? ;-)

 

drugo, kako je to windows "iskopirao" mac i kakve to ima veze sa faktom da windows danas nudi korisnicima vise mogucnosti izbora, i vecu flaksibilnost od linux-a, te je zato mnogo prihvaceniji?

 

-----

 

 

Mislim da sam na ovo odgovorio u prethodnim postovima

mislim da izbegavas konkretan odgovor, nego sve nesto "uospteno". ako pogledas moje poruke, videces da sam se trudio da budem sto konkretniji, da navedem konkretne primere sta i zasto mislim. sa druge strane, tvoje teze se baziraju na "opste je poznato", "ovo je mnogo bolje od onoga" i nekoj retorici.

 

inace, kad god cujes nekoga da prica kako je "ovo mnogo bolje od onoga", "ovo je superiorno, a ono je sranje", i kad god cujes nekoga da donosi zakljucke od opste vaznosti u vezi softvera - znaj da nema pojma o cemu prica. jer ne postoji univerzalno dobro resenje. postoje primene za koje je mikrokontroler 8085 BOLJI od quad core procesora i postoje primene u kojima je bolje raditi na linuxu nego na windowsu, postoje situacije kad kes memorija donosi vise usporenja nego ubrzanja, itd, itd. nema tu crno-belo, nego se treba debelo informisati pre nego sto odlucis koju ces komponentu da stavis za koju primenu...

 

I na kraju-Windwos advokati uglavnom potezu nepostojanje standarda,te nema ono te nema ovo

1. da li bi ti mene okarakterisao kao windows advokata? jel windows advokat pise linux instal skripte za adsl usb, pa kaci po forumima?

2. to sto si naveo (nepostojanje standarda) je fakat. nije prijatno, ali je cinjenica.

 

Samo, nikako nekako da obicni korisnici u radu osete to(ne,programeri nisu obicni korisnici )

sta "nikako da osete"? cari editovanja xorg.conf-a ako imaju neki 16:9 monitor? pa covece, sada je 2008 godina i pola novih distroa ne moze da provali da je rezolucija mog monitora 1680x1050, nego mi razvlaci sliku 1024x768, dok ne editujem xorg.conf jel su to ti sjajni featuri koje propustaju windows korisnici? ;-)

 

Naprotiv,oni uzivaju u KDE ili Gnome-u koji su za dva koplja bolji(objektivno i subjektivno)

kojom metrikom si dostao do rezultata da su gnome/kde objektivno bolji od windows gui-ja?

 

Zato sto je doticni OS najrasprostranjeniji na planeti-sto je logicno

Nema to nikakve veze sa "standardizacijom" i nepostojanjem Visual Studio-a vec sa time sto se velikim(i malim)kompanijma koje prave softver ne isplati(jos uvek)da svoje pulene izdaju i za linux koji nema jos uvek dovoljan market share da bi ulozeno krenuo da se obrce

Da kojim slucajem Linux drzi jedno 20% market share-a za njega bi postojale sve(ili najmanju ruku veci deo)aplikacija kao i za Windoze

zanimljiva teza, ali netacna. da bih ti ilustrovao zasto, napravicemo kratko poredjenje i presek BESPLATNOG softvera za linux i za windows, gde se vidi da windows nudi mnogo izbora cak i u tom domenu.

 

- da pocnemo od IDE alata. pod linuxom mogu da teram eclipse, netbeans, na primer, a pod windowso mogu da teram sve to, i visual studio express. dakle, (najmanje) jedna mogucnost vise. sve sto mogu pod linuxom - mogu i pod windowsom, dok suprotno ne vazi. dakle, windows mi nudi vise mogucnosti.

 

- izbor messengera za windows je ogroman, a to su sve besplatne aplikacije: gtalk je prvo nastao za windows pa za linux, skype isto, msn da ne pominjemo. pigdin je smejurija u odnosu na msn na primer.

 

neke zanimljive besplatne aplikacije za koje ne postoji alternativa istog kvaliteta na windowsu:

- ant movie katalog

- kmplayer (mplayer nema toliko mogucnosti i podesavanja, izlaz na TV i manupulacija slikom na tvu, editovanje subtitleova, itd)

- toad free - administracija oracle-a (pandani na linuxu mu nisu dorasli)

- desktop search. za windows imas vise besplatnih aplikacija. copernic mnogi smatraju najboljom DS aplikacijom, i ona ne postoji za linux, ali i pored toga - cinjenica je da za windows postoji vise besplatnih search aplikacija nego za linux. kako to da im se isplati da prave besplatne aplikacije za windows?

- file manageri: za windows ih ima gomila, ne zna im se broj.

 

zatim, da vidimo koliko IZBORA imaju windows korisnici a koliko linux korisnici kad je u pitanju multimedia softver - konkretno playeri:

 

video: http://en.wikipedia.org/wiki/Comparison_of...Video_players_2

audio: http://en.wikipedia.org/wiki/Comparison_of...Audio_players_2

 

pored toga, ima mnogo besplatnog softvera za windows. na primer, moja kucna masina, desktop, sadrzi samo windows i sve ostalo je besplatni softver. gomila toga moze da se nadje ovde: http://www.freeware-guide.com/ ili http://www.softpedia.com. zaista, windows ne oskudeva u besplatnom softveru, dakle - mnogo ljudi se odlucuje da napravi BESPLATAN softver za windows, pa dakle, razlog popularnosti windowsa ne lezi u tome sto "se velikim(i malim)kompanijma koje prave softver ne isplati(jos uvek)da svoje pulene izdaju i za linux koji nema jos uvek dovoljan market share da bi ulozeno krenuo da se obrce".

 

dakle, teza da ima vise softvera za win jer se ljudima isplati da prodaju svoj softver siroj publici (windows korisnicima) - je upravo pala u vodu. windows nudi mnogo izbora cak i u domenu besplatnog softvera.

 

to ide u prilog tezi da su RAZVOJNI ALATI i lakoca integracije sa sistemom i ostalim komponenetama ono sto je ucinilo windows prihvacenim, a ne neki monopol i slicno. ljudima je jednostavno lakse da pisu dobar softver za win. kad na linuxu to bude moguce - pocece ozbiljnija konkurencija. a to se ne desava zato sto je sloboda=anarhija u linux zajednici.

 

ako bismo zamislili relaciju linux-windows kao borbu dve vojske na bojnom polju, to bi bilo:

• sa jedne strane vojnici, neki odlicni neki srednje sposobni, ali svako ima slobodu da puca gde hoce i da ratuje kako hoce i da se naoruzava kojim hoce oruzjem (i da pravi svoje ako zeli). nemaju vrhovnog komandanda nego jedno 4-5 generala koji komanduju u istoj bitci. a pri tome njih petorica kontrolisu jedno 30% vojske, ostalo su "slobodni strelci".
• sa druge strane disciplinovana vojska koja htela ne htela mora da slusa naredjenja centralne komande, svi koriste istu municiju (code reusability). a glavni komandant ima mnogo talenta za vojnu taktiku. ;-)

 

kad tako pogledas sliku postaje jasno zasto windows drzi jedno 90% trzista a linux se koprca da dodje do 2%. ;-]

Edited May 22, 2008 by imaginos

[Sloba]

Photoshop 7/CS1/CS2 inače najnormalnije radi na Wineu, ako te neko pita

Za uzak skup najkorišćenijih office i dizajnerskih programa (i World of Warcraft i Counter-Strike ), posao odlično radi CrossOver Linux (verzija Winea tvikovana za ove programe).

Haha ne bi bio ovo forum da nema prepucavanja.Slazem se da wineom mozes pokrenuti photoshop 7 ali ne slazem se da to najnormalnije radi...Apsolutno se slazem sa Imaginosovim postom.Jednostavno biramo software i hardware prema potrebi a da to najmanje boli po dzepu a da zavrsava posao.