I've always been a Mozilla advocate. Mozilla's support for Web standards, tied with its open development cycle, powered by the remarkable bugzilla system made it immediately appeal to me. The legendary competition with MSIE is also a significant factor.
But I've really lost faith in Mozilla since this Firebird naming issue came up. It's not that I feel some kind of cameraderie for the Firebird-db people, but out of my own selfishness. If Mozilla can appropriate the name of a prominent Open Source project's name, what's to stop it from doing so again? Perhaps my project is next on the chopping block? Backed with the lawyers of AOL, I have started to fear that the Mozilla project could come to threaten my Open Source project. Perhaps they'll chose to rename their IRC client next?
When users apt-get install firebird, should they get the browser or the database? The only thing the "Firebird" name change is going to achieve is the dangerous precedent for an environment which encourages the free-for-all name grab; I know Mozilla advocates have stuck to their guns in the past on important issues, but they really need to give up the "Firebird" name. Please direct your guns towards the people who break Web standards and perpetuate broken software, not fellow Open Source projects, especially not for something as trivial as a stupid name. Life's just too short.
We may not agree with everything RMS has to say, but is it fair to use the "GNU is Not Unix" logo/category on an article with a headline about "Open Source" rather than "Free Software"? That's bound to antagonise some people who could probably do without it.
I worked in the City of London for two years as a consultant. It is a very abrasive environment. The attitude is pretty much, if you say "no" or "maybe" to any given project or demand, they will go and find someone else who can say "yes". Very often, the people giving the orders are far too conceited to debate technical issues. If you object to their analysis of the situation, you will be routed around. This is all very much why I left that line of work.
You could have saved yourself some porting by just compiling your java code with GCJ. GCJ allows you to compile your java byte code to native executables.
This might become an option in a few years, but the GNU classpath is as yet not complete enough for our years. We actually didn't find gcj output that performant, despite it being compiled to native code. The JRE still beat it in many cases.
Use SWT with Java. SWT uses Windows native widgets on Windows or GTK on Linux.
We also investigated this. SWT is a _horrendous_ API which offers very little abstraction. You end up writing your code once for the Gtk+ target, and again for the native Windows target. It isn't really a cross-platform abstraction like WxWindows, and it's probably the reason why the Eclipse codebase is so large. You end up writing your application for each UI target platform. Gtk# runs and integrates with the platform instead, so you only write your code once.
Either your telling a big lie or dont have your facts straight. Unless you can show hard facts your not going to sway anyone into believing interpreted code outperformed compiled.
I did mention the results are empirical, but they're also pretty obvious from where I stand. You don't need benchmarks when something performs, in some cases, eight times faster than the original implementation. I may well put togther some benchmarks and post them to mono-list or linuxtoday.com. I don't have benchmarks yet; does that make me a liar? Sigh.
What is exactly wrong with Java's use of native threads on Linux boxes?
It's pointless to interface with the threads layer directly when pthreads exists. It makes the runtime essentially unportable to other unices/operating systems. Mono plays nicely with the environment, so the runtime can just be compiled on any POSIX-compilant system. Linux is great, but being attached to it so firmly that your application breaks when Linus changes some internal interfaces is not.
We ported some of our internal Java business applications to C# for use with Mono, and emperical results already suggest the solution is several times faster than the Java code. The port was very easy, with each line of Java code mapping onto one line of C# or less. Porting the UI to Gtk# was more difficult, but we find the Gtk# code more maintainable and the UI, along with the Gtk+ WIMP plugin integrates much more nicely with Windows than SWING. We'll be investigating a switch to Linux over the next few months for some of our Point-of-Sales terminals as a result, and it should be easy thanks to the portability of Mono and Gtk#.
We also ported some of our backend tools for use with Mono. In use with the newly released Mono JIT runtime, Mini, we've achieved some truly stunning results. It turns out that some of the optimisations in the new JIT are better than those used by GCC, so once the code is loaded in memory, it performs better than raw C code. Although I don't yet have hard numbers to back up these result (the transition is still in progress), it has to be said that Mono is the real answer to Java performance. Being Open Source, we can also contribute back to the runtime to make it better suit our needs. It also plays nicely with RedHat 9's NPTL threading implementation, which is more than I can say for the current crop of Java JREs.
I gather the vast majority of students in the United States are more concerned about whether to buy Britney or Aguilera, what to wear for the party next weekend and perhaps, at a push, their education. Really, the number of people who understand the implications of a law like this is very low, even amongst so-called computer literate people.
Even computer science students have little awareness of the social aspects of computing these days. Courses tend to concentrate on "practical" aspects of computing like how to write Web apps in the latest edition of Microsoft Visual Studio.NET. They leave college after three years with little more actual understanding than when they signed up for the course.
Basically, nobody is handing themselves into the police because noone understands or cares. A sorry situation, but there you have it. There may be a valid way for the Americans to stop these laws from proliferating, but your suggestion will never work.
The idea is to get an indication of how much people are influenced by the possibility that their comment will be a first post or come near the top of the pile. If you look at the total number of comments for these kinds of stories, you'll notice there are more comments on the articles without a comment tally. The collected data will be useful in the fight against first post spam and trolls.
I've had my Zaurus 5500 for about a year now, but only recently switched to the OpenZaurus firmware. It's faster and more polished than the firmware that comes with the Zaurus, with the advantage of being constantly updated and running better Free Software equivalents like Konqueror Embedded. It's just a matter of copying the ROM images to CF and rebooting the Zaurus to flash the ROM; I'd recommend it to any Zaurus owner, including the author of the article.
I spent a brief time working as a contractor for a Linux distributor (now defunct). During that time, I was given the task of maintaining portions of XFree86's XInput and DRI code. What I saw, I didn't like.
Efforts to extend XFree86 to support modern graphics capabilities (XRender, Xft, R&R) are floundering because the level of skill needed to develop and maintain them is simply too high. The XFree86 codebase reinvents many wheels, is difficult to maintain and really does carry a lot of legacy footwork that makes it difficult to work with.
That said, XFree86 works amazingly well for what it is. I just don't think XFree86 development is sustainable. The same effects can be achieved with a thin layer like DirectFB without the overhead. You get the same functionality, usually better performant and with far less code necessary in the implementation. Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
I wouldn't go so far as to call XFree86 obsolete, but the technologies upon which it's based certainly are.
You've picked some very unfortunate examples. The DivX format is based on copyrighted Microsoft libraries that use patented compression techniques. Similarly, MP3 content creation has some very restrictive licensing terms, which in many cases require you to pay $0.02 per rip.
The chances are, if you're using these two formats you're breaking the law regardless of "fair use". If you had used Vorbis and perhaps MPEG2, your point would have been made more clearly.
MonoLOGO provides access to all.NET constructs from within LOGO. Its goal to be 99% compliant with ObjectLOGO (there are a few Macintosh APIs that won't make sense to support). A Berkeley LOGO compatibility layer is also planned.
If broadband Internet Telephony which doesn't touch the public switched telephone network (PSTN) is ruled as "Telecommunications", it could be very problematic for Linux distributions like RedHat, which ship software like GnomeMeeting, especially as they can be used to provide a cryptographic telecommunications system in conjunction with ssh tunneling or CIPE. Until distributors exclude such software from their distributions, software like RedHat 8.0 and Debian GNU/Linux 3.0 would be illegal in the United States.
Comparable programs I've written in Linux are all over 200K in size.
This application I'm developing in Gtk# to deploy on Linux must be a dream, then?
Why do you feel the need to put down Linux when you talk about the strengths of.NET? Has it ever occurred to you that thousands of people are writing C# programs on Linux already using Mono, with the additional stability and estabilshed development environment provided therein (emacs, vim)?
I really have to congratulate the GNOME team. I'm one of those desktop skeptics who has formerly been sorely unimpressed by the state of GNOME and KDE, but both have been forging ahead. As I've become more involved with GNOME development, I've come to recognise the relationship between the two projects: they do compete but the beautiful thing is that they cover two separate niches. Namely, KDE forges ahead with the latest features (Xft, KHTML) and has a nippier release schedule, while GNOME tends to integrate more external technologies and tends to adopt features when they're more mature.
GNOME 2.2 has caught up not just visually, but also feature-wise with nifty features like the SSH and SMB backends, but has also been getting rid of visual artefacs leftover from the era of CDE and Motif -- sometimes, a flat look is more appropriate than 3D buttons, for example. I think the 2.2 release puts GNOME back in the game in a big way.
Mono is doing very well indeed as a platform independent of.NET or the tie-ins that Microsoft is traditionally associated. There are already several independent Gtk# applications popping up and the ASP.NET implementation is showing real promise. There's a new page of screenshots here. The Gtk# debugger and documentation browser are fairly complete and have been developed in a minimal time-frame thanks to C#. Other pages worth looking at are gsirc and Platano.
Basically, what these pages show is that Mono is less like Wine and more like a complete new development environment for Linux that also has cross-platform ties. There's lots of innovation going on in the Mono community and that's filtering down into projects like GNOME and KDE through Gtk# and Qt#, for example. I say it's all good.
There are no SQL commands in the worm. It just initiates a bouncing ping between two MS SQL servers that continues until the network or one of the servers is brought down. An annotated dissection of the worm is provided here.
Waking up at 2AM after falling asleep at work on a Friday evening, to be greeted by a wall full of router racks lit up like a wall-shaped christmas tree is a sobering experience indeed. Needless to say I've been working since then to apply appropriate firewall rules accross our network to block port 1434. Once this blows over, it's time to start some real PostgreSQL advocacy..
I think the crunch test will come when Debian assesses the Helix server for eligibility. Until then, I'm treating this cautiously based on experience with Real. Without free codecs, this is useless anyway so it'll be interesting to see to what extent they've embraced Ogg Vorbis and the other technologies from Xiph.
Specifically, Mono is working on Gtk#, which provides.NET bindings for Gtk+. Gtk# This effectively provides an elegant OO interface to Gtk+. There's also work being done to make Gtk+ fit into the Windows environment, using native Windows and Windows XP widgets.
With Mono, it's already possible to run the same binary on Windows, FreeBSD and Linux on multiple architectures (x86 and ppc are well-supported now, with others in the pipeline). Mono seems to slowly be achieving the write-once-run-anywhere mantra that Java never succeeded with on the desktop.
Maybe I'm missing something, but I know the company I work at would rather pay something in the region of $500-$1,000 for the CPUs it has running Linux than $10,000-50,000 for a lawyer.
Standing up to something like this doesn't make sense from a financial point of view, as it's a lose-lose stance. Such is the nature of protection rackets.
Slashdot Mirror
I've been tipped off that the Mono guys are going to be showing their latest hacks. Look out for Jackson Harper's presentation.
I've always been a Mozilla advocate. Mozilla's support for Web standards, tied with its open development cycle, powered by the remarkable bugzilla system made it immediately appeal to me. The legendary competition with MSIE is also a significant factor.
But I've really lost faith in Mozilla since this Firebird naming issue came up. It's not that I feel some kind of cameraderie for the Firebird-db people, but out of my own selfishness. If Mozilla can appropriate the name of a prominent Open Source project's name, what's to stop it from doing so again? Perhaps my project is next on the chopping block? Backed with the lawyers of AOL, I have started to fear that the Mozilla project could come to threaten my Open Source project. Perhaps they'll chose to rename their IRC client next?
When users apt-get install firebird, should they get the browser or the database? The only thing the "Firebird" name change is going to achieve is the dangerous precedent for an environment which encourages the free-for-all name grab; I know Mozilla advocates have stuck to their guns in the past on important issues, but they really need to give up the "Firebird" name. Please direct your guns towards the people who break Web standards and perpetuate broken software, not fellow Open Source projects, especially not for something as trivial as a stupid name. Life's just too short.
We may not agree with everything RMS has to say, but is it fair to use the "GNU is Not Unix" logo/category on an article with a headline about "Open Source" rather than "Free Software"? That's bound to antagonise some people who could probably do without it.
I worked in the City of London for two years as a consultant. It is a very abrasive environment. The attitude is pretty much, if you say "no" or "maybe" to any given project or demand, they will go and find someone else who can say "yes". Very often, the people giving the orders are far too conceited to debate technical issues. If you object to their analysis of the situation, you will be routed around. This is all very much why I left that line of work.
Sorry, that should be "for our uses".
You could have saved yourself some porting by just compiling your java code with GCJ. GCJ allows you to compile your java byte code to native executables.
This might become an option in a few years, but the GNU classpath is as yet not complete enough for our years. We actually didn't find gcj output that performant, despite it being compiled to native code. The JRE still beat it in many cases.
Use SWT with Java. SWT uses Windows native widgets on Windows or GTK on Linux.
We also investigated this. SWT is a _horrendous_ API which offers very little abstraction. You end up writing your code once for the Gtk+ target, and again for the native Windows target. It isn't really a cross-platform abstraction like WxWindows, and it's probably the reason why the Eclipse codebase is so large. You end up writing your application for each UI target platform. Gtk# runs and integrates with the platform instead, so you only write your code once.
Either your telling a big lie or dont have your facts straight. Unless you can show hard facts your not going to sway anyone into believing interpreted code outperformed compiled.
I did mention the results are empirical, but they're also pretty obvious from where I stand. You don't need benchmarks when something performs, in some cases, eight times faster than the original implementation. I may well put togther some benchmarks and post them to mono-list or linuxtoday.com. I don't have benchmarks yet; does that make me a liar? Sigh.
What is exactly wrong with Java's use of native threads on Linux boxes?
It's pointless to interface with the threads layer directly when pthreads exists. It makes the runtime essentially unportable to other unices/operating systems. Mono plays nicely with the environment, so the runtime can just be compiled on any POSIX-compilant system. Linux is great, but being attached to it so firmly that your application breaks when Linus changes some internal interfaces is not.
We ported some of our internal Java business applications to C# for use with Mono, and emperical results already suggest the solution is several times faster than the Java code. The port was very easy, with each line of Java code mapping onto one line of C# or less. Porting the UI to Gtk# was more difficult, but we find the Gtk# code more maintainable and the UI, along with the Gtk+ WIMP plugin integrates much more nicely with Windows than SWING. We'll be investigating a switch to Linux over the next few months for some of our Point-of-Sales terminals as a result, and it should be easy thanks to the portability of Mono and Gtk#.
We also ported some of our backend tools for use with Mono. In use with the newly released Mono JIT runtime, Mini, we've achieved some truly stunning results. It turns out that some of the optimisations in the new JIT are better than those used by GCC, so once the code is loaded in memory, it performs better than raw C code. Although I don't yet have hard numbers to back up these result (the transition is still in progress), it has to be said that Mono is the real answer to Java performance. Being Open Source, we can also contribute back to the runtime to make it better suit our needs. It also plays nicely with RedHat 9's NPTL threading implementation, which is more than I can say for the current crop of Java JREs.
I gather the vast majority of students in the United States are more concerned about whether to buy Britney or Aguilera, what to wear for the party next weekend and perhaps, at a push, their education. Really, the number of people who understand the implications of a law like this is very low, even amongst so-called computer literate people.
.NET. They leave college after three years with little more actual understanding than when they signed up for the course.
Even computer science students have little awareness of the social aspects of computing these days. Courses tend to concentrate on "practical" aspects of computing like how to write Web apps in the latest edition of Microsoft Visual Studio
Basically, nobody is handing themselves into the police because noone understands or cares. A sorry situation, but there you have it. There may be a valid way for the Americans to stop these laws from proliferating, but your suggestion will never work.
The idea is to get an indication of how much people are influenced by the possibility that their comment will be a first post or come near the top of the pile. If you look at the total number of comments for these kinds of stories, you'll notice there are more comments on the articles without a comment tally. The collected data will be useful in the fight against first post spam and trolls.
I've had my Zaurus 5500 for about a year now, but only recently switched to the OpenZaurus firmware. It's faster and more polished than the firmware that comes with the Zaurus, with the advantage of being constantly updated and running better Free Software equivalents like Konqueror Embedded. It's just a matter of copying the ROM images to CF and rebooting the Zaurus to flash the ROM; I'd recommend it to any Zaurus owner, including the author of the article.
I spent a brief time working as a contractor for a Linux distributor (now defunct). During that time, I was given the task of maintaining portions of XFree86's XInput and DRI code. What I saw, I didn't like.
Efforts to extend XFree86 to support modern graphics capabilities (XRender, Xft, R&R) are floundering because the level of skill needed to develop and maintain them is simply too high. The XFree86 codebase reinvents many wheels, is difficult to maintain and really does carry a lot of legacy footwork that makes it difficult to work with.
That said, XFree86 works amazingly well for what it is. I just don't think XFree86 development is sustainable. The same effects can be achieved with a thin layer like DirectFB without the overhead. You get the same functionality, usually better performant and with far less code necessary in the implementation. Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
I wouldn't go so far as to call XFree86 obsolete, but the technologies upon which it's based certainly are.
You've picked some very unfortunate examples. The DivX format is based on copyrighted Microsoft libraries that use patented compression techniques. Similarly, MP3 content creation has some very restrictive licensing terms, which in many cases require you to pay $0.02 per rip.
The chances are, if you're using these two formats you're breaking the law regardless of "fair use". If you had used Vorbis and perhaps MPEG2, your point would have been made more clearly.
It's called MonoLOGO.:
.NET platform.
.NET constructs from within LOGO. Its goal to be 99% compliant with ObjectLOGO (there are a few Macintosh APIs that won't make sense to support). A Berkeley LOGO compatibility layer is also planned.
An implementation of LOGO for the
MonoLOGO provides access to all
Runs on Linux and has a Gtk# console interface.
If broadband Internet Telephony which doesn't touch the public switched telephone network (PSTN) is ruled as "Telecommunications", it could be very problematic for Linux distributions like RedHat, which ship software like GnomeMeeting, especially as they can be used to provide a cryptographic telecommunications system in conjunction with ssh tunneling or CIPE. Until distributors exclude such software from their distributions, software like RedHat 8.0 and Debian GNU/Linux 3.0 would be illegal in the United States.
I don't see how this can fly. Mono has prior art on pretty much all of this.
Comparable programs I've written in Linux are all over 200K in size.
.NET? Has it ever occurred to you that thousands of people are writing C# programs on Linux already using Mono, with the additional stability and estabilshed development environment provided therein (emacs, vim)?
This application I'm developing in Gtk# to deploy on Linux must be a dream, then?
Why do you feel the need to put down Linux when you talk about the strengths of
I really have to congratulate the GNOME team. I'm one of those desktop skeptics who has formerly been sorely unimpressed by the state of GNOME and KDE, but both have been forging ahead. As I've become more involved with GNOME development, I've come to recognise the relationship between the two projects: they do compete but the beautiful thing is that they cover two separate niches. Namely, KDE forges ahead with the latest features (Xft, KHTML) and has a nippier release schedule, while GNOME tends to integrate more external technologies and tends to adopt features when they're more mature.
GNOME 2.2 has caught up not just visually, but also feature-wise with nifty features like the SSH and SMB backends, but has also been getting rid of visual artefacs leftover from the era of CDE and Motif -- sometimes, a flat look is more appropriate than 3D buttons, for example. I think the 2.2 release puts GNOME back in the game in a big way.
For heaven's sake, don't mention the war!
Mono is doing very well indeed as a platform independent of .NET or the tie-ins that Microsoft is traditionally associated. There are already several independent Gtk# applications popping up and the ASP.NET implementation is showing real promise. There's a new page of screenshots here. The Gtk# debugger and documentation browser are fairly complete and have been developed in a minimal time-frame thanks to C#. Other pages worth looking at are gsirc and Platano.
Basically, what these pages show is that Mono is less like Wine and more like a complete new development environment for Linux that also has cross-platform ties. There's lots of innovation going on in the Mono community and that's filtering down into projects like GNOME and KDE through Gtk# and Qt#, for example. I say it's all good.
The URL is http://sites.defenselink.mil/
It hasn't been possible to add new domains or run queries since Friday, so don't even bother.
There are no SQL commands in the worm. It just initiates a bouncing ping between two MS SQL servers that continues until the network or one of the servers is brought down. An annotated dissection of the worm is provided here.
Waking up at 2AM after falling asleep at work on a Friday evening, to be greeted by a wall full of router racks lit up like a wall-shaped christmas tree is a sobering experience indeed. Needless to say I've been working since then to apply appropriate firewall rules accross our network to block port 1434. Once this blows over, it's time to start some real PostgreSQL advocacy..
I think the crunch test will come when Debian assesses the Helix server for eligibility. Until then, I'm treating this cautiously based on experience with Real. Without free codecs, this is useless anyway so it'll be interesting to see to what extent they've embraced Ogg Vorbis and the other technologies from Xiph.
Specifically, Mono is working on Gtk#, which provides .NET bindings for Gtk+. Gtk# This effectively provides an elegant OO interface to Gtk+. There's also work being done to make Gtk+ fit into the Windows environment, using native Windows and Windows XP widgets.
With Mono, it's already possible to run the same binary on Windows, FreeBSD and Linux on multiple architectures (x86 and ppc are well-supported now, with others in the pipeline). Mono seems to slowly be achieving the write-once-run-anywhere mantra that Java never succeeded with on the desktop.
Maybe I'm missing something, but I know the company I work at would rather pay something in the region of $500-$1,000 for the CPUs it has running Linux than $10,000-50,000 for a lawyer.
Standing up to something like this doesn't make sense from a financial point of view, as it's a lose-lose stance. Such is the nature of protection rackets.