Coding The Future Linux Desktop [updated] 700
the.jedi writes "With the release of GTK+ 2.4, and Gnome 2.6 due out some time next week, it seems of some the Gnome developers are looking at how they'll be coding Gnome and the rest of the Linux desktop. Havoc Pennington of Planet Gnome has written a short blog pondering and analyzing the available options as coders move towards high-level languages like java and C#. He gives a good overview and assessment of technologies like mono, OO.org's UNO framework, as well as other ways of tying new languages to the existing code base. An extremely interesting read for desktop linux hackers everywhere."
Update: 03/17 14:44 GMT by T : Speaking of the future of Gnome, aeneas writes with a list of Gnome 2.6 release parties around the world (linked from gnome.org/start/2.5).
Next week I will be coding the Linux desktop: (Score:5, Funny)
[] in scheme
[] in mono
[] in asm
[X] in a penguin suit
[] whilst eating a banana
[] upside down
[] badly
[] perfectly
[] in an easy to use fashion
[] as a placeholder for my terminal windows
[] to look just like Windows
Re:Next week I will be coding the Linux desktop: (Score:5, Funny)
For Slashdot tradition completeness sake:
[] with Cowboyneal
or
[] I don't code in Linux, you insensitive clod!
How about still using C (Score:5, Interesting)
And now, the rest of the story (Score:5, Insightful)
This isn't American and it isn't even Capitalist; it's Human, and probably vexed Pharoah as much as it vexes you or the lower income individual on the upgrade treadmill (MS/Software/_or_ Hardware.)
Regards,
A. C.
Re:How about still using C (Score:5, Insightful)
No. C has its place for sure, but for writing desktop apps it's the wrong tool for the job.
Still, I have to admit, this is something that could go so many ways. Right now Mono has the mindshare in terms of Gnome/GTK# apps, people are playing with it, liking it, there are actually unique interesting apps (like Muine [gooeylinux.org]) written in it etc. Where are the interesting GTK/Java apps?
On the other hand, the GNU java toolchain is nicer than Monos. GCJ is a really nice, easy to use compiler that's pretty fast and it creates ELF binaries. It fits in with the existing infrastructure, reuses our investment in ELF and the resultant apps don't have strange EXE and DLL extensions.
Java-GTK is apparently also quite a mature set of bindings, though I haven't used them so I can't say for sure.
I'm not convinced the patents thing is really valid. If Microsoft have patents on their class libs I think it massively unlikely Sun don't have patents on theirs. Worse, I suspect that even if there was a completely open source, newly designed framework that was similar to Java/.NET it would fall under those same patents.
We probably just have to ride them out.
I think Havoc is off base with the XAML comments. XAML will only be usable with the arrival of Longhorn which is in, what, 2008 now? It looks a lot like XUL, and yet where are all the XUL apps? Firebird is still the flagship XUL app, even after all this time. I certainly cannot see XAML taking over HTML anytime this century, there's simply too much investment in HTML and XAML isn't compelling enough from what I've seen to offset that.
Re:How about still using C (Score:4, Insightful)
A lot of these modern coders on their 3 GHz boxes don't appreciate elegance of design, nor do they think highly of efficiency. It's a shame, but c'est la vie. They're only hurting Linux's desktop uptake in 3rd world countries and businesses with millions of old machines. You think a P500 with 64M, of which there are millions, can run GNOME + OpenOffice.org + Mozilla? Linux is going to be royally screwed unless we start paying attention to efficient design and coding.
And that includes you, Havoc.
Re:How about still using C (Score:5, Insightful)
I should think we'd all be better off if more and more end-user apps were being written in interpreted languages like Ruby, Python, or Perl, using the appropriate GUI bindings (my personal favorite is Ruby-GNOME2, especially just the GTK bits, since those are supported on Windows for an added portability bonus). Porting scripts from one GUI toolkit to another is often quite possible as well since the differences are often minimal (just don't get distracted by that ever-sought Holy Grail of the Meta-Toolkit). Not only that, there appears to be some promise for the idea of using libraries written in any C-based scripting languages from any of the other C-based scripting languages (just as they have excellent capabilities for using C libraries).
Re:How about still using C (Score:5, Insightful)
And, sorry, I think there's a reason why Java is popular on the server side, and why you don't see any killer desktop apps written in Java. And why I'd actually like it to stay that way.
Off the top of my head:
1. I'll say _you_, then, haven't spent days debugging a Java memory leak. Especially in a Swing program. One single listener you've forgot to explicitly remove can keep whole forms or even whole windows still loaded in memory. No, the garbage collector doesn't automatically free those.
2. The garbage collector does _not_ play well with the swap file. It causes each page belonging to the Java heap to be regularly paged in. Often. Several times per garbage collection pass, in fact.
So whereas a system which stuck to C or C++ will still run at full speed when I load 550 MB of programs in a 512 MB of RAM, a 100% Java system would trash to death at that point. (In fact, see point 2: much sooner than that.)
Or if only 300k out of that is Java stuff, it will act all elbows to the other apps. It will keep bringing its own pages in, and forcing everyone else to do with less memory.
And no, this problem isn't solved by compiling to ELF. As long as you have a garbage collector, it happens anyway.
3. Java RAM usage is ludicrious, especially for a system based on small utilities, like *nix is. I've actually had to write once the exact same small GUI utility in both C and Java. The C version ran in under 1 MB. The Java version allocated 16 MB right upon startup.
It gets worse from there. Even minimal string manipulation or use of trees will easily use 2-3 times more memory than in C. Stuff which in C/C++ goes on the stack, or is allocated together as part of a single struct, in Java ends up a twisty little maze of individually allocated objects, each with its own memory overhead, above the size of the data in it. A simple String is two objects for example.
4. It also has horrible startup time. No, sorry, I don't want to wait a couple of seconds just for the JVM itself to initialize, each time I launch an application. And I think that both Gnome and KDE are already proverbially slow to start as it is; they don't need to add half a minute to their startup time just because the gazillion apps they run on startup are Java.
5. Swing is slow. It insists on painting every single pixel in the window personally. Basically if you have one form in a swing window, the whole window is one big canvas, on which the individual buttons/fields/toolbars/menus/etc are rendered in software, pixel by pixel. If that's your idea of a fun desktop, may I humbly suggest setting your X to use the VESA framebuffer instead of whatever accelerated driver you're using?
6. It also requires quite a bit of clue to use well. See for example the listener leaks I've mentioned before. Or it's very easy to write GUI code that's dead slow, if you don't know what you're doing. E.g., code which takes several seconds just to fill in the values in a combo box.
Etc.
Basically, I'm all for Java and all, but I sure as heck don't want it on my desktop, if I have a choice. When I run a web browser or an IRC client program, I very much like them to be well behaved applications which don't play hardball with the paging. I also appreciate if they don't allocate 3 times more memory than they really need.
So, sure, the Gnome team is free to switch to whatever language they please. But the day they release a desktop based on Java, it'll very likely be the day when I kick Gnome as whole off my hard drive.
Re:How about still using C (Score:4, Interesting)
1. I'll say _you_, then, haven't spent days debugging a Java memory leak. Especially in a Swing program. One single listener you've forgot to explicitly remove can keep whole forms or even whole windows still loaded in memory. No, the garbage collector doesn't automatically free those.
Well, then I'll say you haven't spent time debugging C or C++ code. My previous job was C++ UI application development, for the last five years I've been doing Java Swing UIs. There's simply no comparing the frequency of memory leak type problems on Java and C++. I haven't had a memory leak problem in years in Java, it's just too simple to avoid.
Re:How about still using C (Score:5, Insightful)
I wrote a Swing application distributed by a major Internet company (trust me, you've heard of us). The application is well over a hundred thousand lines of code and has been downloaded millions of times.
Yes, you can leak memory in Java. Yes, failing to unregister a listener can lead to huge chunks of memory being retained. No, I can't see how it can take days to track such a problem down.
Java's -Xrunhprof option allows you to generate a complete map of the heap, including all references between objects. When faced with a problem like this, I took half an hour to write a program that would analyze the heap dump and tell me why a particular object was still held in memory.
Then I ran the program for a while, as memory steadily increased due to the leakage, and captured several heap dumps. A quick comparison between the various dumps pointed me towards some objects that seemed suspicious. A quick analysis, and I had an exact chain of pointers from the root set to the offending objects.
Total time to debug, including writing the heap analysis utility: under an hour.
If you have spent days debugging a problem like this, you need help. You make it sound as if the fact that you can accidentally retain an entire object graph is a problem, when it's actually a blessing in disguise. In C, you can easily leak four bytes at a time, and good luck finding it. In Java, leaks are A) much less common, and B) tend to involve many thousands of bytes, and the size of the leaks tends to makes it much easier to notice that there is a problem and subsequently track it down.
Even if, once in a great while, a Java memory leak is actually sticky enough to take days to track down, I still submit that it is light years better than the situation with C.
Swing is slow. It insists on painting every single pixel in the window personally. Basically if you have one form in a swing window, the whole window is one big canvas, on which the individual buttons/fields/toolbars/menus/etc are rendered in software, pixel by pixel. If that's your idea of a fun desktop, may I humbly suggest setting your X to use the VESA framebuffer instead of whatever accelerated driver you're using?
I humbly suggest that you take a look at the Java2D source and get a clue before you go around spouting nonsense like this. Java does indeed take advantage of hardware acceleration built into the video driver, and can even use OpenGL for its 2D rendering.
Re:How about still using C (Score:3, Insightful)
Why would anyone write applications that require Mozilla, when Mozilla is on fewer than 10 percent of the computers out there? That's a good way to alienate your user base.
On the other hand, how many web applications out there are "IE Only" ? We know all too well that there are a lot of webmasters and ISV's out t
Remember SWT (Score:3, Insightful)
IBM's SWT is mature and has native UI bindings for an abundance of platforms [eclipse.org], GTK2 included. That's a good place to start.
As I see it, the main benefit of Mono would be the ability to run MS apps on Linux in the future.
Except (Score:4, Insightful)
Except that they are not poerting things like windows.forms, so just about nothing written for
Mono makes a great tool for migrating Linux programmers over to Windows though.
System.Windows.Forms and mono (Score:4, Informative)
(which is also why Microsoft is backing off of S.W.F themselves; the whole point of them going with
That said, mono is in fact working on a S.W.F implementation in conjunction with Wine.
Two things to keep in mind (Score:4, Insightful)
Sun is also a hardware company and not strictly an OS/apps company. Plus, Sun is not as f-ed up as M$ when it comes to wanting to own every piece of technology they come in contact with. (Also, see last paragraph in this post.)
I think Havoc is off base with the XAML comments. XAML will only be usable with the arrival of Longhorn which is in, what, 2008 now?
Never underestimate an M$ technology. And I keep thinking of how many projects I've worked on where they code to IE and its standards complaint HTML that does not render in anything else. If you think that HTML is in the clear for now and the near future, you're mistaken. I think it's even a struggle now to keep people from just coding to IE. In the business world, where 99% of all the desktops run Windoze, any HTML project will probably only code to IE. For them, there's no reason not to.
I think Havoc is dead on the money with this one. XAML is a threat to HTML and it's needs to be watched and one-upped by the free/open community out there - he's bringing up the right arguments. If not, then there will be little reason for people to even use HTML at all. And like I said, if there's no reason for people to develop to an HTML standard, then there will be no reason to develop to HTML at all.
As for Mono; I also agree with Havoc here in that free alternative technologies should be developed outside M$ and not with it. Until M$ want's to be a regular member of the technology community and not the sole owner of everything, then they can't be trusted. And this is not just a rant but an opinion based on their historical behavior.
While, again, I think the Mono and dotGnu guys are doing a good job, I think their efforts are misplaced. Maybe at a minimum, provide a c# compiler like gcj. But all this Winforms and the like and doing Linux client apps in c# is going to be more of a problem than a solution.
As far as using Java to do app? Hey, at least Sun has an interest in seeing Linux succeed; read: Sun will, like IBM, make more money on Linux at some point than Solaris. M$, on the other hand with their current business model, sees NO benefits from Linux succeeding. So, again, I agree with Havoc.
Re:How about still using C (Score:3, Informative)
Re:How about still using C (Score:4, Informative)
1) Mozilla and OO are written in C++ not Java or C#
2) Java on a modern hotspot JVM can outperform the equivalent C++ code for stuff that isn't IO limited (ie number crunching stuff)
3) GCJ compiles Java to native code anyway.
I'm not sure I see your point.
Re:How about still using C (Score:3, Interesting)
Bullshit.
The best case scenario for a hotspot JVM is that it produces the same code as the C++ compiler. Since it has to recompile the bytecode and run the same code as the C++ version it's mathematically impossible for it to be faster. You're just buying into the propaganda where they compare fast JVMs with crappy C++ implementation compiled with optimization switched off.
Fo
Re:How about still using C (Score:5, Insightful)
As for mathematically impossible: since the jit has access to runtime profiling information it's certainly possible to outperform a static compiler on some code. When the jit compiler is finished it stays out of the way, so the speed degradation is limited to startup time only.
Re:How about still using C (Score:4, Informative)
Re:How about still using C (Score:3, Informative)
For example, GCC compiles per file. It doesn't compile the project as a whole, so it can't perform cross-module optimisations.
Another example, how do you efficiently optimise a library statically? Not only that, but the behaviour of the application might depend upon, for example, a read-in piece of text (to determine, for example, if it logged or not). A sophisticated JIT can then generate more optimised code than a C++ compiler over time.
There are loads
Re:How about still using C (Score:5, Informative)
At 8mb on my system (that includes the java class library) that's pretty light. For comparison .NET on Windows weighs in at about 30mb and the Mono RPM (compressed) is about 8mb as well, so it's certainly competitive.
Re:How about still using C (Score:3, Informative)
It all comes down to time: development time, and maintenance time. C is a costly language, and companies don't want to pay for it.
Re:How about still using C (Score:3, Insightful)
Yes, you're correct - I currently code in it for a living
Please settle down. My point was, it's not used for DESKTOP APPS. Period (well, except in the Linux world). Talk to Adobe, MS, IBM, etc. etc. They use C++. Adobe even uses Qt.
C is everywhere, for sure, and it's an excellent tool for certain jobs. My paycheques will attest to that. But it is not a universal tool, and there are way better ways of writing desktop stuff.
Take a peek at the KDE source code sometime
Re:How about still using C (Score:3, Interesting)
Short and simple answer? Because higher level languages generally abstract the programmer from making low-level routines that can seriously affect how much time the programmer puts into the look and feel of an app. For me as a user, I often get annoyed at programs that do their functionality well, but have horrible UI and horrible design.
For me as a programmer, I use REALbasic [realsoftware.com] (not mentioned in the article). The IDE isn't on Linux, yet, but the remote debugging works well for me. It's compiled down to nat
Re:How about still using C (Score:5, Insightful)
UI's could get much easier to use if developers would just select the right widget for the job. For example: Have a two state switch? Whether some feature is enabled or disabled? Please, just use a check box. The goofy group box with the two radio buttons (one labeled "Enable" and the other "Disable") is just clutter.
Another tip? Ask a graphic designer to layout your UI, then go and implement it. Graphic Designers study the best way to graphically communicate an idea, so (speaking from experience, my wife is a graphic designer) they can be a terrific resource in laying out a UI.
Finally, if you're using any kind of graphical UI editor like MSVC, Glade, Qt Designer, etc.. it just takes a second, but line up your widgets for crying out loud. Nothing screams amateur loser like controls that don't line up correctly.
And remember - your average customer doesn't see the elegant code you wrote under the hood - they see your UI. Especially remember this when writing Linux UI's - one thing MS is fairly good at is putting together a consistent UI. Might be ugly as sin like WinXP's default, but it's consistent.
Re:How about still using C (Score:5, Insightful)
What's worse is that C forces you into a certain way of thinking. Other languages make it easier to work in other styles so you can actually implement the algorithm in the way that you come up with it.
I've got a nice computer and I want to take advantage of it. I don't write much software, but anything that could make it easier would be welcomed.
Re:How about still using C (Score:3, Insightful)
If you want/require crawling around in the guts of the system, go for C.
If you just want to get something completed quickly, use a scripting language like Perl or Python with a fat library.
Once you code enough, it all starts to look similar, anyway.
Re:How about still using C (Score:3, Insightful)
What's worse is that C forces you into a certain way of thinking.
Well, I *do* write lots of software, and I find C/C++ to be the least limiting in terms of programming style, and the most flexible. For example, I dont normally worry much about memory, but when I need to I can.
Does the new release improve the X performance? (Score:3, Interesting)
Re:Does the new release improve the X performance? (Score:5, Informative)
A big part of the slowness of gtk2 is font rendering. Motif uses (or used?) XDrawString(), so text was done entirely by the server. On the downside, the quality of the text rendering was very poor.
gtk2 draws all text with pango. Pango is a high-quality unicode text renderer with an Xft2 backend. If you have an old X server, this can be pretty slow. If you have a recent XRender extension, it's almost as fast as the old XDrawString().
Owen Taylor did add an optimisation to render text more quickly for text which gtk knows is being drawn over a plain background, this helps old X servers a lot, provided you're not using a pixmap-based theme.
Community standards... (Score:4, Insightful)
The question then is: many strong proprietary companies such as Microsoft are moving full speed ahead on high-level managed language platforms. Can open source compete, or is it too unable to make hard decisions? Rephrased: is there some way we can find to move away from C/C++, without causing massive alienation and forking?
It's time to start the discussion. Rather than fooling around in the background, companies should get involved in a broad community process where we work out a common direction for the open source desktop codebase. [emphasis mine]
I'm not a coder, or technical in any form, but I can see how this makes sense. I'd love to adopt Linux but am still trying to mount
It's my guess that more people would want to adopt Linux distros, regardless of their flavour, if the open source OS community worked out those kind of specs as a group, so that different desktop versions of Linux were broadly the same.
(Yes, I know about the kernel, but matters that the article addresses seem to be important. IMHO, it could harm Linux in the future if different distros become too divergent, leading to a loss of interoperability or the requirement of, say, 14 different varieties of OpenOffice.org depending on your distro.)
Re:Community standards... (Score:5, Funny)
Well, that's easy. First, download the latest 2.6 kernel (/dev/clue on 2.4 kernels is still experimental). Use a vanilla kernel, the clue patch is probably not working with the kernel your distro may offer. Then get the clue patch, apply it, recompile (configure the clue as module, building it directly into the kernel is not well tested), don't forget to make modules && make modules_install. Install your new kernel (if you use LILO, dont forget to call
You see, it's really not a problem, is it?
I have to say it: (Score:3, Insightful)
Windows XP's Fisher Price interface is much faster than KDE/GNOME.
Flame me, call me a troll, but it is.
This is why I stick with one of the 'minimalist' window managers. Sure, I'm missing out on a lot of things, and Joe user probably needs KDE/GNOME and all their associated parts, but I don't.
On the extreme side there are still people who only use a terminal.
Please not .net.. (Score:3, Insightful)
Feels like 10 years building a viable alternative to Microsoft and just as the goal is in sight... handing it over
Re:Please not .net.. (Score:4, Insightful)
Feels like 10 years building a viable alternative to Microsoft and just as the goal is in sight... handing it over
Bah. Programming languages are programming languages, irrespective of who came up with them. Developing software for Linux with
Avoiding Windows Forms is your first step to ensuring Microsoft is not a winner. Look into wx.NET (however incomplete it may be, it looks promising).
Yes it's their tech, yes they're evil, no it's not the death knell for Linux.
In this way (Score:3, Insightful)
Avoiding Windows Forms is your first step to ensuring Microsoft is not a winner. Look into wx.NET (however incomplete it may be, it looks promising).
Yes it's their tech, yes they're evil, no it's not the death knell for Linux.
I hate these step things but it's the best way in this case to explain the progression:
1) Get lots of Linux programmers using C#
2) Linux programmers find Window
Visual development environment (Score:5, Interesting)
I think improving the visual part of KDevelop and Glade is very important. I also think leaving C/C++ and possibly Java as the languages in which the applications are written is preferable. C# is simply Java by Microsoft.
It would also be nice to have a development environment that allowed any language to drive the UI.
Re:Visual development environment (Score:5, Insightful)
The main, almost the only consideration for any desktop app is productivity.
Discussions about speed are childish. Java - the programming language - has always been fast, and if there are bindings to GUI libraries like GTK etc, the GUI will be fast, too.
Java/Swing is fast enough nowadays, too, but - having programmed many a Swing app - it's simply not a good framework. No one will be sad to see it go, especially if its replaced something better.
In order to achieve maximum productivity, one needs to have:
1) a decent programming language that follows the obvious principle that anything that can be automated should be automated. Java / C# (the Java clone) provide some of this nowadays, whereas c/c++ definitely don't.
2) a visual, well designed IDE. the productivity gains from features such as refactoring and auto-expansion / fixing etc are just huge. enormous.
side-note: For GUI design, i think the Linux community should just outright steal OS X interface builder. the genius of that application is that it does not just take care of the widgets, but that it also tells you where those widgets will look nice, following the HI guidelines. e.g. it supports the programmer in the design department as well as in programming. which is probably most needed in the linux community. It's there. Borrow from it.
Re:Visual development environment (Score:3, Interesting)
How to do it. [apple.com]
But otherwise, the parent is right. Coding an non-trivial program is non-trivial; coding a GUI on top of that even more so.
The grandparent will have to wait until software component [wikipedia.org]-oriented programming becomes popular. After all, why reinvent the (exact same) wheel over and over again if you can provide a stock software component
High level languages (Score:3, Interesting)
I mean, we all like java, but have you ever seen a normal user application (with a GUI) written in java that is even a bit fast?
Re:High level languages (Score:5, Insightful)
No, it is because no one optimizes the code (Score:3)
Commercial Linux Apps (Score:5, Interesting)
As a bit of a GNOME fanboy, I hope GTK+ and friends can lure ISVs to use G-technologies when porting their programs. GNOME currently seems to have a large base of commercial support, although I've heard QT is being used in commercial development more. The integration of commercial apps with a desktop platform could be a make-or-break for said platform, especially as Linux market share grows and more Aunt Tillies and suits move off of Windows.
I've got a bone to pick with the FA though; it states that FOSS needs a new high level language and toolkit pronto if it's going to lure new developers. I haven't heard of the Adobes, Macromedias, or Intuits of the world scrambling to rewrite their apps in
+5 Insightful (Score:4, Informative)
Yup.
Java/C# are snazzy for:
* Custom application development
* Lightweight distributed and networked systems.
* (Java at least) Cross-platform GUI apps.
* Vertical market software development.
C/C+ are snazzy for:
* Libraries
* Horizontal market applications
Until Microsoft goes out and rewrites MS SQL Server, MSIE, and Microsoft Word in C# (not going to happen, for good reasons), I don't see any reason why there should be any interest in doing the same with the core GNOME apps.
The same goes for Sun and Java. When Sun decides that Java would make a really great language for Open Office and successfully writes an efficient Java-based Office release, then it might be worthwhile considering Java for said use.
Until then, I'd suggest rnning out and actually *using* one of the desktop apps that people have written with Java. Hey...they're slow, RAM-hungry, and annoying to run on systems with different JVMs.
There have been a zillion less efficient languages proposed to replace C (and later C++) over the years. All of them failed to replace C/C++ as a general application programming language. Efficiency matters. The fact that Microsoft is pusshing a high level language and Sun is pushing a high level language (at other people -- notice failure of Wordperfect Java port for an example of why Java/C# are not good choices for horizontal market apps) does not mean that *this* year is the time to move to a high level language. I don't think anyone here wants GNOME or KDE to have a *bigger* RAM footprint, which Java would do.
These languages are all outdated! (Score:5, Funny)
Re:These languages are all outdated! (Score:3, Interesting)
These ports are just attempts by Microsoft to sell
You seriously thought MSFT cares about languages other than C# and VB.NET?
Re:These languages are all outdated! (Score:4, Insightful)
Language Evolution (Score:5, Interesting)
BUT I've also been doing Java and C# the last three years, and they are a *huge* win in developer efficiency. Watching people working on my projects, I can see marginal developers immediately become much more productive (2x in some cases) - and I've been measuring this using several objective metrics (modules/week, LOC, PR #, time/PR).
I would rather see Java "win", but unless Sun blinks on the free/open issue _very_ quickly, I think C# will win by default.
Re:Language Evolution (Score:3, Interesting)
This will, of course, get much easier when all of those high-level langauges can talk to eachother through Parrot [parrotcode.org] as a back-end. You'll be a
C++ rules and will continue to do so (Score:3, Interesting)
Nice article Havoc!
One very key thing is that many many developers who aren't open-source fanatics still use OSS when it suites them - development tools mostly, especially mingw etc.
Now from my empirical sampling of programming buddies, I'd say these developers outnumber the OSS crowd 10 to 1. There just are so many of them, and they're going to be writing software primarily for Windows for years to come.
The key thing is supporting windows in order that we can get those developers to start writing portable code accidently rather than by design. I've already managed to get many of them to use wxwidgets but obviously C++, as Havoc pointed out, isn't best for every project.
Any OS framework has to be aimed primarily at infecting the windows world and building accidental dependance there these portable tools, so that windows apps can magically run on our alternative OSS desktop.
An OSS desktop gains momentum through supported apps making it easy for normal (windows) users to use, not through advocacy.
Never in Mono (Score:4, Insightful)
My personal opinion is that Mono must never come into the code base. It is a project doomed from the start, and I don't want it polluting the code base.
Java is good, but I don't know if any actual advantage in speed or performance will be gained by using Java over C/C++
But this is a wake up call for the community to direct the course of the all important desktop environment, which if corectly done, will make Linux usable to the average Joe.
Re:Never in Mono (Score:4, Insightful)
Umm, given that the major difference between .NET and Java is that one is made by Microsoft and the other by Sun - why exactly is Mono doomed but Java good?
To be frank, I expect a good number of people will want to move up to languages like Java/C#, so the main question is which will "win".
Strategically, Java would be good. It's got a good GNU compiler, I'd guess most professional programmers are familiar with it to some extent, it has huge momentum (for instance it's taught in universities etc), it's very mature and so on. It's also not made by Microsoft - I see rabid opposition to .NET that I don't see for Java, though the reasoning behind those views is normally pretty weak. It's also got a great IDE in the form of Eclipse, that can be compiled and run as a native app.
Realistically, I think Mono/C# will win (the "language-neutral" aspects of .NET seem negligable given how intertwined most code is with the platform that underlies the language).
It's free software through and through, and it has a strong community backed by commercial support from Ximian. There's a lot of people interested in Mono, playing with it etc. Java on the Linux desktop just doesn't have that. Technical merits really aren't major concerns next to the matter of community.
The matter of whether C# or Java is better is entirely arguable at best. I find Java too anal for my tastes and too lacking in features - C# is simply Java with more features and some warts cleaned up so it gets +1 from me.
Of course, Mono can still be bummed by technical problems - while I've been very impressed by the runtime performance of GTK# apps, Mono still imposes some seriously hefty performance penalties. For instance just running "MonoDoc", a simple documentation browser, shows "mono" using 32MB RSS - that's second only to Firefox! Muine, a (very) simple music player, takes 27mb RSS. This is a not inconsiderable chunk of memory overhead. If I had less ram a few of these apps would push me into swapping heavily.
I was going to give some comparison numbers for some Java/GTK apps, but couldn't find any that I could easily compile. Scratch that idea then. I suspect they'd be lower simply through dropping the jitting overhead, but don't quote me on that.
To be frank I'd be happy to work with either, and suspect that's exactly what I'll end up having to do.
Hear, Hear! (Score:5, Insightful)
My sentiment exactly. If Gnome is going to start stockpiling stuff written in C#, it becomes something you can't rely on always being available (i.e. it's over immediately after MSFT thinks they've been entertained enough). The moment C# is starting to creep in is the time Gnome should be forked. Or at least the applications that are written in C#.
BTW, what does Sun think of C# in Gnome? They are contributing to the project, I would suppose that C# has no place in Java Desktop System
KDE is starting to look more and more appealing every day. This is a sad thing to watch - on the one hand Gnome has great initiatives and innovative people, on the other hand we have people who seem to have missed the cluetrain and can't foresee the impending demise of non-MSFT CLR.
I for one don't want out Linux desktop future to be built on Microsoft-owned land. Look at SCO, you can start litigation and fuel FUD even with less obvious IP claims than Microsoft has for Mono.
I didn't read all of it but... (Score:5, Insightful)
C++ offers everything Java and C# do but it also can do so much more. I mean Java and C# have only recently gotten generics. In C++ it is beyond simple to old your old C API's (although C# is pretty simple also).
Some people complain that C++ is too complex, but as Java and C# mature they are becoming just as complex. Why not make it easy get the best performance out of your hardware? Why not use a language that already has tons of power and flexibility?
As for cross platform compatibility... Both C and C++ are extremely portable. It's the API's that are not always so easy. However, this is no different than Java or C#. At some level you're using a C or C++ subsystem that needs to be ported to each platform. Why not just use it in the first place?
Re:I didn't read all of it but... (Score:5, Insightful)
C# and Java aren't much higher level than C++, but they are definite improvements because they decrease opportunities for bugs.
A lot of people talk about performance, but for many apps the difference between Java (and probably C#, but I don't know) and C++ is small enough to be irrelevant. And the gap is shrinking.
Re:I didn't read all of it but... (Score:5, Interesting)
"Our guys" are gonna have to fight their guys. And if "their guys" are armed with cheap CLR/VB.net/C# runtimes (meaning there will by about 10x more), we are going to freaking lose even though we have big and complicated C/C++ howitzers.
Re:I didn't read all of it but... (Score:4, Interesting)
I don't think you could say that C++ is a high level language compared to C# or Java. Look at it this way - C++ usage on Windows is far, far higher than it's ever been in free software land yet pretty much all Windows developers I know who have tried .NET consider it a massive leap over what they were using before.
Now something will reach for the reply button to make a smart comment about MFC. Of course, MFC is not the only C++ API available - the ATL is even not that bad as they go. Even then, C++ is not as convenient as people would like.
For instance you still have manual memory management, and lack of thread support built into the language. You might not consider that a problem, but for instance the following code isn't guaranteed to be thread safe (and on some versions of MSVC++ isn't):
void foo() { static bar = new blah blah blah }
Using languages and runtimes like Java or C# helps with these issues as they were designed in from the start.
Re:I didn't read all of it but... (Score:4, Insightful)
It offers everything that they do? I've been coding C++ for a long time, where are my web service classes, my xml parsers? It's easier to use a single interface than have a ton of different libraries that can cause dependancy hell.
Some people complain that C++ is too complex, but as Java and C# mature they are becoming just as complex.
Java and C# are a lot easier than C++. A simple example:
The C# one looks less intimidating. If a new developer sees both, I'm sure the only thing that might keep him from going to C# is the small speed tradeoff.
Why not make it easy get the best performance out of your hardware
JITed languages are only noticeably slower when GUI is involved. A JIT can also produce code specialized for your exact hardware- something a C/C++ compiler can't do.
As for cross platform compatibility... Both C and C++ are extremely portable. It's the API's that are not always so easy. However, this is no different than Java or C#. At some level you're using a C or C++ subsystem that needs to be ported to each platform. Why not just use it in the first place?
What is better: Porting only a single application, or porting every application? That is an especially strong question when business is involved. Creating portable C/C++ code can be challenging when you have to migrate between Linux, Windows, Mac, 32bit, 64bit, and some guys cell phone. Portable C/C++ will be bigger and look a lot uglier than equivalent Java/C#.
GNOME is GNU. Mono is hostile to GNU. (Score:5, Interesting)
Re:GNOME is GNU. Mono is hostile to GNU. (Score:5, Insightful)
This is important as, if they do charge, the Mono project would no longer be able to release a GPLed CLR or compiler. Even a 1$ license on the patent still means it would be GPL-incompatable.
Personally, I don't see why anyone should move to Mono. I'm perfectly happy coding in Python and Ruby until Parrot hits 1.0, when (in theory at least
Re:GNOME is GNU. Mono is hostile to GNU. (Score:3, Informative)
We think we have a better implementation so we keep going forward with that. I don't think we're even competing since DotGNU seems to have different targets than us: for example the reason we built a JIT from the start is because we want Mono to be an efficient developer platform that enables people to move away from unsafe and difficult to use langauges: this of course would be not compatible with an interpreter design which is slow. By all means continue with the DotGNU
Re:GNOME is GNU. Mono is hostile to GNU. (Score:3, Interesting)
Here are two clear examples of hostility coming directly from Mono project leader Miguel de Icaza:
XUL (Score:4, Informative)
Michel
What happened... (Score:4, Insightful)
I think this is going to bite them in the ass. Instead of putting all of their eggs in one basket, I think a better focus would be to improve all of the bindings to higher level languages. I'd REALLY like to be able to code for gnome in Lisp, but the bindings just aren't there.
Mono and KDE seem to have the right idea. They're making what looks like a first class development platform. With the limited time I have to code, if the development platform is working against me, I'm going to drop it. Gnome's development tools are awful. Kdevelop is much better, and Mono looks promising.
And wasn't this the whole point of basing Gnome on Corba in the first place, so that you could later incorporate objects from other languages? It seems to me like they haven't thought this through at all. Use of Corba seems to be extremely limited...probably because it's a pain in the ass to use and the project has done little to make it easier for developers.
If I could suggest a direction, I'd say concentrate on Gnome the development platform, instead of Gnome the Environment that Launches Mozilla and OpenOffice. The developers they'd attract will then take care of the rest. Solve the language interoperability problem, make sure bindings are up to date, and the apps will follow.
Re:What happened... (Score:3, Informative)
Err...it hasn't changed a bit. They added support for one more language, to the other ones out there. A lot of people that bitterly hate C# went nuts over it, and have been happily misquoting Miguel and thinking that the sky is falling.
If you don't like to use C#...hey, don't use it! Use C, or C++, or perl, or Java, or whatever language you like to code GNOME apps in. If you like Lisp languages, look at cl-gtk or clg.
Re:What happened... (Score:3, Redundant)
But...they haven't. The only languages supported acceptably in the environment are C, C++, and Python. Maybe Perl. Maybe Scheme. I haven't checked lately, but I doubt it. With every API change they make, they break a ton of bindings, and it's tough to keep up. cl-gtk and clg are not up to date at all. Last time I checked, I couldn't compile either on FreeBSD, or run the HelloWorld example on Linux. This was two months ago.
No
YES (Score:5, Insightful)
Unix and C put a zillion little hammers into open source developers hands. This tool was FAST and UBIQUITOUS. Of course that was in the 60s and 70s where unarguably the software and computing landscape was wildly different. Now we have legions of happy go lucky open source developers running around solving every problem with their cute little hammer. They are painting (GUIs) with their hammer. They are reading and writing (XML) with their hammer. They are describing high level concepts with their hammer (ok, the analogy sort of breaks here). "The Hammer" has been a damn fine tool. It still is a damn fine tool for
So don't listen to the din of hammer bearing legions. Open Source needs a damn consistent platform to compete. Pick something. Java, Mono, Parrot... There are several alternatives. (I'm a Java developer, but CLR presents obvious benefits for integration). I think Miguel has his head on right here.
So the goal really is to follow Windows? (Score:5, Insightful)
Note #1: I am not a Python zealot. I have some criticisms of that language, but I'll still admit that it's a huge win over C#. Huge. Period. For starters, just being able to interactively test can double your productivity.
Note #2: There will be the usual claims about performance and how you really should write everything in raw machine code, blah, blah, blah. The first rule of engineering is make it work. The second rule is make it reliable. Then you worry about making it fast. There are many options for speeding up Python, the simplest of which is simply profiling and restructuring the code. After that you have specializing compilers like Psyco, and as a distant third you have C extensions.
For GOD'S SAKE (Score:5, Insightful)
AAAAAAAAAAAAAUUUUUUUUUUUUUUUUGGGGGGGGGGGGGGGGHH
What is *wrong* with you people?
GNOME is not "switching" to C#. Linux is not "switching" to C#. KDE is not "switching" to C#. the FSF is not "switching" to C#. Miguel de Izca is likely to produce his next app in C#. Much like the other eight million languages on Linux (including Java, rep, perl, ruby, and God knows what), C# now has Linux support. It also happens to have GTK/GNOME bindings, like a whole hell of a lot of other existing languages out there. That's *it*. Jesus.
C# is a good language, but it is a far cry from Python, for example.
Great. Use Python. There are GNOME and GTK Python bindings. I suspect KDE has Python bindings. Code in Python to your heart's content. There are a handful of people that would like to use C#, and now they will use C#.
Re:So the goal really is to follow Windows? (Score:5, Insightful)
From the blog, Havoc writes:
My view, which will doubtless get me flamed, is that these languages [python, etc ]aren't really the right thing for writing large desktop apps such as GNOME or OO.org
I'd be really interested to hear Havoc's reasons for this comment. I've written quite a lot of (smallish) desktop apps in Python (most of the ROX ones, in fact), and it seems ideal. I've also used Java quite a lot.
Python is in many ways similar to Java:
- Platform-independant bytecode.
- Fully OO.
But it has differences too:True, you loose static type checking. However:
Re:Python (Score:5, Insightful)
Read about Duck Typing [everything2.com] on e2.
Java, still around eh? (Score:4, Insightful)
Ever since I started to work in computers years back java been around as the great solution. First it would change the web. Remember all those applets? Gone. Then it would change web pages on the server. Well that is still hanging around but I see more perl/asp/php then java.
It was supposed to be cross platform. Well I use the azureus bittorrent client and it is indeed cross platform. It is also a bit of a resource hog.
And that really is my problem. While intrestting in many ways java has always left me with the impression that its insides are a mess or the people who code for it are on 2gig memory machines.
Lean and efficient are words I look for in my desktop. Java would not be the first language I would think off.
For years people been predicting the death of C and it hasn't happened yet. Could this be a clue? That perhaps all the pretenders are just that? Pretenders without any hope of ever coming close to the true king of programming languages?
If this guy really wants a mono or java desktop then let him fork gnome and code it his way. Prove that java/mono is the better way.
Surely that is the opensource way? He got an itch, let him scratch it.
As an aside, anyone know how much of suns java desktop is actually written in java?
Re:Java, still around eh? (Score:3, Insightful)
Then you must not be paying attention. Servlets/JSP is HUGE, especially in "middleware", non-end-user-visible stuff (although there are plenty of major sites run on Servlets/JSP).
some postings here scare me (Score:3, Insightful)
In either case, you get secure memory management, secure code signing / redistribution, remote objects, clean OOP, and many many things the absence of which causes so many problems/bugs/exploits in C/C++ world.
The question is not if, the question is when. Portions of Windows 2003 server are already in managed code. Longhorn will be 100%. What will Linux have at that time to counter it?
Continous flame wars about which set of bindings to use?
I was impressed by the thoughts expressed in the original article but some slashdotters plainly scare me. Linux has no chance on the desktop and will face the sunset on the server if the move to managed code does not happen.
Unix-style fragmentation won't kill Linux, but the thought fragmentation will.
XAML or ???? (Score:3, Insightful)
MS is successful because it makes programs people want... regardless how much the design of those programs suck.
XAML, depending on it's design, gives us a great place to leverage the Unix desktop. Consider (if) it is a generic UI describing XML document... whose to say weither it's rendered using Windows or GTK? At the same time, we would be promoting XAML.
So, we need to decide. Do we implement XAML, or do we make our own better version? I for one think we should at least take a look at XAML, if it sucks, we should make our own.
Why can't the w3c define the schema for such a document?
Re:XAML or ???? (Score:3, Informative)
XUL [mozilla.org] already exists. XAML is a XUL feel-alike, like C# is to Java.
Pah. It always takes Microsoft to bring already-existing ideas into the spotlight.
I'ld like to hear more about the Parrot... (Score:3, Interesting)
Quoting from Havoc's blog:
Unfortunately, Havoc says nothing about why he thinks the Parrot will not be the right thing: he merely asserts his opinion. My impression is that Parrot and Perl 6 development are both moving forward satisfactorily and offer the underpinnings needed for major projects. And of course are right in the center of open source development.
So what am I missing? Are there inherent structural flaws in these languages or the Parrot? Or do others share my personal opinion that Perl, Python, and Ruby are mostly out of favor because they aren't 133t enough to separate programmers from lusers?
(I thought this thread was sort of cold but perhaps throwing this gasoline on it will create some heat and maybe even some light.)
1337 and lusers (Score:3, Interesting)
It appears that Java programmers are considered the VB monkeys of today, so I don't think that's it.
Quite a few only use the languages they are taught at school, and with which they think they can get a job (those that don't have one or are afraid of losing their current job, that is). Therefore they avoid anything "exotic".
OTOH, avoiding Perl mak
XAML: hierarchical storage of application data (Score:3, Interesting)
Rant:
Reading The Fine Article(R), I found it unsettling that people are seeing XAML as a potential substitute for both HTML and programming, and haven't yet articulated an answer, even if a derisive one.
If it was the first time I took a real look about XAML, from the first few paragraphs of MS' introduction to it, it is clear it amounts to storing UI and other application data (not organisational data used by the application, but data used to build the application itself) in XML, that is to say, hierarchically.
Just as every time one talks about XML and data in the same breath, or OO and data, this would be a throwback to 35 years ago before Codd had defined and published the Relational Model for database management.
This is specially worrying because we see many free software advocates, and most of new hackers, married to OO instead of fundamentally saner functional programming, even if it is a marriage of convenience just to get things like garbage collection that are included in current popular OO platforms; and it is specially disappointing given that Gnome now is giving thought to a saner if partial answer, namely Gnome Storage.
Marrying Gnome Storage with some functional programming over .Net or Java perhaps could by us some sanity back, but I feel it like a kludge unlikely to produce significantly better.
Going Java or .Net may be an intelligent way of trailing MS. But to really leapfrog it where now they have a huge advantage -- and that's not now the desktop as in an user environment or office automation apps or games, but custom software development for businesses with Oracle Developer, PowerBuilder, VB, Delphi and the like --, we have to present something fundamentally and conceptually better.
Something like a functional flavor of Alphora Dataphor integrated at the systems level since the installer could be the answer perhaps; while this would be a tall order for the near future, having it in sight for, say, twenty years in the future while implementing it step by step -- for example, first the D-compliant RDBMS interfaces, then an upwards- and downwards-scalable RDBMS engine with a quasi-SQL interface for backwards compatibility, then integration in the OS, then POSIX interoperability --, would give us the initiative and reduce MS to yet another platform direction change in the future, while we'd be able to keep our perfect POSIX backwards compatibility.
Question on C# vs. Java (Score:3, Insightful)
The author calls for an open Java VM (which is a very good call IMHO), the natural assumption is that the runtime would execute Java bytecode, as it should. Is there a reason why C# couldn't be compiled to Java bytecode, and if so, then could extensions be added to accomodate non-Java languages?
I agree that Linux needs a solid front, but many of the issues raised speak to factions that want their technology to reign supreme on Linux. Why not have a runtime that runs all languages and let the coders decide which to use?
Aside, excellent insight into the purpose of XAML. You've got to realize that Internet Explorer Longhorn Edition is going to fully support all of the vector-based rendering APIs available to XAML's GDI/GDI+ predecessor. This means a full-featured GUI that can use a rich set of Microsoft's controls will be able to execute from inside the web browser using the same code you'd write for a local application. This is a huge deal, and whether it be XUL or something else entirely, Linux needs a equivalent alternative.
Why not embedded scripting? (Score:3, Interesting)
This doesn't seem like brain surgery to me...but then again, I am perfectly happy running Zope and kicking out web apps - or throwing together a python/Tk app if I need a gui for something on my desktop. I know...I am in the minority.
how about OpenStep? (Score:3, Interesting)
We're missing the point (Score:3, Insightful)
Look at what Microsoft is doing. They've created a platform with the CLR/.Net infrastructure. They have language products like C# and VB.Net (and J#, but no one's THAT big of a sucker) that allow the application programmer to choose a language in which THEY will be productive and/or feel comfortable. But guess what? The same resources (GUI / Network / DB / Web / etc.) are available to both. In fact, a VB.Net programmer and a C# programmer can each work on the same project and have everything work right together. Wanna know why? Because the USEFUL tools Microsoft has already written (in fast, native code) are accessed via the CLR and both programmers' code get converted to the same IL. Microsoft has created a unified ABI that all of their managed products use, so that it doesn't matter what language is chosen, you get to use all the neat toys that come with the PLATFORM.
And that's what we need. We need a virtual platform that has the following attributes:
1. Comprehensive and useful framework. It should be tuned to the needs of MODERN applications, i.e. it includes a full-featured GUI, a useful Database interface API, Network APIs, etc. The key is to provide a comprehensive foundation that programmers can use to create their apps so that they only have to write the code that is unique to their problem, not recreate infrastructure useful to many apps.
2. Provide application portability. It should be accessible only to applications via an architecture-independent bytecode system, so desktop applications written for the virtual platform will run unaltered on all compliant IMPLEMENTATIONS of this virtual platform.
With a modern JIT-ing virtual machine along the lines the JVM and CLR, the vast majority of non-platform code will run "fast enough". Making the platform bytecode engine able to pre-compile speed sensitive sections of user bytecode to native code after delivery should satisfy most people's "need for speed".
3. Have native speed. Each implementation of the platform must be written in blazingly fast native code, including the GUI! If the goal is to provide an extremely productive framework that allows developers to make useful programs in less code, it follows that the resulting programs will spend most of their "time" inside of platform code. Thus, it's gotta be FAST!
Let's be honest: Sun made a strategic mistake with writing Swing in Java. While it made it easier to only have to implement a full-blown GUI once, it was so dog-slow that until recently no one really took it seriously and it has acquired a bad reputation. In hindsight, they would have been much better off at this point to have implemented Swing natively on all supported platforms, as they do the core elements of the JRE.
4. Available to all. It must become as ubiquitous as we can make it. That means all OS platforms and that it can't be just for free/Free apps. If you want to maximize productivity for desktop programmers, it needs to become the "de facto" standard. If you're going to learn to program, THIS is what you should be able to learn at college and at your local "Learn to be a Computer Geek" training programs. If possible, implementations should be Open Source. Regardless, the platform itself needs to be protected by a community process or other trustee system to prevent hijacking by commercial interests. The idea is to provide, as a community of individuals and businesses, the infrastructure for us all to be productive.
What everyone is wrestling with is that a platform with all of these features does not yet exist. There are many platform or platform-like frameworks out there that provide some or much of this, but none of them do it all. Worse yet, the two platforms that are the closest to achieving the technical
And no mention of D... (Score:3, Informative)
This seems like a natural fit for developing desktop applications that don't feel like they're running under a VM, yet they are still garbage collected.
Don't Discount Firefox/Mozilla (Score:4, Interesting)
Those technologies offer a standards based means of doing UI's. The web isn't going away, and gradually browsers are getting closer to what we can do on the desktop. There are folks having some luck extending Javascript with Smalltalk features [technicalpursuit.com].
There already exist well supported compilers for Javascript-and those could be highly optimized with the right effort.
Javscript is _already_ well supported by Microsoft(they are supporting it as one of the major languages for the Windows Scripting Host). IMHO VBScript is just plain too buggy and ugly.
IMHO languages like Python/Perl/Ruby the best mainstream tools for Server Side Development(though Mozart-Oz [mozart-oz.org] has some interesting features). Client side? The browser appears to be the client of the future--and folks doing desktop stuff had best figure out how to deal with that.
A Mono developer's perpective (Score:4, Informative)
I'll try to address some of the issues Havoc presented. Of course, I'm a Mono developer, so I'm biased, but hopefully people can see my arguments are more on the technical side than advocacy.
No rewrites please: this is a very important point: we can't just throw away the current code: we need incremental changes to not disrupt stability and compatibility. I'll just note that using Mono (and C#), interoperability with existing C code is much easier than with Java because of P/Invoke.
Calling managed code from C/C++: Havoc says it's hard, but Mono provides an easy to use interface to do that. Mono is designed to be embedded in existing applications, not just as a runtime for standalone completely managed programs. Also, it would be easy to create a shared library and header files to access managed methods seamlessly: they can be automatically generated thanks to the use of Reflection and the Mono embedding API.
I'm not sure a "simple native component system bridge" would solve the issues, mostly because simple systems are always found later to be incomplete, they get changed and become big, but with all the design warts needed to make a simple design work for not-so-simple constraints.
A minimal Mono system is currently about 2 MB on disk, but no effort yet has been put into reducing it (and I think it's entirely possible, we have been busy implementing features and leaving aside space optimizations). Of course, since the default build of the core assembly has lots of features, much of the reduction in size could be achieved by trimming features that other systems don't have:-). Even without trimming, most people will concour that 2 megabytes of disk space for a shared component is small enough in a desktop setting (and applications compiled to IL code are usually much smaller than comparable C apps anyway).
Community should decide: of course, I agree. Anything that is pushed down our throats by somebody else is not going to work for the free software and open source communities. The solution will need to be choosen because it actually solves issues the developers and the users see. Java had several years to try to attract developers from our community and it had some success in some niche areas (not for desktop applications, though). Mono has just started, but from the comments of the developers that actually used it to write new applications or port existing ones from C, it looks like we are on a good adoption path (even though we didn't release a 1.0 version yet, we are still working on debugging support and documentation is sparse).
Havoc fears the adoption of Mono or Java for the desktop would alienate people and cause forks. I don't think that will happen with Mono, because Gnome will continue to have a diversity of developers who'll prefer using the C libraries directly: Mono allows to keep and interoperate with existing code very easily and we want the migration to happen incrementally, so at first only end-user applications would be written in managed code, while the foundation would still be in C (at least, enough of the foundation to have people happyly writing their own apps in c or with the existing bindings). At that point, when a managed execution environment has proven itself to both developers and users (hopefully) we could start discussing about using it for the foundation, too, if that makes sense. I think Mono is positioned better here to allow this incremental shift of both development and espectations towards a managed runtime.
Problems with a .Net clone: Havoc claims that MS controls the platform
because, even if the core is unencumbered, some assemblies are tied to MS
technologies and there is non standards body or community momentum to build
alternative solutions for a complete platform. Well, considering that until
a couple of months ago there were 5 people developing mono, we have achieved a lot,
not only in the implementation of the runtime, but also, thanks to the large
commun
Re:Eeek... (Score:3, Insightful)
So when I write code for my company in Prolog, using some obscure graphics library that was written in Sumerian by thirteenth-century monks, I'm sure that there will be no conflicts in someone else extending my work. If I leave my company, I'm sure they won't have any trouble finding someone of comparable skill with experience with those technologies.
There's value to "use what you know", but if we can slowly get everyone familiar one or two core APIs/languages/frame
Why Linux will never beat Microsoft or Apple (Score:4, Insightful)
>"Do not integrate, do not unify, be free."
If I have Windows, I download a Windows binary and USE it (ok, I might have to choose the Windows version, but that's all).
If I have a Mac, I download a Mac binary and USE it (ok, I might have to choose the MacOS version, but that's all).
If I have a Linux or BSD distro, what do I need to do? Why are the end-users asked to know what their OS is? What the hell is a dependency? Why should I have to know how to compile (or even know what "compile" is)? Why can't something for Mandrake/GTK work on Slackware/Gnome?
While I agree that choices are good, this is what is slowing down Linux development (too many options to support) and is also what confuses the normal end-user (can't even *choose* what to download, I won't even get into installing the damn things).
Stop thinking as programmers and stop saying immature things like "the user should understand his PC, know about KDE/Gnome, X, insert_random_lib_name_and_version_here", because last time I checked, 99.9999% of car drivers out there only know how to fill their gas and windshield cleaner tanks. But they all still own and use their cars.
We have people who can barely use Windows or MacOSX, they would have no chance in hell with Linux.
If you take this as a flame or a troll, then you're indeed the proof that you don't have the slightess clue about what end-users want/need/understand.
Microsoft and Apple understand this YEARS ago (even if Microsoft still don't know how to make decent software at decent prices).
Re:Why Linux will never beat Microsoft or Apple (Score:3, Insightful)
>If I have Windows, I download a Windows binary and
>USE it (ok, I might have to choose the Windows
>version, but that's all).
Thats why your typical windows machine is a teeming hive of virii, spyware, adware, trojans, worms, and general cruft.
I also seem to have a much quicker time of finding/installing software for my distro using its preffered install/update tool (I only have to know the name of what I want!) Than any windows chump who has to jump through hoops on various websites to find what t
That's great if you ignore interoperability (Score:5, Insightful)
Do not integrate, do not unify, be free.
Be free to have to specify each individual UI preference for every new app I use, you mean?
Be free to have to spend hours trying to get my new word processor to talk to my printer?
You're kind of missing the point re: integration, I think.
Re:Eeek... (Score:4, Insightful)
I doubt they are using Java and Mono because they are "trendy". If anyone strays more from "trendy" things, it'll be developers. We use what is best for the job, be it C or C#.
If you have ever coded in one of these languages you would know it increases productivity beyond anything possible in C or C++. They are easier to code, easier to debug, easier to manage. Processors are getting fast enough to handle the small speed decrease of using a JIT. Languages like these are the future- C/C++ will easily be phased out as much as ASM was, as soon as the JITed languages become fast enough.
I am asking same question again - why Linux world need to copy everything from Windows world? Do not integrate, do not unify, be free.
Being so loosely integrated is one of the major limiting factors on linux advancing anywhere in the desktop world. Sure- having a ton of choices is great for development and customization, but for Joe User it is hell to have to learn so much crap to get things working. And if he asks his friend for help, chances are the friend will be using something entirely different and not be able to give much if any.
While Windows has it's faults, it is king of integration. It is also the driving force for a lot of new technologies. It sucks, but unless Linux apps want to be left behind, they have got to be more like Windows apps. Copying from them is OK in my book, so long as they don't copy MS's security practices
Re:Eeek... (Score:3, Insightful)
In practice, though, KDE development isn't as much in C++ as in a greatly enhanced C++/Qt/kdelibs environment. There's a huge difference between being able to draw on all that extra functionality and working in stock C++.
Re:Eeek... (Score:3, Funny)
Thats an easy one to answer. We could cut to the chase and just copy everything directly from the Mac, but it is easier to let Windows copy it from the Mac first to work out the portability kinks... Then we can copy it and do it right the third time in Linux :)
They most certainly are the way to go. (Score:3, Insightful)
Computer time is a flow. Every 18 months, hardware is roughly running twice as quickly.
Arguing that virtual machine based software is inefficient is like arguinig that MPEG layer 2 audio compression is supperior to MPEG layer 3 because it takes less CPU time to decode (or MP3 vs. OGG Vorbi
Re:One word... Smalltalk... (Score:4, Insightful)
HOWEVER - these are things that could be remedied.
The people who get twitchy at the prospect of a virtual machine should try Smalltalk on a 16mhz Palm. One of the main reasons for the slowness in Swing, for example, is that they're taking the MVC paradigm -- which was easy and lightweight in the Smalltalk paradigm -- and cruft it onto Java's statically-typed, heavier model.
I'm hoping that systems like Smalltalk and Self get more attention for desktop development in coming years, now that they're finally seeing a degree of revival for web apps.
that's OSX (Score:4, Insightful)
OSX pretty much uses that paradigm, only with Objective-C (which was based in part on smalltalk) as the language. I can vouch for the fact that it makes a nice development model.
Yes, it did (Score:3)
Linux made Unix viable again. Unix on fast and cheap commodity hardware. Open, unified Unix, instead of mish mash of incompatible proprietary variants.
Without Linux (and BSD's, which might be where Linux is now if Linux didn't exist), Microsoft would have collected the jackpot already. And rightly so, probably - proprietary Unices sucks, and if it's something I can't
Re:Python and large desktop apps (Score:4, Informative)
Nasty type errors are really rare, though. Normally, you've either done something stupid and the code doesn't run at all (and you have to test everything at least once), or the types are right.
Of course, some languages can be really helpful with their type checking. Haskell often gives some insight into the nature of some code by giving it a more general type. But I find Java tells you nothing you didn't already know.
Python has a few other problems. It's (a) slow even with tools like Psyco.
I've looked at the output of some code from psyco and it looked just like C (provided you stick to C-compatible types, of course). Python tends to off-load critical loops into C libraries (map(), etc). Java tends to be much slower, perhaps because most of its standard library is interpreted?
Re:Python and large desktop apps (Score:3, Informative)
Not in Python - it's as natural as eating or sex
The more code can be automatically verified and checked, the better IMHO.
That's why there should be tests that excercise your code. Static typing helps catch some trivial bugs, but it only goes so far.
It's (a) slow even with tools like Psyco a
I think this is the reason it's not considered for OO.org scale programs. Desktop programs need to be very snappy, and Python takes a hi