-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [keeping the thread, but changing the subject to a more descriptive one] Joseph M. Gaffney wrote:
On Friday 10 March 2006 14:18, Robert Schiele wrote:
On Fri, Mar 10, 2006 at 01:45:30PM -0500, Joseph M. Gaffney wrote:
So nothing yet from Novell or the developers?
Why should the developers say anything here about that? The whole discussion was completely emotional with no technical reasons. Thus you just addressed the wrong people and should try to talk to the marketing department instead.
My comments (and others) have gone a bit further than that, though I honestly don't remember if that were here or somewhere else (alot of forum postings over the past day or so). To sum it up, concerns are related to:
Let me split those up in single points and address each of them.
- Increased CPU/Memory usage from implementing a managed application as a core SUSE application for package and system management,
Why increased CPU/memory usage ? (read further on, I think your reason for believing this is clarified there)
- possible legal ramifications,
Yes, that is not totally clear to me either. While our former Gartner friend on this list has stated that the LGPL is void or something, I don't see any reason it would be. It is LGPL, period. And I assume it is LGPL instead of GPL beause it also ships libraries. The LGPL just gives the option of using those libraries as part of a proprietary (or rather, non GPL) application, but otherwise the copyleft conditions of the GPL remain within the libraries. Now, as of the state of Mono, ECMA standard, patents and microsoft. Miguel [de Icaza] has been stating again and again and again that there is no legal problem with Mono wrt microsoft and the ECMA standards associated with C# or the .NET runtime. Personally, I'm really not convinced ... not at all, as being an ECMA standard does *not* void any patent claims, infringement trials and similar. IANAL but personally, I always had the feeling that Miguel was stating the opposite almost ad nauseum but never really explained why. Might just be me though. On the other hand, I assume that the Novell legal dept has checked back with this, as we all know Novell really isn't a friend of microsoft (and that if patent claims or infringement trails are possible, they will happen sooner or later).
- the reason for basing such a system on a set of "standards" that are controlled by another organization known to implement its own variations on a whim,
While I strongly agree with the 2nd part of that (we all know that microsoft and standards makes 2), I really don't see that issue at all in this case. Mono is the platform, not .NET As I wrote in an earlier post, just forget that Mono is a .NET spec implementation. C# is a modern OO programming language, Mono is an opensource runtime, that's it, and that's fine with me.
- the current state of Mono support and stability by comparison to other distros,
I guess you picked up my argument about this. Well, at least, having Mono as a strong requirement for Zen and Yast2's package management module will imply having a very up-to-date Mono platform shipped as part of the distribution. I see that as a benefit ;) When I wrote my gripes about Mono not being a stabilized platform in terms of API (I'm really speaking of platform and language features, not of bugs or crashes), I don't really see that as an issue in this particular case: Yast2 requires the Zen engine that requires a certain Mono version. That one has to be supplied with SUSE Linux >= 10.1. Period. No issue here.
- the possibility for multiple required snapshots (a la wine or cedega as examples),
Sorry, I absolutely don't see what you're relating to. Zen is developed against a certain feature-set of the Mono runtime. That version (or higher) of the Mono runtime has to be shipped as part of SUSE Linux 10.1. That's it.
- and concerns over a lack of involvement from the openSUSE community.
We're working in a "benevolent dictatorship" model here. This deserves a thread of its own that would certainly be filled with emails for weeks, but I'd really like to make some points (that only reflect my very humble opinion, I don't mean to speak for anyone else). I'm no Novell fanboy, actually I don't care much about Novell itself, but I do care about the SUSE staff and that great distribution we all love to use (and, of course, I care even more about the community that's around it). That model for openSUSE has advantages and drawbacks, as always, but we must give Novell credit for some points: - - we would never have had a freely downloadable SUSE Linux version (from day one of its release) with SuSE GmbH, simply because selling the boxes was a large part of their revenue - - we probably wouldn't have had something like openSUSE without Novell either, as Novell has the cash to invest into such losses, from a purely financial point of view (of course, they're a business, and they are planning that in return, they will sell more SLES and SLED/NLD, OES, etc... - it's a win/win situation to me, both for them and for the community) - - as opposed to Redhat/Fedora, Novell still has a large staff of full-time employees working on the distribution (as well as KDE, GNOME, Xgl, and many many other OSS projects, but that also applies to Redhat), while Fedora has been pretty much tossed to the community without much from Fedora being used for Redhat's enterprise distribution (AFAIK) - - new initiatives, such as Tango, desktop usability projects, Xgl, ... - - more weight when talking to hardware and software vendors than SuSE GmbH (at least I strongly presume it is the case ;)) So, let's not paint it black. As I wrote above, I'm not a Novell fanboy at all, but we have to give them credit for that. And we also have to accept some of their decisions, even if we as a community will eventually need to have better communication and maybe even more consultation about the direction of the distribution. If you prefer a development and community model where the community is in total control, then you'd certainly be better off with Debian or Gentoo. But you don't have much more control there either, as roles and responsabilities are given to maintainers who have proven their leadership and know-how, and they have the final word. Personally, at the moment, I see the "benevolent dictatorship" model we currently have as the most effective one. Of course, a lot of things have still to be done in terms of community integration and participation, but most are very aware of that and it doesn't just happen in 3 months' time. And it's also up to us, the community, to do something, to step up and take tasks, develop initiatives and projects, not just say "novell has to do this, they must do that".
I believe alot of people here have expressed serious concerns with the use of a .Net based application as a core component, and I have yet to see any official response on this. Well, whether your concerns were serious is quite questionable. Your main argument was that you associate .Net/Mono with Microsoft and that you do not like Microsoft. I don't like corporate policy of Microsoft either but competing with a company does not mean running through the world with blinders, ignoring this company's products.
No, that wasn't the reason. My concern is over duplicating the efforts. As I said (I'm pretty sure in forums on this one, so noone here would have seen it), innovation by duplication isn't innovation at all. I would much rather see a better system created, standardized, and implemented. I personally
Yet another language ? Yet another platform ? Oh please, that's the least thing we need.
believe what ODT teaches us (yes full acceptance is a long way off, but I believe it will hold up and expand) is that an open standard with a thorough review process will result in a highly competitive product, beyond what can be offered in current commercial packages. A traditionally proprietary corporation implementing such standards seems highly unlikely, allowing the "alternative" (and I use quotes because its more than an alternative, its an improvement) to thrive. Without such a refined method, I don't believe the idea would have even come up in Massachusetts, and spread to other governments and organizations in the way it has so far.
Mono is Mono, period. Forget that .NET thing.
I also have no issue with implementing Mono and using it as a means by which Novell can take on the corporate desktop; .Net is a reasonable way to allow a company to comingle Linux and Windows. What I have issue with is using it,
Well it's also just a modern programming language with a good runtime engine. While I very much prefer Java, both as a language and as a runtime, Mono isn't all that bad. Managed environments such as Java and Mono have a lot of advantages over "traditional" environments and it's definitely where the IT industry is heading to since a few years, especially with Java (that has been around for a lot longer than .NET and Mono).
as mentioned, in such a required application. Nothing can be done is C# that couldn't be done in C++, and managed applications simple have a much larger footprint. To use a .Net application as an example, the Notepad
What makes you say they have a larger footprint ? You know that in many cases, a Java application is faster than one implemented in C or C++ ? (I'm not talking about Swing GUI applications, them being slow has very different reasons, the JVM itself is extremely fast)
implementation Microsoft offers as a sample, which doesn't even have the slightest bit of advanced features such as find and replace, uses a whopping 8MB of ram. Is this the kind of memory usage Linux users are going to see in
Awww.. please.. don't pick microsoft's notepad.NET as a proof for managed applications and environments being not as performant as statically compiled ones.
the future? Considering the size of a system management application, when implementing large-scale changes and updates, is it possible that the 2GB limitation for a single thread could be reached (referenced to unpatched 2GB/2GB limitation on 32-bit systems with the linux kernel)? To what specifications will 10.1 capable systems need to be to pull off regular use of ZEN?
I'm sorry but that point is bullshit, from a technical point of view.
Note that I don't like programming (although I sometimes have to do it) in the Java language because it has some rather stupid design flaws in my opinion. But I don't run through town like a maniac crying that I will
must... resist... :) (no let's not start a programming language flamewar ;))
never use applications written in Java. As long as I do not have to maintain the software and it is doing his job I don't care when it is written in Java.
Yep, that was exactly my point in my previous mail. (and I wipe the next section because this would end in a flamewar)
My concern isn't that I couldn't port it or replace it by another means, my concern is what this means for the future of the SUSE Linux platform. Will (and this is a prediction based on my experience with managed environments such as .Net) memory and CPU hogs become more prevalent, and integrated with the core that makes SUSE Linux the SUSE Linux distribution? Will the end users be required to make significant upgrades to their hardware to be able to perform an initial installation on slightly older hardware?
Let me express some doubts about your experience with managed environments.
There seem to be quite a few concerns (and I'm not the only one) as to the use of .Net based apps, but no apparent or offered benefits. This is what I would like some clarification on.
I know it isn't your intention but my FUD-o-meter is almost red. Isn't it possible to discuss about this "issue" in a manner that would not threaten, that would not sound like "SUSE is dead", etc... ? If every single time a decision is taken that doesn't make everyone happy we end up into threads like these... cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\ <pascal.bleser@skynet.be> <guru@unixtech.be> __v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEEf7+r3NMWliFcXcRAvWAAJ9hOvxh6YooUZ+XBCaLn4cKUKOM3gCeMLFo 2I1U9OpFTpju4hvOM+tQVr4= =3C2U -----END PGP SIGNATURE-----