You were 'forced' to start working on Git as a result of Jeremy Allison's reverse engineering of the BitKeeper protocol and Larry McVoy's hostile reaction.
At first you weren't too enchanted about the waste of time having to write your own DVSC system from scratch for lack of acceptable alternatives. I remember you complaining about that work preventing you to progress on the kernel.
Now Git is becoming the de-facto tool for source control management in most F/OSS communities and inside companies. That's another very successful project you fathered, and while I guess Mercurial or other projects would have existed anyway, the usage of Git on the kernel has demonstrated its reliability and its performance and traction have made DVCS'es gain visibility and market in no time.
Here come the questions:
* Are there any features you still miss from BK? * As a happy Git user, I thank Jeremy Allison for his refusal to accept compromise and his tentative to create a Free BK client and I thank you for your refusal to accept a technically inferior/ill-suited solution like SVN. How do you reflect on this?
We have had different experiences. When I started using it, I definitely struggled many times with OSGi (or more like setting up some containers for my specific needs), but not any more than I did with any other 'advanced' framework (including JEE). But on the (full-OSGi) project I'm working on, OSGi is not costing us anything. We're doing agile development (Scrum) and we're very much feature driven. If we were wasting too much time fighting against OSGi, I'd totally agree with you. But we're not. And our team has members that are just "Java developers" that don't know the specifics of OSGi that much, but we integrated OSGi best practices into our coding guide and it's working well.
In fact, I think OSGi is costing us *less*, because for an application like the one we're developing that requires modularity, we would have ended up writing our own inferior, more expensive and most of all not standardized "plugin system". In fact, in my company there are many different kinds of modules systems that were previously developed and we can't easily exchange modules between those systems (developed for different projects, clients, etc). With OSGi, we can start to share more than just classes or jars. Good bundles do half the integration work.
Anyway I'm not trying to convince you. OSGi is no silver bullet, and it can be difficult in practice when you're plugging into legacy. But when it's working, then it's really nice. My non-OSGi inclined co-workers even grew to like it.
I do agree there's a problem with legacy Java code that makes use of features that are hardly reconcilable with OSGi. I think most of those libs that don't get along well with OSGi are doing something wrong, but sometimes they're trying to be too smart;). Incompatible legacy code is pretty much the only reason one should run classloader issues, because frankly I find OSGi makes things easier here (especially if you generate your manifest with bnd, which avoids most of the mistakes). One way or another, I agree we most often have no choice but to use those libraries (legacy or not). We can't know "before" if the third party Jars we're using will get along well. At work, I was lucky for one huge software stack (which included C++ parts) and had basically no trouble (beside the initial pain to help my co-workers going) porting the whole thing to OSGi. Another stack is still not ported because of dependencies on those bad JARs (packages split across Jars, having API that's not theirs, etc).
A lot of Java projects are now OSGi-ready though. It's really taking off. I also agree that the tooling is not perfect yet, but it's improving. If you are using Eclipse, I recommend using BndTools rather than PDE. It's a lot less stressful.
In general, I believe the constraints clean programming in OSGi put on the developer lead to better design/architecture, cleaner separation of concerns, even if you're going to dump OSGi after that. But usually when you reach that point you usually get to like it: like coffee, it tastes bad at first. Unlike coffee though, there are too many ways to do OSGi wrong, because there's a lot of contradicting approaches around there. The common wisdom is to avoid the OSGi API when we can (it can be avoided if we don't have to register services dynamically or do framework-level stuff), but after that all hell breaks lose when it comes to testing, building, what editor to use etc. Too many dissenting voices make it long to find a non-intrusive way, but it exists!:)
Damn, I sound like a commercial, but really OSGi and DI are the only thing that made me enjoy Java. I disliked it before. Also, OSGi is a nice way to do mix polyglot JVM components and that's the "next big thing" (which is not novel at all, but all this has happened before, and will happen again...)
OSGi and DI frameworks such as Google Guice are giving Java a new life. Of course 95% of Slashdot is stuck using Perl but thanks for your review (in fact I'm mostly replying here to compensate with the retarded posts). Sprint DM have been standardized in OSGi and renamed "OSGi Blueprint Services" and while I've not used them (because Declarative Services were enough for my needs and I never was a Spring user), I plan on checking them soon. A lot of people are using Spring and this is the way to get them interested in OSGi.
By the way, another great (but free/creative commons) book on OSGi is Neil Bartlett's "OSGi in Practice". I can't recommend it enough. Unfortunately, it's still in draft so some parts are not completed, but I learnt more about OSGi reading this book than any other resource I could find (printed or online), except maybe looking at the frameworks' code directly.
A branch of the Scala IDE for eclipse shows when there's an implicit conversion by underlining the converted expression. I guess this feature will come to other editors soon enough. Also, to have this conversion, you must have imported it (or its package object). The predefined conversions in scala.Predef are doing what you'd expect them to do and aren't very dangerous (much less, than say, built-in automatic conversion in some dynamic languages).
Implicit parameters are just like dynamic default values. Not a big deal really, especially since Scaladoc hides them by default, you don't even have to know they're here. But they open for a world of possibilities to change the behavior of an API.
In general, implicits in Scala are really a powerful tool and they're useful for API designers more than 'common' users. You said it's not about FP, but Scalaz which is the FP lib for Scala uses them to their fullest extent to replace class inheritance (considered harmful) altogether.
Being myself a Scala fan, I agree with you that it is painful that Sun did not make the JVM with language agnosticism in mind, and that is the main superiority of.NET over the Java platform (the very fact that the best I can call it is "the Java platform", while.NET is not called the "C# platform", is a good hint).
Concerning type erasure, as it has been pointed out by my sibling-thread, it's a design choice. Scala also has adopted type erasure with generics. The other choice could have been made, that is encode type annotations for generics in the bytecode. There is nothing in the JVM preventing it to be done, since it can be done manually, the [alternative language] compiler can add the required info. In Scala, the choice has been made to mimics Java (and I guess, the more the generated code will look like Java, the more we will benefit from runtime optimizations). Thanks to Scala's very powerful syntax, there is a library called Manifest that automatically adds the type information and easily allows you to code as if there were no type erasure.
Still, I agree this feels like a weird rule, especially the first time you run into it. It is not the expected uniform behavior. The same goes will tail-call optimization that should be in the JVM (and should be in OpenJDK7), closures, etc. Generally speaking, the JVM should be a generic platform for languages exactly like the.NET framework is.
But I am one of those guys who wouldn't run Scala on.NET, the general anti-NET guy (not anti-Mono). Even if some legal doubt surrounding free.NET implementations remain (even with the recent community promise, but there's always a legal risk with any software you use anyway), this is purely an emotional and political decision. It's fashionable to call my kind "freetards":). Yet, I've been using and enjoying free software for a long time now, and I remember your stories (notably how you were interviewed by Microsoft and told them you would join them if they changed their business model and developed free software) so I feel you're not the last to take emotional and political decisions. Please note that I appreciate the existence of a Free.NET runtime.
You have done an impressive work with Mono. Don't you think the same effort could have been to make the [renamed] Java platform as generic and powerful at the.NET environment? Sure, there is a lot of inertia with Sun, but if someone could have achieved it, that would have been you. At the end of the day, you are still bound by Microsoft standards, are they so much better than Sun's that it justified starting a free.NET implementation from scratch (granted, neither HotSpot nor the JDK were free at the time, but there were already free partial implementations) ? I have read your reasoning at the time of creation of Mono. Of course, after all this work it is late to have second thoughts and regrets, but in retrospective, was it such a good idea?
We both know the linked article is a joke and Mono doesn't seem to be gaining any real share. Sure, C# and.NET are strong, but from what I see here Mono is only marginally used even for server-side solutions, and there is a lot of rejection on the desktop from the free software community (which I agree with, even if I have had F-Spot and Tomboy, I do think running Mono for two apps is excessive).
At the end of the day, I just regret the Mono vs Java situation created yet another division in the community. Of course, and I thank you for it, you are very much responsible for OpenJDK becoming free. And I agree that Sun's strategy regarding both licensing, evolution and genericity of the Java platform has been awful. Yet, right now, between the two, most free software enthusiasts would choose Java. There is no way to rewrite the past, but maybe there could be a way for a better outcome.
(1) Do you think Jazz could gain from a distributed model, like git does for source control management, where the repositories can be forked and kept synchronized upstream/downstream (a bit like a "progressive fork" where fixes can be shared but the project can be forked for various reasons)? I heard there is a git connector in incubation but it seems to me more than just code artifacts should be distributed. After enjoying the many benefits of distributed SCMs, it's hard to go back, and I think at least issue management could gain from the same model.
(2) Do you think creating your own SCM was the good decision, in opposition with using metadata in combination with SVN or git?
(3) Are there any plans to liberate Jazz under the EPL or another Free license, and do you believe Jazz can really gain enough traction as it is? There are plans to integrate Google Wave in the Eclipse Communications Framework by 2010, EGit is coming fast and has a lot of momentum among Eclipse developers, Mylin is getting better with every release, issue trackers are getting a lot better, continuous integration engines such as Hudson work really well... To me it looks like Free Software alternatives are going to beat Jazz at its game (not as well integrated at first), because this is typically software that companies want for free, and Free Software communities want Free Software (I know Jazz is gratis for Open Source projects).
(4) What's your opinion on the new wave of JVM languages such as Scala or Clojure? Did you try playing with them?
(5) Are you planning on participating in the development of E4? Regarding alternative JVM languages, there is a real need to refactor JDT to extract a "JVM-language" development tooling on which the specific Java - the language - tooling is built. The current architecture has been problematic to the development of good environments for alternative JVM languages (Groovy, Scala, JRuby,...) and the current solution is using Aspects with EquinoxAspects to hack on JDT (my understanding is that there are many problems with this hack). Refactoring JDT is something that would be great for E4 (and truly useful), but JDT seems very much to be IBM's turf and I don't see it coming. Any opinion on this, as the original lead on JDT?:)
Anyway, Eclipse is one of those self-updating apps with its own package manager/provisioning platform (p2). It's not really designed to be installed as a shared program, unfortunately so. As a Debian user and Eclipse developer, I don't find it such a big deal to simply decompress the Eclipse archive in the home directly.
Oh, you sound like a Redditer, sad (atheist that doesn't feel like trashing religious people here). I think you won't find a country where there is more separation of Church and State than France. The closest countries are Belgium and Turkey. In France no official swears on the Bible. In France at trials people swear on their honor, not on some mythological novel 9/10th of the population doesn't care about. In the United States it is about "all religions" OK in public, and in France about "no religion" in public.
I never figured why you "atheists" need to justify your lack of belief and disprove God's existence. Who gives a shit really? Over here in France, I have maybe met 10-15 true believers of my generation in my whole life, including a few who were simply insane.
I know it was partially true, I should remember not to be too lazy when posting on/.:).
Note that I was not talking about automatic parallelization which is indeed possible only with pure languages (and ghc is experimenting on it); but simply about the fact that is is easier to parallelize an application with immutable data structures since you need to care a lot less about synchronization. For instance, the Erlang actors model (also in other languages like Scala on the JVM) still requires the developer to define the tasks to be parallelized, yet immutable data structures make the developer's life a lot easier with respect to concurrent access and usually provide better performance.
My "It is true" was referring to "functional languages" which do usually privilege immutable data structures, not to Haskell or Lisp specifically (which as you said has many variants with mutable structures focused libraries). As you said, Clojure is itself a Lisp-1 and it does privilege immutable data structures and secure concurrent access with Refs/STM or agents. What is more interesting in the Clojure model (compared to Scala's, since they are often compared even though their differences, as functional languages and Java challengers on the JVM) is that it doesn't allow unsafe practices (all must be immutable except in variables local to a thread, etc).
Because they are "Open Source" business-minded and not "Free Software" supporters, meaning they don't give a fuck about providing a full Free stack. I have come to the tragic conclusion that most Open Source contributors are now running Windows.
On the other hand, would they care to make their software Free if it weren't for the Open Source movement? At least we can port the best written software (if its core is not too tightly-coupled to Win32 APIs), so still better than nothing. The biggest problem is that it completely overshadowed the moral aspects of Free Software, which are now to of many corporate Open Source developers nothing but a joke under the pretense of pragmatism and practicality.
So instead of telling developers to abandon tools which make their job and life easy, how about requesting Linux developers to make game development a little easier?
The problem is that there is no such thing as "Linux developers". Afaik, OpenGL is maintained by the OpenGL ARB and it looks it needs more support. I agree it is inferior to DirectX, however it is not by abandoning it that the solution will improve. Windows game developers are responsible for the situation by adopting DirectX and succumbing to Microsoft's charms so massively. It's Microsoft, everyone saw it coming.
Anyway, I was not talking about the quality of the API but the achievable end-results which are close to DirectX equivalents (the proof is that Wine translates DirectX to OpenGL and games don't end up looking so bad). I would rather have slightly worse looking games and having them run natively on Linux.
OpenGL ES is a strict subset of OpenGL and the UnrealEngine2 can run under Linux natively. The 3rd version doesn't run Linux/BSD yet (afaik) because I guess it is not a priority, but I don't see why it couldn't.
For being a developer on a cross-platform game (using SDL but knowing how to do it in a "lower-level" way with X / ALSA), I can assure that while it's not perfect, the sound & mouse events is a non-issue. It's only a matter of reading doc... of course the development environment could be better, but it won't happen magically: even in the best case scenario, it will happen gradually if games are release natively.
Thanks for the link! It doesn't look bad even if I am not very much into realm/faction-based MMOs. However the RTS part seems really nice! Players can even run their own server. Their forum, which is usually a good indicator of the community, looks civilized and written in proper English. I have found that Linux games tend to have a more mature community. I will try it when I have some free time.
I also know of Regnum Online which has a native client, but having played it I can tell it's utter shit and I'll spare you the link. If you are masochist, use Google:).
Actually, I am rather selective for MMOs, it's easy to get addicted even to bad ones. I dream of Mortal Online with a native Linux client.
Unfortunately this will be buried in the mass of posts, but I'll go anyway.
If a game developer releases his game for Mac and Linux as well, maybe that's 10% market share but it's not the same market share! It's really disappointing to see this fact so often overlooked. Because not all users are the same. Mac and Linux users are DYING to play games. Meaning that a lower market share could still have higher game adoption.
For instance, take MMOs. There are no decent MMOs running Linux natively. As a former Ultima Online player now reconverted into a Free Software enthusiast, I would love a good MMO to play. But I will not use Windows.
The market for MMOs is *saturated*. If you publish yet-another-MMO, whether it's for a niche market of players (hardcore MMOs such as DarkFall of Mortal Online which I would love to play) or another WoW theme-park-MMO clone, you still have to convince Windows players to buy your game and pay the monthly fees. The Linux desktop usage may be lower, there is NO competition for MMOs. Meaning all suckers for MMOs like me would play if the game is any good.
In fact this applies to most games because the market is saturated. It is better summed up by the Lugaru game developers.
IMO, game developers are only missing opportunities. Once they release for Linux and Mac, desktop usage will raise and more people will favor their games over their Windows-only competitors.
Last argument is that "Linux users only want free". This is wrong. Windows users are a lot more about cracking and pirating. If Linux users see something of value, they will no doubt buy it to encourage companies to continue. Most Free Software enthusiasts have no problem with proprietary games because it can be considered a piece of art rather than a piece of software. At least art resources (graphics, music) need not be free, even RMS says so:). And we *are* desperate for good native games.
So (to game developers), stop depending on DirectX! Use abstraction layers between DirectX and OpenGL. UnrealEngine 3 works with both, and considering how advanced it is, I don't want to hear shit about how OpenGL is not as good. It will only get worse if game developers let it die. And release NATIVE support for Ubuntu and Fedora. The community will make sure it works on other distributions.
And, it is also possible to (gasp) add proprietary code on top of a GPL project too. It simply takes a bit more work. Several companies have been doing this with Linux for years. Here's how to do it:
1. Submit hooks into the GPL code back into the GPL project. These hooks will be used to connect your proprietary code into the GPL code. Most likely these changes will be rejected by the project. Who cares? You've done your bit.
2. Now use the open source hooks that you submitted, but were rejected by the GPL project to create a new GPL project that includes those hooks. Can't stop you from forking a project!
3. Now build the proprietary layer of your code on top of the hooks. As long as you are dynamically linking into the GPL portion of the code, you are safe from the GPL license. Otherwise, you wouldn't be able to run any proprietary third party application on a Linux box. If that was the case, IBM would have dropped Linux a long time ago.
4. Rake in cash by leaching off the GPL software project!
Nope. Your "loophole" doesn't exist, you cannot link either dynamically or statically on top of a GPL'ed piece of software without your code being GPL'd. But as with all copyright infringement (which is exactly what you are describing), a copyright owner has to complain / sue you. In the case of proprietary Linux modules, they are tolerated by Linus and other kernel developers because they feel they add value anyway. So it's a tolerance that might as well stop tomorrow.
Why is Nvidia safe? Because they don't themselves distribute GPL'ed code. They only distribute their modules which are very similar to Windows or Mac drivers. The only Linux-specific parts are the interface/hooks and this is rarely considered as derivative work (it really depends on the interpretation of the judge at the trial), so that's how far the legal uncertainty goes for Nvidia.
If the user himself links proprietary to GPL'ed software, he is safe: the GPL has no provision preventing the end-user from any usage. However, the ones who are distributed GPL'ed software automatically linking proprietary modules to the kernel are.... Ubuntu and other distributions (note that Debian does not). They are actually the ones most likely to be sued if a kernel developer with copyright relevant to the graphical subsystem in the Linux kernel (or some code from which it was derived) wanted to go against the flow (because, most kernel hackers stopped caring even if Greg K-H complained about it, and obviously Linus doesn't give a shit because he's "rational").
Now, do the same with a GPL'ed project whose copyleft belongs to the FSF and it will be another story altogether. I think it might hurt:). So what you're saying will work only if the original authors don't want to enforce the GPL for a particular case, and you should ask them first -- they will never say they don't care officially, but you can still test the water if you like to play.
I agree this licensing stuff is tricky, but the GPL actually works and makes sense (but if I lack sleep I can't wrap my head around it).
I'll reply to you but I could as well have replied to the other hundreds of similarly ignorant posts. The difference I guess is in your uneducated (dare I say moronic) title.. When you ssh a GNU/Linux server, it *is* free because you have access to the DATA (and to the free software using it). When you are doing "local computing", data access is guaranteed so the focus so far was on software freedom. When you do "remote computing" (ie cloud computing, SaaS, etc), the notion of *usage* Freedom needs to be extended not only the software, but also to control over the data as well as the guarantee that the software running (or at least the data managing parts) is the software you can obtain.
Reading the article and past RMS interviews, this interpretation seemed obvious but you are so many calling him stupid for stating that simple fact yet not even understanding how obvious it is that it ends up being a pathetic flame-fest. In fact, the most important aspect of remote computing is the control over your data (at least the ability to get it back) in a standardized way so that even if you don't have the software that's running on the other end, you can have a free software of your own do it.
Next time maybe you can read, and if you did, try understanding. Sorry for the rude tone but so much ignorance or ease to go flame gets on my nerves.
Now you may disagree and think that it's OK if you spent 2 years uploading data on facebook that is totally yours (your inputs, your personal life, your photos, etc) and can't even get it to process it yourself or upload it to a (better) competitor, that's your problem. RMS is only saying one thing: Free Software is about control over the data, and if you do remote computing, then you need more than just Free Software to ensure the very freedoms that the FSF is trying to defend. Sorry, but he makes sense.
It IS possible to do SaaS in a way that guarantees control over data and software freedom, that's just not what is being done.
Slashdot Mirror
You're right of course. Thanks. I remembered it was a Samba dev. and I got the wrong one. Too bad we can't edit posts :-).
Indeed. Thanks for the correction.
You were 'forced' to start working on Git as a result of Jeremy Allison's reverse engineering of the BitKeeper protocol and Larry McVoy's hostile reaction.
At first you weren't too enchanted about the waste of time having to write your own DVSC system from scratch for lack of acceptable alternatives. I remember you complaining about that work preventing you to progress on the kernel.
Now Git is becoming the de-facto tool for source control management in most F/OSS communities and inside companies. That's another very successful project you fathered, and while I guess Mercurial or other projects would have existed anyway, the usage of Git on the kernel has demonstrated its reliability and its performance and traction have made DVCS'es gain visibility and market in no time.
Here come the questions:
* Are there any features you still miss from BK?
* As a happy Git user, I thank Jeremy Allison for his refusal to accept compromise and his tentative to create a Free BK client and I thank you for your refusal to accept a technically inferior/ill-suited solution like SVN. How do you reflect on this?
For the record.
We have had different experiences. When I started using it, I definitely struggled many times with OSGi (or more like setting up some containers for my specific needs), but not any more than I did with any other 'advanced' framework (including JEE). But on the (full-OSGi) project I'm working on, OSGi is not costing us anything. We're doing agile development (Scrum) and we're very much feature driven. If we were wasting too much time fighting against OSGi, I'd totally agree with you. But we're not. And our team has members that are just "Java developers" that don't know the specifics of OSGi that much, but we integrated OSGi best practices into our coding guide and it's working well.
In fact, I think OSGi is costing us *less*, because for an application like the one we're developing that requires modularity, we would have ended up writing our own inferior, more expensive and most of all not standardized "plugin system". In fact, in my company there are many different kinds of modules systems that were previously developed and we can't easily exchange modules between those systems (developed for different projects, clients, etc). With OSGi, we can start to share more than just classes or jars. Good bundles do half the integration work.
Anyway I'm not trying to convince you. OSGi is no silver bullet, and it can be difficult in practice when you're plugging into legacy. But when it's working, then it's really nice. My non-OSGi inclined co-workers even grew to like it.
I do agree there's a problem with legacy Java code that makes use of features that are hardly reconcilable with OSGi. I think most of those libs that don't get along well with OSGi are doing something wrong, but sometimes they're trying to be too smart ;). Incompatible legacy code is pretty much the only reason one should run classloader issues, because frankly I find OSGi makes things easier here (especially if you generate your manifest with bnd, which avoids most of the mistakes). One way or another, I agree we most often have no choice but to use those libraries (legacy or not). We can't know "before" if the third party Jars we're using will get along well. At work, I was lucky for one huge software stack (which included C++ parts) and had basically no trouble (beside the initial pain to help my co-workers going) porting the whole thing to OSGi. Another stack is still not ported because of dependencies on those bad JARs (packages split across Jars, having API that's not theirs, etc).
:)
A lot of Java projects are now OSGi-ready though. It's really taking off. I also agree that the tooling is not perfect yet, but it's improving. If you are using Eclipse, I recommend using BndTools rather than PDE. It's a lot less stressful.
In general, I believe the constraints clean programming in OSGi put on the developer lead to better design/architecture, cleaner separation of concerns, even if you're going to dump OSGi after that. But usually when you reach that point you usually get to like it: like coffee, it tastes bad at first. Unlike coffee though, there are too many ways to do OSGi wrong, because there's a lot of contradicting approaches around there. The common wisdom is to avoid the OSGi API when we can (it can be avoided if we don't have to register services dynamically or do framework-level stuff), but after that all hell breaks lose when it comes to testing, building, what editor to use etc. Too many dissenting voices make it long to find a non-intrusive way, but it exists!
Damn, I sound like a commercial, but really OSGi and DI are the only thing that made me enjoy Java. I disliked it before. Also, OSGi is a nice way to do mix polyglot JVM components and that's the "next big thing" (which is not novel at all, but all this has happened before, and will happen again...)
OSGi and DI frameworks such as Google Guice are giving Java a new life. Of course 95% of Slashdot is stuck using Perl but thanks for your review (in fact I'm mostly replying here to compensate with the retarded posts). Sprint DM have been standardized in OSGi and renamed "OSGi Blueprint Services" and while I've not used them (because Declarative Services were enough for my needs and I never was a Spring user), I plan on checking them soon. A lot of people are using Spring and this is the way to get them interested in OSGi.
By the way, another great (but free/creative commons) book on OSGi is Neil Bartlett's "OSGi in Practice". I can't recommend it enough. Unfortunately, it's still in draft so some parts are not completed, but I learnt more about OSGi reading this book than any other resource I could find (printed or online), except maybe looking at the frameworks' code directly.
A branch of the Scala IDE for eclipse shows when there's an implicit conversion by underlining the converted expression. I guess this feature will come to other editors soon enough. Also, to have this conversion, you must have imported it (or its package object). The predefined conversions in scala.Predef are doing what you'd expect them to do and aren't very dangerous (much less, than say, built-in automatic conversion in some dynamic languages).
Implicit parameters are just like dynamic default values. Not a big deal really, especially since Scaladoc hides them by default, you don't even have to know they're here. But they open for a world of possibilities to change the behavior of an API.
In general, implicits in Scala are really a powerful tool and they're useful for API designers more than 'common' users. You said it's not about FP, but Scalaz which is the FP lib for Scala uses them to their fullest extent to replace class inheritance (considered harmful) altogether.
Being myself a Scala fan, I agree with you that it is painful that Sun did not make the JVM with language agnosticism in mind, and that is the main superiority of .NET over the Java platform (the very fact that the best I can call it is "the Java platform", while .NET is not called the "C# platform", is a good hint).
.NET framework is.
.NET, the general anti-NET guy (not anti-Mono). Even if some legal doubt surrounding free .NET implementations remain (even with the recent community promise, but there's always a legal risk with any software you use anyway), this is purely an emotional and political decision. It's fashionable to call my kind "freetards" :). Yet, I've been using and enjoying free software for a long time now, and I remember your stories (notably how you were interviewed by Microsoft and told them you would join them if they changed their business model and developed free software) so I feel you're not the last to take emotional and political decisions. Please note that I appreciate the existence of a Free .NET runtime.
.NET environment? Sure, there is a lot of inertia with Sun, but if someone could have achieved it, that would have been you. At the end of the day, you are still bound by Microsoft standards, are they so much better than Sun's that it justified starting a free .NET implementation from scratch (granted, neither HotSpot nor the JDK were free at the time, but there were already free partial implementations) ? I have read your reasoning at the time of creation of Mono. Of course, after all this work it is late to have second thoughts and regrets, but in retrospective, was it such a good idea?
.NET are strong, but from what I see here Mono is only marginally used even for server-side solutions, and there is a lot of rejection on the desktop from the free software community (which I agree with, even if I have had F-Spot and Tomboy, I do think running Mono for two apps is excessive).
Concerning type erasure, as it has been pointed out by my sibling-thread, it's a design choice. Scala also has adopted type erasure with generics. The other choice could have been made, that is encode type annotations for generics in the bytecode. There is nothing in the JVM preventing it to be done, since it can be done manually, the [alternative language] compiler can add the required info. In Scala, the choice has been made to mimics Java (and I guess, the more the generated code will look like Java, the more we will benefit from runtime optimizations). Thanks to Scala's very powerful syntax, there is a library called Manifest that automatically adds the type information and easily allows you to code as if there were no type erasure.
Still, I agree this feels like a weird rule, especially the first time you run into it. It is not the expected uniform behavior. The same goes will tail-call optimization that should be in the JVM (and should be in OpenJDK7), closures, etc. Generally speaking, the JVM should be a generic platform for languages exactly like the
But I am one of those guys who wouldn't run Scala on
You have done an impressive work with Mono. Don't you think the same effort could have been to make the [renamed] Java platform as generic and powerful at the
We both know the linked article is a joke and Mono doesn't seem to be gaining any real share. Sure, C# and
At the end of the day, I just regret the Mono vs Java situation created yet another division in the community. Of course, and I thank you for it, you are very much responsible for OpenJDK becoming free. And I agree that Sun's strategy regarding both licensing, evolution and genericity of the Java platform has been awful. Yet, right now, between the two, most free software enthusiasts would choose Java. There is no way to rewrite the past, but maybe there could be a way for a better outcome.
(1) Do you think Jazz could gain from a distributed model, like git does for source control management, where the repositories can be forked and kept synchronized upstream/downstream (a bit like a "progressive fork" where fixes can be shared but the project can be forked for various reasons)? I heard there is a git connector in incubation but it seems to me more than just code artifacts should be distributed. After enjoying the many benefits of distributed SCMs, it's hard to go back, and I think at least issue management could gain from the same model.
...) and the current solution is using Aspects with EquinoxAspects to hack on JDT (my understanding is that there are many problems with this hack). Refactoring JDT is something that would be great for E4 (and truly useful), but JDT seems very much to be IBM's turf and I don't see it coming. Any opinion on this, as the original lead on JDT? :)
(2) Do you think creating your own SCM was the good decision, in opposition with using metadata in combination with SVN or git?
(3) Are there any plans to liberate Jazz under the EPL or another Free license, and do you believe Jazz can really gain enough traction as it is? There are plans to integrate Google Wave in the Eclipse Communications Framework by 2010, EGit is coming fast and has a lot of momentum among Eclipse developers, Mylin is getting better with every release, issue trackers are getting a lot better, continuous integration engines such as Hudson work really well... To me it looks like Free Software alternatives are going to beat Jazz at its game (not as well integrated at first), because this is typically software that companies want for free, and Free Software communities want Free Software (I know Jazz is gratis for Open Source projects).
(4) What's your opinion on the new wave of JVM languages such as Scala or Clojure? Did you try playing with them?
(5) Are you planning on participating in the development of E4? Regarding alternative JVM languages, there is a real need to refactor JDT to extract a "JVM-language" development tooling on which the specific Java - the language - tooling is built. The current architecture has been problematic to the development of good environments for alternative JVM languages (Groovy, Scala, JRuby,
Anyway, Eclipse is one of those self-updating apps with its own package manager/provisioning platform (p2). It's not really designed to be installed as a shared program, unfortunately so. As a Debian user and Eclipse developer, I don't find it such a big deal to simply decompress the Eclipse archive in the home directly.
Oh, you sound like a Redditer, sad (atheist that doesn't feel like trashing religious people here). I think you won't find a country where there is more separation of Church and State than France. The closest countries are Belgium and Turkey. In France no official swears on the Bible. In France at trials people swear on their honor, not on some mythological novel 9/10th of the population doesn't care about. In the United States it is about "all religions" OK in public, and in France about "no religion" in public.
In fact, this goes so far that there is a French word for it that has no exact English equivalent: http://en.wikipedia.org/wiki/La%C3%AFcit%C3%A9
I never figured why you "atheists" need to justify your lack of belief and disprove God's existence. Who gives a shit really? Over here in France, I have maybe met 10-15 true believers of my generation in my whole life, including a few who were simply insane.
We call that processes and the fork model.
I know it was partially true, I should remember not to be too lazy when posting on /. :).
Note that I was not talking about automatic parallelization which is indeed possible only with pure languages (and ghc is experimenting on it); but simply about the fact that is is easier to parallelize an application with immutable data structures since you need to care a lot less about synchronization. For instance, the Erlang actors model (also in other languages like Scala on the JVM) still requires the developer to define the tasks to be parallelized, yet immutable data structures make the developer's life a lot easier with respect to concurrent access and usually provide better performance.
My "It is true" was referring to "functional languages" which do usually privilege immutable data structures, not to Haskell or Lisp specifically (which as you said has many variants with mutable structures focused libraries). As you said, Clojure is itself a Lisp-1 and it does privilege immutable data structures and secure concurrent access with Refs/STM or agents. What is more interesting in the Clojure model (compared to Scala's, since they are often compared even though their differences, as functional languages and Java challengers on the JVM) is that it doesn't allow unsafe practices (all must be immutable except in variables local to a thread, etc).
Interesting times on the JVM indeed.
The problem is shared-memory, not multi-processor or core itself. Graphics card have dedicated memory or reserve a chunk of the main memory.
It is true, because they privilege immutable data structures which are safe to access concurrently.
Because they are "Open Source" business-minded and not "Free Software" supporters, meaning they don't give a fuck about providing a full Free stack. I have come to the tragic conclusion that most Open Source contributors are now running Windows.
On the other hand, would they care to make their software Free if it weren't for the Open Source movement? At least we can port the best written software (if its core is not too tightly-coupled to Win32 APIs), so still better than nothing. The biggest problem is that it completely overshadowed the moral aspects of Free Software, which are now to of many corporate Open Source developers nothing but a joke under the pretense of pragmatism and practicality.
The problem is that there is no such thing as "Linux developers". Afaik, OpenGL is maintained by the OpenGL ARB and it looks it needs more support. I agree it is inferior to DirectX, however it is not by abandoning it that the solution will improve. Windows game developers are responsible for the situation by adopting DirectX and succumbing to Microsoft's charms so massively. It's Microsoft, everyone saw it coming.
Anyway, I was not talking about the quality of the API but the achievable end-results which are close to DirectX equivalents (the proof is that Wine translates DirectX to OpenGL and games don't end up looking so bad). I would rather have slightly worse looking games and having them run natively on Linux.
OpenGL ES is a strict subset of OpenGL and the UnrealEngine2 can run under Linux natively. The 3rd version doesn't run Linux/BSD yet (afaik) because I guess it is not a priority, but I don't see why it couldn't.
For being a developer on a cross-platform game (using SDL but knowing how to do it in a "lower-level" way with X / ALSA), I can assure that while it's not perfect, the sound & mouse events is a non-issue. It's only a matter of reading doc... of course the development environment could be better, but it won't happen magically: even in the best case scenario, it will happen gradually if games are release natively.
I know of it. I said decent. :)
I thought exactly the same. I must be a gay fish.
Woops, in fact, Savage2 is not an MMORPG :). It's multiplayer and online though. Doesn't look bad anyway :).
Unfortunately, doing so encourages the status quo. Not that I blame you, but this is a temporary fix.
Thanks for the link! It doesn't look bad even if I am not very much into realm/faction-based MMOs. However the RTS part seems really nice! Players can even run their own server. Their forum, which is usually a good indicator of the community, looks civilized and written in proper English. I have found that Linux games tend to have a more mature community. I will try it when I have some free time.
:).
I also know of Regnum Online which has a native client, but having played it I can tell it's utter shit and I'll spare you the link. If you are masochist, use Google
Actually, I am rather selective for MMOs, it's easy to get addicted even to bad ones. I dream of Mortal Online with a native Linux client.
Unfortunately this will be buried in the mass of posts, but I'll go anyway.
:). And we *are* desperate for good native games.
If a game developer releases his game for Mac and Linux as well, maybe that's 10% market share but it's not the same market share! It's really disappointing to see this fact so often overlooked. Because not all users are the same. Mac and Linux users are DYING to play games. Meaning that a lower market share could still have higher game adoption.
For instance, take MMOs. There are no decent MMOs running Linux natively. As a former Ultima Online player now reconverted into a Free Software enthusiast, I would love a good MMO to play. But I will not use Windows.
The market for MMOs is *saturated*. If you publish yet-another-MMO, whether it's for a niche market of players (hardcore MMOs such as DarkFall of Mortal Online which I would love to play) or another WoW theme-park-MMO clone, you still have to convince Windows players to buy your game and pay the monthly fees. The Linux desktop usage may be lower, there is NO competition for MMOs. Meaning all suckers for MMOs like me would play if the game is any good.
In fact this applies to most games because the market is saturated. It is better summed up by the Lugaru game developers.
IMO, game developers are only missing opportunities. Once they release for Linux and Mac, desktop usage will raise and more people will favor their games over their Windows-only competitors.
Last argument is that "Linux users only want free". This is wrong. Windows users are a lot more about cracking and pirating. If Linux users see something of value, they will no doubt buy it to encourage companies to continue. Most Free Software enthusiasts have no problem with proprietary games because it can be considered a piece of art rather than a piece of software. At least art resources (graphics, music) need not be free, even RMS says so
So (to game developers), stop depending on DirectX! Use abstraction layers between DirectX and OpenGL. UnrealEngine 3 works with both, and considering how advanced it is, I don't want to hear shit about how OpenGL is not as good. It will only get worse if game developers let it die. And release NATIVE support for Ubuntu and Fedora. The community will make sure it works on other distributions.
Nope. Your "loophole" doesn't exist, you cannot link either dynamically or statically on top of a GPL'ed piece of software without your code being GPL'd. But as with all copyright infringement (which is exactly what you are describing), a copyright owner has to complain / sue you. In the case of proprietary Linux modules, they are tolerated by Linus and other kernel developers because they feel they add value anyway. So it's a tolerance that might as well stop tomorrow.
:). So what you're saying will work only if the original authors don't want to enforce the GPL for a particular case, and you should ask them first -- they will never say they don't care officially, but you can still test the water if you like to play.
Why is Nvidia safe? Because they don't themselves distribute GPL'ed code. They only distribute their modules which are very similar to Windows or Mac drivers. The only Linux-specific parts are the interface/hooks and this is rarely considered as derivative work (it really depends on the interpretation of the judge at the trial), so that's how far the legal uncertainty goes for Nvidia.
If the user himself links proprietary to GPL'ed software, he is safe: the GPL has no provision preventing the end-user from any usage. However, the ones who are distributed GPL'ed software automatically linking proprietary modules to the kernel are.... Ubuntu and other distributions (note that Debian does not). They are actually the ones most likely to be sued if a kernel developer with copyright relevant to the graphical subsystem in the Linux kernel (or some code from which it was derived) wanted to go against the flow (because, most kernel hackers stopped caring even if Greg K-H complained about it, and obviously Linus doesn't give a shit because he's "rational").
Now, do the same with a GPL'ed project whose copyleft belongs to the FSF and it will be another story altogether. I think it might hurt
I agree this licensing stuff is tricky, but the GPL actually works and makes sense (but if I lack sleep I can't wrap my head around it).
I'll reply to you but I could as well have replied to the other hundreds of similarly ignorant posts. The difference I guess is in your uneducated (dare I say moronic) title.. When you ssh a GNU/Linux server, it *is* free because you have access to the DATA (and to the free software using it). When you are doing "local computing", data access is guaranteed so the focus so far was on software freedom. When you do "remote computing" (ie cloud computing, SaaS, etc), the notion of *usage* Freedom needs to be extended not only the software, but also to control over the data as well as the guarantee that the software running (or at least the data managing parts) is the software you can obtain.
Reading the article and past RMS interviews, this interpretation seemed obvious but you are so many calling him stupid for stating that simple fact yet not even understanding how obvious it is that it ends up being a pathetic flame-fest. In fact, the most important aspect of remote computing is the control over your data (at least the ability to get it back) in a standardized way so that even if you don't have the software that's running on the other end, you can have a free software of your own do it.
Next time maybe you can read, and if you did, try understanding. Sorry for the rude tone but so much ignorance or ease to go flame gets on my nerves.
Now you may disagree and think that it's OK if you spent 2 years uploading data on facebook that is totally yours (your inputs, your personal life, your photos, etc) and can't even get it to process it yourself or upload it to a (better) competitor, that's your problem. RMS is only saying one thing: Free Software is about control over the data, and if you do remote computing, then you need more than just Free Software to ensure the very freedoms that the FSF is trying to defend. Sorry, but he makes sense.
It IS possible to do SaaS in a way that guarantees control over data and software freedom, that's just not what is being done.