Not sure why you've been modded as Funny, but whatever.
We already have plans to add a XAML designer to MonoDevelop. Last summer we started a project called LunarEclipse to do just that, but it was based on Silverlight 1.1 and a lot has changed since then.
Being that Moonlight is Free Software, someone could always provide patches to make it run on other platforms.
Currently Linux is our focus because we are working hard to catch up with Microsoft (and because it's the platform that all of us Moonlight developers actually use on our desktops), but we would gladly accept patches to make it work on other platforms. We'd love to have it work on BSD and OSX (and in fact, there have been 2 contributors sending us patches to help it build on Windows).
The main thing that would have to be done to make Moonlight work on the BSDs is to add support for an OSS audio backend, we currently only have ALSA and PulseAudio backends.
I'm guessing he meant "officially blessed" (which would be correct), not "given permission". The Mono team did not need Microsoft's permission to implement Moonlight. No one needs permission to implement a re-implementation of Silverlight as far as I'm aware.
Moonlight is a clean re-implementation of Silverlight based on the docs at http://msdn.microsoft.com/ Microsoft's test suites (which they have provided to us) and writing our own test cases to figure out how Silverlight handles certain cases where the docs were unclear (which we have tried to document on our own wiki: http://www.mono-project.com/MoonlightQuirks - we've also included all of our own test suites in the moonlight source repository).
Roy Schestowitz is routinely proven wrong on his own website because he fails to read the articles he claims support his accusations. If you actually READ the articles he links to (after following link-back after link-back to his own articles), you discover quickly that the article does not support his claims and often outright rejects the claims he made.
Moonlight is so far only reliable for 1.0 sites (although 2.0 is coming along rapidly, especially since Microsoft has released their Silverlight 2.0 System.Windows.Controls source code as Free Software under the MS-PL which is basically MIT/X11 + GPLv3-like Patent Protection).
possibly by prodcing a new version of Silverlight and NOT releasing any specifications on its new features
Well, if that happens... two things:
1. At least Linux users will be able to view Silverlight content up until that point
2. We'll simply have to do what every other piece of Free Software does that interacts with proprietary protocols: Reverse-Engineer.
For the most part that's what we've been doing anyway, we write test cases to see how things are supposed to work and then implement our logic to do the same thing.
Very likely that this is how the Gnash developers work as well.
Nothing new here.
and making sure any Silverlight-producing software only produces those new Moonlight incompatible features.
Sure, they could make Expression Blend output some brand-new XML that is incompatible with their previous version (making it incompatible with WPF), but that would hurt them as well and piss off a lot of WPF/Silverlight developers.
So, unlikely.
Then Microsoft starts spouting FUD at them about patent violations, despite having aided them before.
Yea, that won't work. They'd be laughed out of court.
The rest of your post is just so hilariously misinformed it's not even worth responding to. Same old arguments by FUD-slingers.
Mind telling me what you do for a living? Likely you make money by screwing people over, no matter what job you have, even if you work for a non-profit organization.
Hell, I bet you're a used-car salesman.
Get off your make-believe moral high-horse and recognize that you are no better than the poster you replied to.
As was already mentioned earlier in this thread, if Nokia's software uses native (rather than managed) libraries to build their.NET 3.0 program, then they clearly didn't care about it being cross-platform.
If they built it purely in managed code and it doesn't work under Mono, then it is just a bug in Mono - file a bug so that we can fix it.
With the latter, proprietary type, the OS is not irrelevant at all. Since he is currently working on porting Silverlight to Linux, how could he not know this?
Uh, that's exactly why he's porting Silverlight to Linux. It makes it not depend on the OS.
AJAX sucks, everyone knows that. I think just about everyone agrees that Flash, too, is crap (besides not being open source, making it no better than Silverlight and arguably worse because the Silverlight formats are at least open).
Silverlight 2.0 (Silverlight 1.0 isn't much of a change from Flash) really is a far better solution, giving developers a lot more flexibility and power. Is it unfortunate that Microsoft developed the technology? Sure, but you can't blame Microsoft for bringing a better platform to the table.
For developers wanting to develop the next generation of "web 2.0" applications, Flash is definitely the wrong choice and AJAX isn't a great choice either.
Maybe the Java community will develop something equally useful, a really fast canvas that can be manipulated by managed languages that run in th JVM, but there doesn't seem to be much of a push atm.
I think that it's a shame that Java isn't putting up more of a fight, especially now that Java is moving toward the GPL. Sun needs to get its act together and do something about it.
Hula isn't a webmail client. it's a mail/calendar server based on Novell's existing NetMail server software (which is used by a number of companies from what I understand - it's also the server software used by myrealbox.com)
NetMail is being opened up and relicensed under the LGPL and being renamed to Hula
Being that I'm the author of the IMAP code in Evolution, I've found a few niggles in GW's IMAP code but they have all been resolved and they are quite eager to fix any bugs you can find in their IMAP implementation.
This was brought up by Matt Wilson of Red Hat in the irc channel earlier today and I believe the Hula team is addressing the issue
if I recall correctly, msw said that copying the kernel's asm/atomic.h into the apropriate location (/usr/include/asm or some such?) would fix the problem.
Matt also had some Makefile.am fixes for systems with kerberos headers/libs in a location other than/usr
you might try checking the irc channel for better/more accurate info (I'm going on memory of a discussion I skimmed 6 hours ago)
If you fully read the message I sent and what I was responding to, you'll notice I only threatened to quit if we decided to do a native win32 port (e.g. not using GNOME libs).
Since Tor is the one doing all the effort to port to win32 (non-native, e.g. depending on GNOME libs), presumably this will limit the amount of #ifdef's in the code. However, based on a recent patch I received to allow building my MIME library (GMime) over to win32, a lot of POSIX functionality is missing in the win32 environment... things like fsync() (which is useful for being able to guarentee things like data integrity on disc - without this functionality, it'd be hard for Evolution to be sure data was actually written to disc)
According to Tor, Win32 also treats sockets and file descriptors differently (e.g. you can't use socket functions on a file descriptor or vise versa)
Oh, and to add to the fun - socket/file descriptor ids overlap - e.g. it's possible for both a file descript and a socket descriptor to have an id of 33.
He's also noted that each of sockets and file descriptors have different subsets of POSIX functions available.
Go Win32! Go!
These are the sorts of things that make me cringe when talking about a Win32 port (native or not) of Evolution.
The maintainance of Evolution after a win32 port might (s/might/will certainly/) also become a nightmare. Imagine, if you will, that a user submits a bug report to me saying it crashes or misbehaves in some fashion and it turns out the problem is because of a bug in the Win32 POSIX implementation? It's bad enough when we find bugs in Glibc and the Linux Kernel, nevermind adding this whole new stack of problems that I'm sure we'll encounter once a win32 port has been done.
So to summarise: the win32 port of Evolution will not be a native win32 port which reduces my nightmare considerably so unless Tor submits a patch to me which adds a considerable number of #ifdefs all over the place that make my head scream, I will likely not be quitting.
For the most part I like my job, I like my coworkers, and... well, I like being payed (even tho I wish I got payed a lot more than I am - rent isn't cheap in Cambridge)
wow, oGALAXYo sure likes to reply to his own posts pretending to be a different AC each time.
stop spreading FUD. You don't have to FUD GNOME just to praise KDE, if KDE is so great you should be able to praise it without having to bash GNOME.
just because a widget is deprecated doesn't mean you can't use it, it just means that in gtk-3.0 it will be gone (or there is a good chance it will be).
stop referring to yourself in the third person. we all know you are a troll. it doesn't matter if what you say has valid points or not, you are only posting it to be a wanker.
Slashdot Mirror
We're already hard at work on Moonlight 2.0 and things are progressing quickly.
Not sure why you've been modded as Funny, but whatever.
We already have plans to add a XAML designer to MonoDevelop. Last summer we started a project called LunarEclipse to do just that, but it was based on Silverlight 1.1 and a lot has changed since then.
Being that Moonlight is Free Software, someone could always provide patches to make it run on other platforms.
Currently Linux is our focus because we are working hard to catch up with Microsoft (and because it's the platform that all of us Moonlight developers actually use on our desktops), but we would gladly accept patches to make it work on other platforms. We'd love to have it work on BSD and OSX (and in fact, there have been 2 contributors sending us patches to help it build on Windows).
The main thing that would have to be done to make Moonlight work on the BSDs is to add support for an OSS audio backend, we currently only have ALSA and PulseAudio backends.
I'm guessing he meant "officially blessed" (which would be correct), not "given permission". The Mono team did not need Microsoft's permission to implement Moonlight. No one needs permission to implement a re-implementation of Silverlight as far as I'm aware.
Moonlight is a clean re-implementation of Silverlight based on the docs at http://msdn.microsoft.com/ Microsoft's test suites (which they have provided to us) and writing our own test cases to figure out how Silverlight handles certain cases where the docs were unclear (which we have tried to document on our own wiki: http://www.mono-project.com/MoonlightQuirks - we've also included all of our own test suites in the moonlight source repository).
Roy Schestowitz is routinely proven wrong on his own website because he fails to read the articles he claims support his accusations. If you actually READ the articles he links to (after following link-back after link-back to his own articles), you discover quickly that the article does not support his claims and often outright rejects the claims he made.
NBCOlympics.com uses Silverlight 2.0 BETA.
Moonlight is so far only reliable for 1.0 sites (although 2.0 is coming along rapidly, especially since Microsoft has released their Silverlight 2.0 System.Windows.Controls source code as Free Software under the MS-PL which is basically MIT/X11 + GPLv3-like Patent Protection).
Well, if that happens... two things:
1. At least Linux users will be able to view Silverlight content up until that point
2. We'll simply have to do what every other piece of Free Software does that interacts with proprietary protocols: Reverse-Engineer.
For the most part that's what we've been doing anyway, we write test cases to see how things are supposed to work and then implement our logic to do the same thing.
Very likely that this is how the Gnash developers work as well.
Nothing new here.
Sure, they could make Expression Blend output some brand-new XML that is incompatible with their previous version (making it incompatible with WPF), but that would hurt them as well and piss off a lot of WPF/Silverlight developers.
So, unlikely.
Yea, that won't work. They'd be laughed out of court.
The rest of your post is just so hilariously misinformed it's not even worth responding to. Same old arguments by FUD-slingers.
key phrase being: "adequate for most non-enterprise development work"
Enterprise is where the money is, and always will, be at.
Mind telling me what you do for a living? Likely you make money by screwing people over, no matter what job you have, even if you work for a non-profit organization.
Hell, I bet you're a used-car salesman.
Get off your make-believe moral high-horse and recognize that you are no better than the poster you replied to.
As was already mentioned earlier in this thread, if Nokia's software uses native (rather than managed) libraries to build their .NET 3.0 program, then they clearly didn't care about it being cross-platform.
If they built it purely in managed code and it doesn't work under Mono, then it is just a bug in Mono - file a bug so that we can fix it.
No need to insult us.
It's been a dead project since the beginning.
Seriously tho, 6+ years of "prototyping"?
Evolution 1.0 is more usable than Chandler and it only took a year or 2 to implement iirc.
Uh, that's exactly why he's porting Silverlight to Linux. It makes it not depend on the OS.
AJAX sucks, everyone knows that. I think just about everyone agrees that Flash, too, is crap (besides not being open source, making it no better than Silverlight and arguably worse because the Silverlight formats are at least open).
Silverlight 2.0 (Silverlight 1.0 isn't much of a change from Flash) really is a far better solution, giving developers a lot more flexibility and power. Is it unfortunate that Microsoft developed the technology? Sure, but you can't blame Microsoft for bringing a better platform to the table.
For developers wanting to develop the next generation of "web 2.0" applications, Flash is definitely the wrong choice and AJAX isn't a great choice either.
Maybe the Java community will develop something equally useful, a really fast canvas that can be manipulated by managed languages that run in th JVM, but there doesn't seem to be much of a push atm.
I think that it's a shame that Java isn't putting up more of a fight, especially now that Java is moving toward the GPL. Sun needs to get its act together and do something about it.
Hula isn't a webmail client. it's a mail/calendar server based on Novell's existing NetMail server software (which is used by a number of companies from what I understand - it's also the server software used by myrealbox.com)
NetMail is being opened up and relicensed under the LGPL and being renamed to Hula
like what?
Being that I'm the author of the IMAP code in Evolution, I've found a few niggles in GW's IMAP code but they have all been resolved and they are quite eager to fix any bugs you can find in their IMAP implementation.
This was brought up by Matt Wilson of Red Hat in the irc channel earlier today and I believe the Hula team is addressing the issue
/usr
if I recall correctly, msw said that copying the kernel's asm/atomic.h into the apropriate location (/usr/include/asm or some such?) would fix the problem.
Matt also had some Makefile.am fixes for systems with kerberos headers/libs in a location other than
you might try checking the irc channel for better/more accurate info (I'm going on memory of a discussion I skimmed 6 hours ago)
I'm not a Novell sales rep, but I'd have to respond to your question with "That depends on the needs of your 500 user company."
"500 users" isn't enough information to formulate which server software best fits your needs.
Evolution (also by Novell) is an Outlook client replacement that runs on UNIX and is being ported to Win32.
iFolder is peer-to-peer. (altho it can also be done via server)
Hula is more than a webmail front-end, it is also the server.
Hula isn't abandonware. It is anything *but*. You have no idea what you are talking about.
If by twit you mean someone worth far more to society than you, then yes... I am a twit.
But what does that make you?
Grow up.
If you fully read the message I sent and what I was responding to, you'll notice I only threatened to quit if we decided to do a native win32 port (e.g. not using GNOME libs).
Since Tor is the one doing all the effort to port to win32 (non-native, e.g. depending on GNOME libs), presumably this will limit the amount of #ifdef's in the code. However, based on a recent patch I received to allow building my MIME library (GMime) over to win32, a lot of POSIX functionality is missing in the win32 environment... things like fsync() (which is useful for being able to guarentee things like data integrity on disc - without this functionality, it'd be hard for Evolution to be sure data was actually written to disc)
According to Tor, Win32 also treats sockets and file descriptors differently (e.g. you can't use socket functions on a file descriptor or vise versa)
Oh, and to add to the fun - socket/file descriptor ids overlap - e.g. it's possible for both a file descript and a socket descriptor to have an id of 33.
He's also noted that each of sockets and file descriptors have different subsets of POSIX functions available.
Go Win32! Go!
These are the sorts of things that make me cringe when talking about a Win32 port (native or not) of Evolution.
The maintainance of Evolution after a win32 port might (s/might/will certainly/) also become a nightmare. Imagine, if you will, that a user submits a bug report to me saying it crashes or misbehaves in some fashion and it turns out the problem is because of a bug in the Win32 POSIX implementation? It's bad enough when we find bugs in Glibc and the Linux Kernel, nevermind adding this whole new stack of problems that I'm sure we'll encounter once a win32 port has been done.
So to summarise: the win32 port of Evolution will not be a native win32 port which reduces my nightmare considerably so unless Tor submits a patch to me which adds a considerable number of #ifdefs all over the place that make my head scream, I will likely not be quitting.
For the most part I like my job, I like my coworkers, and... well, I like being payed (even tho I wish I got payed a lot more than I am - rent isn't cheap in Cambridge)
Evolution already does spell-checking and has since 1.0 (before 1.0 actually)
;-)
if you'd like Evolution ported to Windows, better get crankin'
patches welcome.
right, but ONLY if the Exchange admin has enabled IMAP or POP.
wow, oGALAXYo sure likes to reply to his own posts pretending to be a different AC each time.
stop spreading FUD. You don't have to FUD GNOME just to praise KDE, if KDE is so great you should be able to praise it without having to bash GNOME.
just because a widget is deprecated doesn't mean you can't use it, it just means that in gtk-3.0 it will be gone (or there is a good chance it will be).
Qt does the same thing. sheesh.
stop referring to yourself in the third person. we all know you are a troll. it doesn't matter if what you say has valid points or not, you are only posting it to be a wanker.