Re: What about Embedded?
Mono has been successfully used in embedded systems of different sorts. Examples? Or are we just talking about some guy who got it working once? In the particular context of Gnome and Mono, I assumed you were talking about Maemo which is probably the high profile user of Gnome today on an small device, and on Maemo Mono is just a fine solution. Maemo are not using Python yet as far as I can tell. They would like to support it as a development environment, and maybe then use it for their own core stuff. But it needs some performance/memory/code-size work. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Save a kitten today (was Re: What about Embedded?)
On jeu, 2006-07-20 at 23:24 +0100, Jamie McCracken wrote: I totally agree but wouldn't it be better to use native languages that offer all this like the D language (http://www.digitalmars.com/d/). It's cool to read about various languages, but really, this is off-topic on this list. We're in the process of choosing which modules we'll include and deciding whether we'll accept apps written with Gtk#. It's not easy and there's been a lot of noise that make it even less easy. So please think twice before sending an email, especially when the list becomes high-traffic as it is right now. We don't want to see developers unsubscribing because of the noise. (this is not only for Jamie, but for everyone here) Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Crush the political bullshit [Was: What about Embedded?]
quote who=Philip Van Hoof In an opensource setting, we should CRUSH political bullshit and overthrow it with technical superiority. We are by the way NOT doing that, and in stead failing TECHNICALLY at the exact same POLITICAL problems companies are also facing. Philip, Firstly, what we are doing (Free Software) is *inherently* political, and in many ways hasn't been technically superior for a long time. Do we give up? Absolutely not. Secondly, there are lots of interests involved in what we do, and sometimes they are competing interests (competing - and yet collaborating). You can't just make simplistic statements like CRUSH political bullshit and expect it to actually mean anything. It's just another way to dismiss people's entirely valid points of view. We can't do that. There are hard choices to be made here, some of which may exclude members of our community. These choices may not have such import to you, but please don't disregard or disrespect the other points of view in our community. Thanks, - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ People who paid for bug fixes in the 3c501 driver also bought MacIIfx support contracts... - Alan Cox ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Some Vala ideas (Was: What about Embedded?)
On Fri, 2006-07-21 at 11:23 +0200, Philip Van Hoof wrote: On Fri, 2006-07-21 at 07:07 +0200, Jürg Billeter wrote: You might be interested in looking at Vala http://www.paldo.org/vala/ . It's not ready for production use yet but it's available for testing now and with feedback [hint ;) ] from interested developers I believe that we can get a very nice development environment for GNOME ready in relatively short time. Yes Jürg, I have been looking at your Vala stuff very recently indeed. And I indeed have to say it looks very interesting. I even think language binding code generators are not the best solution. Imo it should be handled by the languages themselves and fully automatically. Other than political, I don't see the *real* technical difficulties for something like that. Probably because Vincent asked us to keep on topic, Jürg replied me in private about his idea to have compiler plugins and a standardized interface description (like GIDL). I hope some more people with ideas will contact Jürg and share them. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Hello, Mono has been successfully used in embedded systems of different sorts. Examples? Or are we just talking about some guy who got it working once? Confidential, paying commercial customers. All we can say is that the PowerPC port was paid by them. Maemo are not using Python yet as far as I can tell. They would like to support it as a development environment, and maybe then use it for their own core stuff. But it needs some performance/memory/code-size work. Yeah, but users are. And they have been for a long time in the pre-Maemo GPE days. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On 7/20/06, David Nielsen [EMAIL PROTECTED] wrote: tor, 20 07 2006 kl. 23:24 +0100, skrev Jamie McCracken: The D language offers the best of all worlds IMO *without* compromising on speed, resource usage or bloat. It would be madness to use a VM instead! (of course its not as integrated into Gnome yet and lacks an IDE but if someone puts the work in you will have a killer platform than no VM based platform can match) ... in about 10 years, once D exits beta and someone sits down to write a proper IDE, the bindings, etc.. Mono is here now, it has basically all the tools we want, the Mono maintainers care about GNOME and as an added bonus we get to market GNOME to all the college students who are currently being trained with .NET in mind. I think this is a good point. I have just spent my gap year developing a C# app for Windows, not because I wanted to use that platform but because that was what my employer specified. It was ridiculously easy to learn (because of the number of help/tutorials/examples around), and the development speed was incredible. I'm sure this will be the situation for a huge number of young people. As far as I have experienced this year, Microsoft are very good at catching programmers when they are young, giving them very powerful tools that make life very easy, and that they _feel_ they can not do without (I think many people in the community are experienced working without any high level tools, and now find them useful but not essential, whereas increasingly young people are being taught to program with these advanced functions, practically unaware of what to do if they are not available). If you are only developing desktop applications for relatively high end systems (as these people generally are) I think it is fair to say that there are few compelling reasons to learn lower level languages. I reckon C# can act as a bridge that allows people to use what they know already (and the knowledge of a large pool of Windows and Linux programmers) to learn about (some aspects of) programming for Gnome, perhaps learning to write more efficient/low level code later on. The important thing is that they are programming _for gnome_ Embracing these people is a great way to get more developers, fresh ideas and new and diverse applications. Who ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Hello, Indeed, I find it ironic that in light of recent moves to expand the Gnome tent to include Mobile and Embedded devices as at GUADEC this year, that there is at the same time an effort to push MONO into the stack. At what price are these moves being made or considered? Like Havoc said, innovation at the cost of performance and memory usage is not innovation in my book. Mono works just fine on embedded devices, and considering that it consumes less memory than Python when running Gtk applications and people do not have a problem using Python on embedded devices I do not see the problem. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On Thu, 2006-07-20 at 14:46 -0400, Miguel de Icaza wrote: Hello, Indeed, I find it ironic that in light of recent moves to expand the Gnome tent to include Mobile and Embedded devices as at GUADEC this year, that there is at the same time an effort to push MONO into the stack. At what price are these moves being made or considered? Like Havoc said, innovation at the cost of performance and memory usage is not innovation in my book. Mono works just fine on embedded devices, and considering that it consumes less memory than Python when running Gtk applications and people do not have a problem using Python on embedded devices I do not see the problem. In fact. Considering that most of ALSO the application developers in the GNOME context are very good at *not* freeing up their memory, I actually but truly believe that running most GNOME programs under a garbage collector would actually save (a lot) more memory then the virtual machine would add. But that is of course just an assumption. Perhaps I shouldn't make such an assumption if I want to be a nice guy :-)? Nice guys tell you bed-time stories. They don't show you reality. So I run valgrind a lot. And suddenly it's not just an assumption anymore, but more or less a proven fact. I do agree that running it with a garbage collector doesn't fix the problem itself. Leaks must be fixed, not garbage collected. Of course. I would, however, want to point out that I'm not trying to sneak in a look how bad Evolution is here. In terms of truly leaking memory, Evolution is not bad at all. Evolution does consume a lot memory in known memory. Mostly in its summaries. I'm not talking about Evolution here (I know I do a lot, so don't get confused). -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On Thu, 2006-07-20 at 23:24 +0100, Jamie McCracken wrote: And this is why GNOME should accept and go for higher programming languages and modern development techniques. I totally agree but wouldn't it be better to use native languages that offer all this like the D language (http://www.digitalmars.com/d/). I think most of the people that ever talked with me on IRC already know that I'm very much a fan of the D programming language. No one has ever justified why we need a VM given all its disadvantages (speed - especially when mixing with native code, startup time, resource usage, bloat etc) A program that runs in a virtual machine can benefit from run-time optimization. If you want to do the same with a native application, you would need to feed the compiler with statistics which you need to gather from your users. Which isn't always an easy task. Or you must use alignment tricks and give the compiler a lot hints. But those hints don't hint the compiler about when the user uses it in an unexpected way. Unexpected as in: the user doesn't use the application the way the developer intended. -- I'm sure the heros that implemented our current virtual machines can give you much more information on this than I can. -- But all that doesn't matter for desktop NOR for mobile usage a lot. There's plenty of CPU to waste on a little bit of virtual machine overhead when we are talking about desktop applications. I mean, have you actually seen what some people dare to implement? THAT is the ONLY reason why their stuff runs slow and consumes a lot memory! It mostly has nothing to do with native or virtual machine. Even for mobile devices. But you make a good point with D. I would love to develop using D for the Nokia 770. In fact, I have plans to build myself a cross GCC compiler with an ARM backend and a D frontend soon. And then ... fuck the convention that everything must be done in a popular language to be accepted by some community. Then they don't accept it. That's their problem. I really hope young fresh developers think like this when they will pick their programming language for implementing their cool ideas. Hey young guys, if that GNOME community doesn't like your .NET: so what! DO use what you want to use. Your cool application will get popular even without this official recognition of that GNOME platform. Meanwhile, I do ask the non-Mono (and non-Python, non-Java, non- whatever) GNOME community to start accepting the modern programming languages. Stop fooling yourself and DO look at reality. Also managed languages can still leak and crash and misbehave if the p/invoke is not done properly so it aint a silver bullet. True. Of course. The D language offers the best of all worlds IMO *without* compromising on speed, resource usage or bloat. It would be madness to use a VM instead! There's still some pro VM arguments that D doesn't have. Like a good reflection framework (Hibernate uses this a lot). Oh .. And now that I mention Hibernate. The current popular languages (Java and .NET) have A LOT frameworks (Spring, Hibernate, etc) that don't (yet) exist in the D world. (there's NSpring and NHibernate Java guys, you don't have to tell me I'm selling Java-only tech because you would be lying). Most of them don't even have an equivalent in any of those native languages. I assure you such frameworks DO speed up software devel- opment. I would very much want GNOME application developers to start leveraging such frameworks. (of course its not as integrated into Gnome yet and lacks an IDE but if someone puts the work in you will have a killer platform than no VM based platform can match) -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
tor, 20 07 2006 kl. 23:24 +0100, skrev Jamie McCracken: The D language offers the best of all worlds IMO *without* compromising on speed, resource usage or bloat. It would be madness to use a VM instead! (of course its not as integrated into Gnome yet and lacks an IDE but if someone puts the work in you will have a killer platform than no VM based platform can match) ... in about 10 years, once D exits beta and someone sits down to write a proper IDE, the bindings, etc.. Mono is here now, it has basically all the tools we want, the Mono maintainers care about GNOME and as an added bonus we get to market GNOME to all the college students who are currently being trained with .NET in mind. Aside such things as the existence of tons of books, documentation, classes and existing programmers for .NET, I agree D is a shoe in.. I have confidence in Miguels team, I'm sure they'll optimize the crap out that sucker if we hit serious problems providing GNOME using Mono. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Philip Van Hoof wrote: On Thu, 2006-07-20 at 23:24 +0100, Jamie McCracken wrote: And this is why GNOME should accept and go for higher programming languages and modern development techniques. I totally agree but wouldn't it be better to use native languages that offer all this like the D language (http://www.digitalmars.com/d/). I think most of the people that ever talked with me on IRC already know that I'm very much a fan of the D programming language. Great :) No one has ever justified why we need a VM given all its disadvantages (speed - especially when mixing with native code, startup time, resource usage, bloat etc) A program that runs in a virtual machine can benefit from run-time optimization. If you want to do the same with a native application, you would need to feed the compiler with statistics which you need to gather from your users. Which isn't always an easy task. D *easily* beats mono and java in every benchmark so runtime optimisations count for very little here. http://shootout.alioth.debian.org/debian/benchmark.php?test=alllang=dlanglang2=csharp [snip] Even for mobile devices. But you make a good point with D. I would love to develop using D for the Nokia 770. In fact, I have plans to build myself a cross GCC compiler with an ARM backend and a D frontend soon. Great the more of us that use D in gnome the more likely it will get accepted at some future date. And then ... fuck the convention that everything must be done in a popular language to be accepted by some community. Then they don't accept it. That's their problem. I believe Mono was rejected mostly by Sun Developers with concerns over bloat and memory usage being high on the list (and maybe a few political reasons). D does not have these issues and if a few of us Gnome developers start using it we may find we can get in Gnome one day :) The D language offers the best of all worlds IMO *without* compromising on speed, resource usage or bloat. It would be madness to use a VM instead! There's still some pro VM arguments that D doesn't have. Like a good reflection framework (Hibernate uses this a lot). Why do we need reflection? If and when Gobject gets full introspection it will become irrelevant. Reflection does affect performance too which is why D avoided it and stuck to introspectable properties only. D has made sensible design choices by following Delphi's design instead of java/c#. Oh .. And now that I mention Hibernate. The current popular languages (Java and .NET) have A LOT frameworks (Spring, Hibernate, etc) that don't (yet) exist in the D world. (there's NSpring and NHibernate Java guys, you don't have to tell me I'm selling Java-only tech because you would be lying). Most of them don't even have an equivalent in any of those native languages. I assure you such frameworks DO speed up software devel- opment. I would very much want GNOME application developers to start leveraging such frameworks. We already have most of what we need in Gnome already for building cool desktop apps - we just need D bindings for the Gnome specific stuff. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
David Nielsen wrote: tor, 20 07 2006 kl. 23:24 +0100, skrev Jamie McCracken: The D language offers the best of all worlds IMO *without* compromising on speed, resource usage or bloat. It would be madness to use a VM instead! (of course its not as integrated into Gnome yet and lacks an IDE but if someone puts the work in you will have a killer platform than no VM based platform can match) ... in about 10 years, once D exits beta and someone sits down to write a proper IDE, the bindings, etc.. D is already stable enough - yes its officially still in beta but nothing has changed there and people are building apps with it. Mono is here now, it has basically all the tools we want, the Mono maintainers care about GNOME and as an added bonus we get to market GNOME to all the college students who are currently being trained with .NET in mind. All too true - its why we need volunteers to beef up D's offering. We do have GTK bindings though (http://dui.sourceforge.net/) Aside such things as the existence of tons of books, documentation, classes and existing programmers for .NET, I agree D is a shoe in.. For Gnome to be the best desktop it needs the best technology and that is arguably the D language. On a technical basis it is currently unbeatable (I think!) I have confidence in Miguels team, I'm sure they'll optimize the crap out that sucker if we hit serious problems providing GNOME using Mono. As a c# programmer myself (asp.net) I know how hard that is. If they can make mono anywhere near as good as D then he will have converted me! -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On Fri, 2006-07-21 at 00:03 +0100, Jamie McCracken wrote: Philip Van Hoof wrote: On Thu, 2006-07-20 at 23:24 +0100, Jamie McCracken wrote: D *easily* beats mono and java in every benchmark so runtime optimisations count for very little here. http://shootout.alioth.debian.org/debian/benchmark.php?test=all〈=dlanglang2=csharp Most of the tests I see on that page are specific algorithms that utilise already manually optimized techniques. The reality, however, is that most desktop application softwares don't look *at all* like these tests. Most desktop application softwares are very unoptimized pieces of code that do *a lot* disk I/O, inter process communication, write a lot things to the X server (also IPC) and perform an unholy amount of string (and other types of memory) copying (and an almost equal amount of not-freeing that). Real code is very often not at all like these school algorithms that have been developed by keen students. They are used, yes. But those parts of the application-code indeed runs often optimized already. I believe Mono was rejected mostly by Sun Developers with concerns over bloat and memory usage being high on the list (and maybe a few political reasons). I wouldn't say Sun has something to do with this. Let's not accuse people here, shall we? D does not have these issues and if a few of us Gnome developers start using it we may find we can get in Gnome one day :) Just use it. Why do you want it *in* GNOME so fast? Why do we need reflection? I'm not saying your *need* it. I'm saying a lot developers are *using* it. I usually avoid using it myself. If and when Gobject gets full introspection it will become irrelevant. Ugh .. GObject introspection will not at all have all the features reflection in Java and .NET have. Not even close. Reflection does affect performance too which is why D avoided it and stuck to introspectable properties only. D has made sensible design choices by following Delphi's design instead of java/c#. I agree with that. We already have most of what we need in Gnome already for building cool desktop apps - we just need D bindings for the Gnome specific stuff. So help the guys doing just that? -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On Fri, 2006-07-21 at 00:10 +0100, Jamie McCracken wrote: ... in about 10 years, once D exits beta and someone sits down to write a proper IDE, the bindings, etc.. D is already stable enough - yes its officially still in beta but nothing has changed there and people are building apps with it. But the Digital Mars D compiler is a proprietary compiler, and I don't believe there is a stable backend for gcc yet. Maybe some people don't care about that, but I suspect more than a few do care. It certainly was an obstacle with Java bindings for awhile (and perhaps still is somewhat). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Cody Russell wrote: On Fri, 2006-07-21 at 00:10 +0100, Jamie McCracken wrote: ... in about 10 years, once D exits beta and someone sits down to write a proper IDE, the bindings, etc.. D is already stable enough - yes its officially still in beta but nothing has changed there and people are building apps with it. But the Digital Mars D compiler is a proprietary compiler, and I don't believe there is a stable backend for gcc yet. http://dgcc.sourceforge.net/ -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On Fri, 2006-07-21 at 00:31 +0100, Jamie McCracken wrote: Cody Russell wrote: On Fri, 2006-07-21 at 00:10 +0100, Jamie McCracken wrote: ... in about 10 years, once D exits beta and someone sits down to write a proper IDE, the bindings, etc.. D is already stable enough - yes its officially still in beta but nothing has changed there and people are building apps with it. But the Digital Mars D compiler is a proprietary compiler, and I don't believe there is a stable backend for gcc yet. http://dgcc.sourceforge.net/ I knew about this backend I think, but I guess I didn't realize it has become very stable. Or perhaps my assumption was just based on the fact that it hasn't been folded into gcc proper yet. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Hi; On Fri, 2006-07-21 at 00:10 +0100, Jamie McCracken wrote: the tools we want, the Mono maintainers care about GNOME and as an added bonus we get to market GNOME to all the college students who are currently being trained with .NET in mind. All too true - its why we need volunteers to beef up D's offering. We do have GTK bindings though (http://dui.sourceforge.net/) Those bindings, and forgive my bluntness, suck in a way that it's hard to describe; the API is horrible (four ways to add a callback to a clicked event? come on, give me a break) and the rationale for some of their choices is risible (uttons are there to pass on user events not executing actions? key bindings and composite widgets anyone?). They still need a lot of work just to be *half* as good as any of the other bindings of the platform libraries. I concede that, in time and with enough manpower and when D will have reached a critical mass of users, D should become a tool for developing GNOME applications. But now it's really too early even to plan upon it. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Emmanuele Bassi wrote: Hi; On Fri, 2006-07-21 at 00:10 +0100, Jamie McCracken wrote: the tools we want, the Mono maintainers care about GNOME and as an added bonus we get to market GNOME to all the college students who are currently being trained with .NET in mind. All too true - its why we need volunteers to beef up D's offering. We do have GTK bindings though (http://dui.sourceforge.net/) Those bindings, and forgive my bluntness, suck in a way that it's hard to describe; the API is horrible (four ways to add a callback to a clicked event? come on, give me a break) and the rationale for some of their choices is risible (uttons are there to pass on user events not executing actions? key bindings and composite widgets anyone?). They still need a lot of work just to be *half* as good as any of the other bindings of the platform libraries. I concede that, in time and with enough manpower and when D will have reached a critical mass of users, D should become a tool for developing GNOME applications. But now it's really too early even to plan upon it. Yeah things could be better but if it is all sorted out we would have the best development framework on any platform. Ideally it needs paid developers to turn it into a really cool platform (maybe a gnome company can sponsor it?) If I have the time I will help out of course. Topaz in D - now that would rock! -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On Fri, 2006-07-21 at 00:35 +0100, Emmanuele Bassi wrote: the rationale for some of their choices is risible (uttons are there to pass on user events not executing actions? key bindings and composite widgets anyone?). I haven't at all investigated DUI. I did look at the D specification. The event-handling, however, looks to me a lot like how to do it in C#: From the samples on the site: button.onClick += doCancel; What is wrong with operator overloading + and using delegates for this? In my opinion, that works great in C#. Note that normally I discourage operator overloading. But for Events ... yeah, fantastic idea of Microsoft! My opinion is that it's much cleaner in C#, than these anonymous classes in Java. Which is in my opinion caused by wanting to stick to the observer design pattern TO purely. Microsoft learned from Suns mistakes, and improved it in their own thing. Some call that stealing, I call it innovation. If you can't cope with that, you'll simply lose the game. Totally fair and correct. I guess the DUI guys are still in experimenting phase a little bit. Why don't we (or whoever the experienced GNOME/Gtk+ binding guys are) go out and help them? Lets just go over there and make their stuff the best humans ever created? Why? Because we can. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Hello, I look forward to Mono development over time. I do think it is an exciting framework. My experience is from the embedded world. My engineers don't use Python with Gtk+. We use Gtk+ and Gtkmm. My concern is for the overall user experience. I come from a world of our own in-house kernel and rootstrap. My kernel is written in ARM assembly. All of my drivers from I2C to USB are written in ARM assembly. So as I transition my team's products to the Gnu/Linux and Gnome platform, the overall user experience should not regress. That is my gatekeeper in a way. You have to weigh the pros and cons of cost as well. Do I throw more money at more expensive processors, more memory, and more flash just so that software performance doesn't regress? Or do I compromize and stick with native for now, keep the price down and allow third party use of frameworks like Mono or Python and see it evolve over time. That is my balance. I think it is a fair one. It is a fair one. Our difference of opinion is that we are probably looking at different sides of the embedded world. Embedded can mean a million different things. Mono has been successfully used in embedded systems of different sorts. In the particular context of Gnome and Mono, I assumed you were talking about Maemo which is probably the high profile user of Gnome today on an small device, and on Maemo Mono is just a fine solution. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
The reality in this story is that application developers don't want to care about this. This is why a lot of them prefer to develop using virtual machines. And this is why GNOME should accept and go for higher programming languages and modern development techniques. I totally agree but wouldn't it be better to use native languages that offer all this like the D language (http://www.digitalmars.com/d/). No one has ever justified why we need a VM given all its disadvantages (speed - especially when mixing with native code, startup time, resource usage, bloat etc) I'll mention a couple of advantages not pointed out so far and which I find fundamental: 1) Portability: one single binary for all platforms and architectures. 2) Code access security (CAS), ability to restrict the permissions of an application or library. Maybe those features are not fundamental right now (although very convenient), but they will be in the future. GNOME needs to expand beyond the local desktop to be able to offer applications which can compete with the Web 2.0. In order to survive in an Internet based on services, we'll need an easy and secure way of delivering applications and add-ins through the net, which can consume those services. A VM is just perfect for this. Lluis. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On Don, 2006-07-20 at 23:24 +0100, Jamie McCracken wrote: I totally agree but wouldn't it be better to use native languages that offer all this like the D language (http://www.digitalmars.com/d/). No one has ever justified why we need a VM given all its disadvantages (speed - especially when mixing with native code, startup time, resource usage, bloat etc) Also managed languages can still leak and crash and misbehave if the p/invoke is not done properly so it aint a silver bullet. The D language offers the best of all worlds IMO *without* compromising on speed, resource usage or bloat. It would be madness to use a VM instead! (of course its not as integrated into Gnome yet and lacks an IDE but if someone puts the work in you will have a killer platform than no VM based platform can match) You might be interested in looking at Vala http://www.paldo.org/vala/ . It offers similar advantages as D does but with one major addition: it has been designed for GNOME (resp. GObject). I assume you can't subclass D classes from C (via GObject) or other languages, so it's only usable for applications but not for GNOME libraries. Vala uses the GObject type system as its native type system and bindings for GTK+ and other GNOME libraries are only needed at compile-time, not at run-time. It's not ready for production use yet but it's available for testing now and with feedback [hint ;) ] from interested developers I believe that we can get a very nice development environment for GNOME ready in relatively short time. Regards, Jürg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
What about Embedded?
Indeed, I find it ironic that in light of recent moves to expand the Gnome tent to include Mobile and Embedded devices as at GUADEC this year, that there is at the same time an effort to push MONO into the stack. At what price are these moves being made or considered? Like Havoc said, innovation at the cost of performance and memory usage is not innovation in my book. One item that Jeff mentioned at GUADEC that I recall is that it is not far from reality that their will be more Gnome embedded/mobile devices than desktop installs at some future date. This sort of development is going on full speed. I personally think more thought needs to be put into the decision than simply the inclusion of pet applications. Sean On 7/16/06, Havoc Pennington [EMAIL PROTECTED] wrote: Iain * wrote: Really? depends on your context... For some people a terminal and text editor are completely worthless, but take away photo management Once again, who are we targetting with the desktop. Apple know who they're targetting, which is probably why text editor and terminal are not high on the list of features. Yes! I was hoping your thread about this would catch fire instead of the one about mono, because answering the what is gnome anyhow? question would make the mono-type debates much simpler. If GNOME can't figure out a way to answer that question, its only option is to be a platform provider for Elisa, Maemo, SLED, Fedora, Ubuntu, Palm, Firefox, WINE, etc. etc. Those are all more focused, more target-audience-decided-upon solutions that in many cases use GNOME technology but diverge to a small or large extent from the GNOME desktop release because guess what, actually shipping something useful requires more focused, specific thinking. There's nothing wrong with the platform provider path, and it's probably inevitable by inertia and industry dynamic, but if taking that path it'd be interesting to do it consciously and optimize GNOME as a platform provider - with the providers of all those more focused solutions as the primary customers. And this _also_ helps answer the Mono debate - the question would become how to best serve the specific solutions and the teams building them. To me there are two hard parts to answering the target audience / what is GNOME question: 1) how does GNOME decide anything? it's a big swarm of people 2) which audience or focus to choose? Here's one way one might approach it. : Step 1. Collect underpants. j/k : Step 1. Redefine GNOME as in the original charter; provide an open source computing platform to the general public. Do this on the foundation level and get wide buy-in. Hammer the message consistently through the web site and other communications. The goal is to fight off the GNOME = desktop environment legacy. Note, platform in the charter I think has to be understood as environment or solution not as APIs - might be worth officially rewording in that way. In fact, I think it has to include both software bits AND finding some way to work with content and online services if there's a serious interest in offering open source alternatives to today's proprietary software companies. So, let's assume platform includes all that stuff for purposes of redefining GNOME in this way. : Step 2. Kill the single desktop release and replace it with target-audience-specific/solution-to-problem-specific more focused releases. For example, while they may not be interested, Maemo and Elisa would be candidates. The current desktop release should become one thing among peers; or it's even worth considering splitting it up to be multiple peers. Don't call the desktop release desktop either because it's too vague. More specific examples might be an enterprise unix/linux GUI release, or tech-oriented consumer/hobbyist release or tech workstation release or high-powered MS Office user in an office release or computer lab / thin client release or whatever people feel is the right focus. The word desktop is like a cancer. Its problems include: - it's vague as hell - includes a zillion target audiences and apps - it accepts an existing category definition (essentially, what windows and mac are) thus precluding meaningful innovation - it excludes content and online services - key elements of all the new stuff going on in the tech industry today The huge debate here is how to split things up; the important thing to remember is that there can be lots of code sharing (where it makes sense) between related offerings. So e.g. almost everything could use GTK, but only some offerings might want the GNOME panel. i.e., doing the split by _codebase_ is wrong; the split is by _target audience_ and _focus_; some splits might be worthwhile _just to change the default config options_ even. The technology can be made to support such things, and in fact it should be made to do so. Also of course, the split
Re: What about Embedded?
On Wed, 2006-07-19 at 07:03 -0500, Sean Kelley wrote: Indeed, I find it ironic that in light of recent moves to expand the Gnome tent to include Mobile and Embedded devices as at GUADEC this year, that there is at the same time an effort to push MONO into the stack. At what price are these moves being made or considered? Like Havoc said, innovation at the cost of performance and memory usage is not innovation in my book. One item that Jeff mentioned at GUADEC that I recall is that it is not far from reality that their will be more Gnome embedded/mobile devices than desktop installs at some future date. This sort of development is going on full speed. I personally think more thought needs to be put into the decision than simply the inclusion of pet applications. The current proposal is to add GTK# to the official Bindings set, and Tomboy to the official Desktop set. The Platform set, which is the only set relevant to embedded devices, isn't changed, and unless I'm mistaken the current rules are that whilst Desktop applications can use Bindings, Platform is pure C. Personally, I have an interest in embedded use, but see no problem with GTK# entering Bindings. There are some great applications written in Python and C#, and none of them are useful in the embedded context as they are *desktop* applications. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
