Well yes, legally they had to. Unless they were going to write a rendering engine from scratch they had to choose between Gecko and KHTML, both of which I believe require the giving back of modifications.
The annoying thing about the KHTML thing was that they kept it secret for so long, and when they did "give back" it was in the form of a huge patch dump that took volunteers ages to work through. There was even duplicated bugfixing going on there etc - in other words given the choice between working with the OSS community and letting Jobs go "tada!" in front of his followers, they chose the latter. Poor show.
Better solution is to not need a config file - quite often things in config files aren't really to do with personal preference especially in end user apps, they are just there because it was easier to slap in a pref than fix the problem.
I'm not saying it's impossible, but it's a lot harder to have Bruce Perens to talk people into doing things his way, making them want to do it than it is for Steve Jobs to say "... or you're fired."
That's true, but you've got to recognise that this is much a weakness as a strength. The "do it or you're fired" from a visionary approach can work well if the visionary dictator is incredibly smart, receptive, unbiased etc but it's just as easy to end up with dead ends like brushed metal as it is with great ideas.
I think the poor quality of Apple's package manager is deliberate. Apple don't/like/ install software: they think that you should be able to run new software straight from the CD
So why do they even provide a package manager/installer thing then? If their appfolders system was good enough, then they wouldn't need one. Are you saying they know their official system isn't powerful enough so they provide a deliberately crippled alternative? Doesn't sound like a good plan to me.
Installation programs break the spatial paradigm that is the heart of Mac OS, and Apple's documentation says this.
To have a spatial paradigm a spatial file manager helps. This is something that Apple has moved away from (mostly due to the NeXT origins of OS/X), not towards, despite the usability benefits of such an approach.
Oh, and I wouldn't pay too much attention to Apples usability documentation either. Last time I checked they violated their own advice all the time - indeed, whenever they have to choose between "looks cool" and "follows the Apple HIG" they seem to choose looks cool. Sometimes they even doctor the HIG to match.
Of course, that only works if the program you want is in one of these repositories, and is up to date, and isn't badly packaged, and... and... and....
No, the original poster is correct. You cannot rely on the distro packaging everything you want correctly, even if you use Gentoo or Debian (distros that are only used by people who are skilled enough to compile stuff anyway).
Yeah, but everything has a cost and a benefit. I think what the xchat guys did here was right.
Why?
Let's see. I've used xchat a fair bit before. I have no idea what "old style nick completion" is. Gaim has as similar option - I tried switching it on and saw no difference. Whatever it is, is far too subtle for me. It's just sitting there, taking up space, and making me wonder what it does.
If every time you make a change, you need a pref to appease the old users, you end up with a bloated app full of "Old this", "Broken that" and so on. Witness KDE Klipper which basically has a "break my clipboard" option.
I've met a lot of non-technical people who really don't grok (as in, have a good understanding) trees and folder heirarchies.
These people typically have very few folders, if any. They are not characterised by having deep folder heirarchies, in fact, they may only be one or two levels deep at most.
These people do not really enjoy computing, they tolerate it. They find the computer a thing to be wary of - unpredictability is like poison to them, eating away at their confidence with the machines. I've seen this happen with my own eyes: users who get basic stuff with files and directories wrong, and who end up fearful, convinced that it's their own fault.
Often, it is. They saved the file in the wrong place, or had two directories with the same name but in different places and got them mixed up etc. All very easy mistakes to make if you don't naturally think in terms of trees.
For people like this, the spatial system is really, really great. They don't have deep heirarchies so lots of windows popping up isn't a big deal. They love predictability. If the window for a folder opens in exactly the same way it did last time, that's brilliant - nothing changed, so by definition they did nothing "wrong".
For people like us, who often have lots of files, deep directory heirarchies, it's perhaps not so great but as the review noted it's trivial to go back to the old system, or use keys/middle button to work around the window clutter. So really we lose little - in fact, I never really use Nautilus for my file management at the moment anyway, so the only possible change for me is that I gain something.
Basically, you've got to realise that spatial nautilus isn't meant for browsing your source code directories. It's meant to help the very large number of people who can benefit from this model. There's a reason Apple used it in the old pre-OSX systems.
Apparently an incompetent Slashdotter believes that the POSIX APIs are enough to write a complex graphical application which magically feels native on any platform.
Apparently said person has never actually had any experience with porting software in their lives?
They do that all the time with even proprietary software - see the Sherlock fiasco. Hell the visualisation in iTunes isn't just a clone of G-Force, it practically is G-Force.
Alright, points one and two are valid, especially the one about garbage collection causing swap (and cpu cache) thrashing. I'm not really sure about one though - dangling references in any language is a bug and there's nothing the runtime can do about it. OK, so in Java you use up lots of memory - if you'd freed that window in C or C++ a crash is one potential outcome which is much worse.
The other points you raise (memory overhead, startup time) are mostly due to the Sun JVM implementation - both Mono and GCJ apps have startup times similar to native apps. In fact I have written small programs and utilities using GCJ and they perform similar to native apps - not surprising given that this is exactly what they are.
GCJ with Java-GTK outputs binaries similar to GCC with GTK, or G++ with GTKmm. Their performance characteristics are naturally similar as well.
Heh, I don't think you quite understand how huge these programs are - we're talking millions of lines of C++ (and remember that one line of C++ can easily be equivalent to 10-20 lines of C)
Well, Python is dynamically typed for one. Dynamic typing is great for scripting languages because the language gets out of your way and the rules are laxer, so you can work quicker. It's not so great for larger or more complex pieces of code where robustness is more important than having fewer rules.
Programming is hard. It's an unnatural thing for the human mind to do. The more code can be automatically verified and checked, the better IMHO.
Python has a few other problems. It's (a) slow even with tools like Psyco and (b) has a wierd non-C like syntax which is a bit offputting for people who are used to C++/Java/C# style languages.
I assume you're referring to the size of libgcj as a reasonably complex assignment I did for a compsci class recently is only 114k on disk.
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.
I wouldn't be so quick to group C and C++ together like that. A lot of pain in Gtk/GNOME development is due to the pure C interfaces. I don't see many KDE developers complaining that they need "higher level" languages. They already use one: C++.
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
}
... because the C++ standard does not state that static constructors must be thread safe like that (it's susceptible to race conditions).
Using languages and runtimes like Java or C# helps with these issues as they were designed in from the start.
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
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.
You've clearly never spent hours tracking malloc arena corruption, insidious thread safety bugs, or enjoyed the benefits of a clean OO syntax.
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) 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.
That's accurate - the main problem is that gcc is (a) slower and (b) produces larger code than VC++ does. The gcc guys focus primarily on standards compliance and portability rather than performance, and for most apps it doesn't really matter. Many games though are absolutely huge pieces of C++ - one program TransGaming worked on took 20 minutes simply to link the end result.
The threading library with GLIB is now "operation or not" on integers and pointers.
I think you mean the threading library now supports atomic operations - ie you can do some simple integer/pointer manipulation without needing a mutex in a thread safe fasion. They've introduced equivalents to InterlockedIncrement, InterlockedCompareExchange etc in Win32 and very useful they are too.
if nobody can make money off of it, nobody will invest in the research, and no new drugs will be produced. Are you still convinced this is a good idea?
This seems more like an argument for funding cancer drug research from alternative sources rather than keeping the patent system, to be frank.
Slashdot Mirror
The annoying thing about the KHTML thing was that they kept it secret for so long, and when they did "give back" it was in the form of a huge patch dump that took volunteers ages to work through. There was even duplicated bugfixing going on there etc - in other words given the choice between working with the OSS community and letting Jobs go "tada!" in front of his followers, they chose the latter. Poor show.
Better solution is to not need a config file - quite often things in config files aren't really to do with personal preference especially in end user apps, they are just there because it was easier to slap in a pref than fix the problem.
That's true, but you've got to recognise that this is much a weakness as a strength. The "do it or you're fired" from a visionary approach can work well if the visionary dictator is incredibly smart, receptive, unbiased etc but it's just as easy to end up with dead ends like brushed metal as it is with great ideas.
So why do they even provide a package manager/installer thing then? If their appfolders system was good enough, then they wouldn't need one. Are you saying they know their official system isn't powerful enough so they provide a deliberately crippled alternative? Doesn't sound like a good plan to me.
Installation programs break the spatial paradigm that is the heart of Mac OS, and Apple's documentation says this.
To have a spatial paradigm a spatial file manager helps. This is something that Apple has moved away from (mostly due to the NeXT origins of OS/X), not towards, despite the usability benefits of such an approach.
Oh, and I wouldn't pay too much attention to Apples usability documentation either. Last time I checked they violated their own advice all the time - indeed, whenever they have to choose between "looks cool" and "follows the Apple HIG" they seem to choose looks cool. Sometimes they even doctor the HIG to match.
No, the original poster is correct. You cannot rely on the distro packaging everything you want correctly, even if you use Gentoo or Debian (distros that are only used by people who are skilled enough to compile stuff anyway).
Why?
Let's see. I've used xchat a fair bit before. I have no idea what "old style nick completion" is. Gaim has as similar option - I tried switching it on and saw no difference. Whatever it is, is far too subtle for me. It's just sitting there, taking up space, and making me wonder what it does.
If every time you make a change, you need a pref to appease the old users, you end up with a bloated app full of "Old this", "Broken that" and so on. Witness KDE Klipper which basically has a "break my clipboard" option.
If you carry on that road, madness is ahead....
I've met a lot of non-technical people who really don't grok (as in, have a good understanding) trees and folder heirarchies.
These people typically have very few folders, if any. They are not characterised by having deep folder heirarchies, in fact, they may only be one or two levels deep at most.
These people do not really enjoy computing, they tolerate it. They find the computer a thing to be wary of - unpredictability is like poison to them, eating away at their confidence with the machines. I've seen this happen with my own eyes: users who get basic stuff with files and directories wrong, and who end up fearful, convinced that it's their own fault.
Often, it is. They saved the file in the wrong place, or had two directories with the same name but in different places and got them mixed up etc. All very easy mistakes to make if you don't naturally think in terms of trees.
For people like this, the spatial system is really, really great. They don't have deep heirarchies so lots of windows popping up isn't a big deal. They love predictability. If the window for a folder opens in exactly the same way it did last time, that's brilliant - nothing changed, so by definition they did nothing "wrong".
For people like us, who often have lots of files, deep directory heirarchies, it's perhaps not so great but as the review noted it's trivial to go back to the old system, or use keys/middle button to work around the window clutter. So really we lose little - in fact, I never really use Nautilus for my file management at the moment anyway, so the only possible change for me is that I gain something.
Basically, you've got to realise that spatial nautilus isn't meant for browsing your source code directories. It's meant to help the very large number of people who can benefit from this model. There's a reason Apple used it in the old pre-OSX systems.
By definition a KDE app has to be a Qt app, as the KDE APIs are built on top of Qt and rely on them in almost every way.
Apparently said person has never actually had any experience with porting software in their lives?
They do that all the time with even proprietary software - see the Sherlock fiasco. Hell the visualisation in iTunes isn't just a clone of G-Force, it practically is G-Force.
There are two X servers at freedesktop.org now, both with stupid and confusing names but hey :)
1) Xserver - this is the new experimental one that does pretty drop shadows and stuff. Not really mainstream yet. This is the fork of kdrive.
2) Xorg - this is the fork of XFree before the licensing change. It's not experimental and is usable just like XFree is.
Hope that helps
I'm unsure whether I should feel sorry for your partner or not...... ;)
The other points you raise (memory overhead, startup time) are mostly due to the Sun JVM implementation - both Mono and GCJ apps have startup times similar to native apps. In fact I have written small programs and utilities using GCJ and they perform similar to native apps - not surprising given that this is exactly what they are.
GCJ with Java-GTK outputs binaries similar to GCC with GTK, or G++ with GTKmm. Their performance characteristics are naturally similar as well.
Heh, I don't think you quite understand how huge these programs are - we're talking millions of lines of C++ (and remember that one line of C++ can easily be equivalent to 10-20 lines of C)
Programming is hard. It's an unnatural thing for the human mind to do. The more code can be automatically verified and checked, the better IMHO.
Python has a few other problems. It's (a) slow even with tools like Psyco and (b) has a wierd non-C like syntax which is a bit offputting for people who are used to C++/Java/C# style languages.
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.
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.
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.
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.
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) 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.
That's accurate - the main problem is that gcc is (a) slower and (b) produces larger code than VC++ does. The gcc guys focus primarily on standards compliance and portability rather than performance, and for most apps it doesn't really matter. Many games though are absolutely huge pieces of C++ - one program TransGaming worked on took 20 minutes simply to link the end result.
I think you mean the threading library now supports atomic operations - ie you can do some simple integer/pointer manipulation without needing a mutex in a thread safe fasion. They've introduced equivalents to InterlockedIncrement, InterlockedCompareExchange etc in Win32 and very useful they are too.
Of course you shouldn't read that unless you also read the the rebuttal - apparently a lot of what is in Ross Andersons FAQ is flat out lies.
This seems more like an argument for funding cancer drug research from alternative sources rather than keeping the patent system, to be frank.