Re: [Mono-dev] signcode
On Thu, 2009-02-26 at 13:05 -0800, mastedm wrote: Hi. How can I use signcode in command line Yes, mono includes a managed signcode.exe tool that is very similar (including command-line options) to the (unmanaged) one MS has on Windows. or from C/C++ code in Linux? Sure, you can call it directly using mono or by calling the bundled shell script. Have fun! Sebastien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Architectural decisions behind mod_mono
I'm going to have to disagree with Rodrigo here. For MySpace/Facebook level web applications (the op's hypothetical target) the reliability issue is a bit of a red herring. In these environments applications are frequently segregated onto their own machines for operational reasons. Thus, if an app has crapped out on a machine, the whole machine is useless. It doesn't matter that the web server is still up and responding to requests (presumably with 500 errors). In these situations, application isolation takes a backseat to performance. Unfortunately Microsoft has a long history of confusion on this topic. I remember back when IIS5 was being developed I implored the IIS team make it possible to write filters as kernel modules. I insisted that the extra kernel transitions needed to invoke my legacy encryption filter was going to kill performance. Their reaction was 'No way! You might blue-screen the machine!'. They never did understand that, whether it was in user space or the kernel, if there was a fatal bug in my filter the machine was no more useful than a doorstop. This is a minor issue that should pose no scalability issues on itself. There's no question that the number of process boundary transitions per request has a significant impact on performance. If that weren't the case we'd all be running microkernels and IIS would never have been pushed into the OS. That said, I will agree that this is rarely the dominant performance issue. Usually the application's (mis-)behavior swamps that of the infrastructure. Still, it would be nice to have a high-performance, cross platform ASP.NET hosting environment that could wring the most out of what ever OS it was running on. -- Jay ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Developing an Gnome-Panel Addon with mono?
How can I develop an Gnome-Panel addon with mono? Isn't it possible? For example I just want to develope a simple clock, but i don't know how to start. I found nothing by google and this page. Can anyone help me? -- View this message in context: http://www.nabble.com/Developing-an-Gnome-Panel-Addon-with-mono--tp22413716p22413716.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Developing an Gnome-Panel Addon with mono?
On 3/9/2009 13:28, goto wrote: How can I develop an Gnome-Panel addon with mono? Isn't it possible? For example I just want to develope a simple clock, but i don't know how to start. I found nothing by google and this page. Can anyone help me? Hi, You can read Tomboy's source code to find out how they develop their GNOME Panel Applet. That'll probably be the best way to get started. --Bojan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Architectural decisions behind mod_mono
Unfortunately Microsoft has a long history of confusion on this topic. I remember back when IIS5 was being developed I implored the IIS team make it possible to write filters as kernel modules. I insisted that the extra kernel transitions needed to invoke my legacy encryption filter was going to kill performance. Their reaction was 'No way! You might blue-screen the machine!'. They never did understand that, whether it was in user space or the kernel, if there was a fatal bug in my filter the machine was no more useful than a doorstop. Maybe but these kind of performance issues can usually be solved through horizontal scaling, something which applications like Facebook should have no problem with. Bluescreens on shared hosting boxes however would be very bad, and the shared hosting market is very important for webdevelopment frameworks to attract new developers. That and maybe debugging issues, it's tough to debug something if it keeps bluescreening on you. If a process dies because of a segmentation fault, you just restart the process so it can resume work while you figure out what happened. This is significantly less downtime, which means especially much for hosting with uptime guarantees. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Architectural decisions behind mod_mono
Hey, They never did understand that, whether it was in user space or the kernel, if there was a fatal bug in my filter the machine was no more useful than a doorstop. So if there's a bug in your filter which caused every 100th request to bluescreen the computer, yes you're right. Your computer would be no more useful than a doorstop. But if every 100th request just crashed the process, you could just restart the process and continue fine for the next 99 requests. Which solution is better? Does performance even come into the equation here? Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Architectural decisions behind mod_mono
Tinco Andringa wrote: Unfortunately Microsoft has a long history of confusion on this topic. I remember back when IIS5 was being developed I implored the IIS team make it possible to write filters as kernel modules. I insisted that the extra kernel transitions needed to invoke my legacy encryption filter was going to kill performance. Their reaction was 'No way! You might blue-screen the machine!'. They never did understand that, whether it was in user space or the kernel, if there was a fatal bug in my filter the machine was no more useful than a doorstop. Maybe but these kind of performance issues can usually be solved through horizontal scaling, something which applications like Facebook should have no problem with. Horizontal scaling is almost always the answer here. However the question is not simply Can I handle the load?, but rather At what cost per user can I handle the load?. Thus at a large enough scale the efficiency of the request handling infrastructure can become important. Bluescreens on shared hosting boxes however would be very bad, and the shared hosting market is very important for webdevelopment frameworks to attract new developers. That and maybe debugging issues, it's tough to debug something if it keeps bluescreening on you. If a process dies because of a segmentation fault, you just restart the process so it can resume work while you figure out what happened. This is significantly less downtime, which means especially much for hosting with uptime guarantees. I totally agree with you. Where the goal is a broad range of applications running on as little hardware as possible, fault isolation is essential, even if it costs you performance (hence the business of VMware). However sometimes when you're trying to scale a small range of tightly controlled applications, the reverse is true, and performance becomes more important than isolation. -- Jay ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announcing Mono 2.4 Preview RC 2...
Hey Everyone, We've just released Mono 2.4 RC 2 today! Please help us out by giving it a try with your applications. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.4 here: https://bugzilla.novell.com/buglist.cgi?query_format=advancedclassification=Monotarget_milestone=2.4.xorder=bugs.bug_status%2Cbugs.bug_severity The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you add [Regression] to the beginning of the summary of the bug, then it is much more likely your bug will get fixed. Please help the Mono team to make 2.4 the best ever. Thanks! Mono QA ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Architectural decisions behind mod_mono
Alan McGovern wrote: They never did understand that, whether it was in user space or the kernel, if there was a fatal bug in my filter the machine was no more useful than a doorstop. So if there's a bug in your filter which caused every 100th request to bluescreen the computer, yes you're right. Your computer would be no more useful than a doorstop. But if every 100th request just crashed the process, you could just restart the process and continue fine for the next 99 requests. Which solution is better? Does performance even come into the equation here? At the loads I'm talking about a failure every 100th request occurs at least once a second per server if not faster. Even if I only loose the application process, if all the servers in my 300 server network are failing once a second, I've got a big problem. (At a minimum imagine the reconnect storm to the back-end servers if the web servers loose their connection pools once a second). Still, its valid to say that at some intermediate failure rate, process failures would be preferable to blue screens. However the decision ultimately comes down to a trade off between the cost to QA the software to an acceptable failure rate verses the cost of adding and maintaining more machines. And my point to the IIS people was that I should be the one to make that decision, not them. In a similar vein I think it would be useful to have a high-performance ASP.NET hosting app that avoids the need for multiple process boundary transitions. Note that I'm not saying that this is a priority for the mono development effort, or even that the mono team should develop such a thing, just that it would make sense from a cost-benefit standpoint in some circumstances. -- Jay ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
