On Friday 10 March 2006 17:34, Pascal Bleser wrote: > [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).
My concerns are regarding the ECMA standards, as you mentioned, this does not void any patent claims, etc, etc. Regarding any kind of combination of licensing creates an issue, etc etc, I have no idea. My question lies in the above. > > - 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. Ehh.... I don't know that I can really consider that to be the case. Mono is, and was intended to be, a cross-platform implementation of .Net. To quote the home page: "Mono provides the necessary software to develop and run .NET client and server paplications on Linux, Solaris, Mac OS X, Windows, and Unix." .Net *is* the platform. Mono is the means. > > - 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 ;) *nod* Though a point of note is that varying implementations have caused varying dependencies of specific versions of Mono, as mentioned elsewhere. > 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. Yes, that is the requirement at the moment; however, with rapid development, there are rapid release cycles, and the possibility of varying versioned dependencies. Will all versioning be kept in sync? Seems like quite a task at the moment. > > - 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. See above... > > - 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). I understand and agree the model which SUSE is currently under. My point is, and remains, that this is an extremely significant change. While the advantage exists for using Mono on the corporate desktop, I do not believe there to be any advantage on the regular Linux user's desktop. In fact, for reasons mentioned throughout this response, I believe there to be significant disadvantages. I believe Novell would have done well to ask the input of the community in this regard, primarily to find where Mono and specifically .Net can fit in, and whether or not this is a "feature" any of the SUSE user community would really be interested in. <snip - unrelated to the discussion> > >>> 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. My comment wasn't in terms of a "yet-another-XX" situation, but using what is valid and open and available now. My concerns remain over the standards control of .Net. Java, imho (while being seriously lacking, as I mentioned I don't like any of these types of languages) would be a better choice. I don't remember where I saw it, so perhaps someone else can put a link to the article or blog (whatever it was), but a VP (or some such) at Sun recently commented that he is in charge of open-sourcing *all* of the software from Sun, in what seems to me to be an effort to involve the community, focus on hardware, and profit by supporting those who would purchase the hardware. > > 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. Read comments earlier. > > 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). Advantage being cross-platform capabilities, which is typically of no general interest to a Linux user, as mentioned earlier. The typical advantage to a Linux user is performance and stability - I don't see either as existing for 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) The tradeoff exists - I won't sit here and argue this point, but I thinks its quite obvious that the increased portability is at the expense of cpu and memory. > > 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. Statically compiled... ahh... much like you can do with Java? Well, I'd like to ask then, what is the advantage of a statically compiled binary of a C# application versus a C++ application? If you're going to have a compiled binary, whats the point in even using C# or Java? I'm sorry, but that point (brought up by many Java supporters in response to other comments of mine elsewhere) has always seemed kind of ridiculous. > > 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. What is, the question about memory limitations being reached? Yes and no. My overall question is, what is the increase in hardware requirements, and is the focus of this as accepting to major hardware upgrades as will be required by Vista. I say this because currently no system on the market will be able to really use Vista, and Vista takes .Net to the fullest implementation as of yet (something MS has been pushing for years, and I've failed to see its usefulness still). > >> 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 > ;)) You said that, not me :P > >> 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. Again, you said this, not me :P You're quoting yourself here :) > > 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. No, really, I see *no* advantage to a SUSE user. > 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... ? I didn't realize it sounded that way. I see it more as sounding like "SUSE will cost significantly more hardware to implement over prior versions". I do see that as a problem, though many (other than myself) consider that acceptable. I see it as unnecessary bloat. > If every single time a decision is taken that doesn't make everyone > happy we end up into threads like these... I would consider this a bit more significant than just a simple decision - this is a core requirement that will be in every installation of SUSE, not choosing a blue theme over a green theme by default or some such. > cheers Joseph M. Gaffney aka CuCullin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
