If someone else downloads child porn, they are the ones committing the crime - there is no reason the cops would arrest you for it if they knew it wasn't you. The police are not in charge of inventing the law, and even if they did say something like you describe, that doesn't mean it is true.
I suppose you could recompress both images as JPEG with various quality settings, then do a pixel-by-pixel comparison computing a difference measure between each of the two source images and its recompressed version. Presumably, the one with more JPEG artefacts to start with will be more similar to its compressed version, at a certain key level of compression. This relies on your compression program generating the same kind of artefacts as the one used to make the images, but I suppose that cjpeg with the default settings has a good chance of working.
Failing that, just take the larger (in bytes) of the two JPEG files...
Right because we all know that sensible coders get it right first time, and have every feature you'll ever want already implemented in version 1.0, and so never need to push out a new version of their program, and if for some unthinkable reason they do want to make a new release, the users positively enjoy watching the download creep through as slowly as possible...
BTW, have you seen the size of the package updates for your Linux distribution recently?
Fedora is already using binary diffs to speed up downloading updates - see yum-presto. With a better binary diff algorithm, the RPM updates can hopefully be made even smaller. As the Google developers note, making smaller update packages isn't just a 'nice to have' - it really makes a difference in getting vulnerabilities patched faster and cuts the bandwidth bill for the vendor and its mirror sites. Remembering my experiences downloading updates over a 56k modem, I am also strongly in favour of anything that makes updating faster for the user.
Obviously, the #1 market for standalone GPS receivers is the OpenStreetMap mapping community, who wander around making GPS traces to create a free world map. I've found that for this job you want the most sensitive and accurate receiver possible, and a standalone unit from Garmin seems to give better quality data than the GPS sensor built into my BlackBerry, especially in city areas where not much of the sky is visible.
Why do you suppose that ASP.NET, Winforms and so on are 'the patent infringing parts'? Just because they are APIs made by Microsoft, they must be covered by enforceable software patents held by that company? Because of the word 'Microsoft'?
The Mono project has a commitment to remove code that is found to be a patent violation; I think there is no reason to suppose that Mono's Winforms or other Microsoft-compatible APIs are any more of a patent risk than running Samba or Firefox.
Well, you know, Mono is open source, all of it. Even the parts which are not covered by Microsoft's patent promise.
The Linux kernel is another piece of software which is not covered by Microsoft's patent promise. Indeed, in the USA Microsoft owns at least one software patent (the VFAT one) which applies to Linux, and is actively suing people for it. So by your argument Linux is not open source?
As far as I know the enforceable patents held by Microsoft, the ones which cover anything at all novel, are those for the runtime engine (the CLR). These are included in the patent promise. There is no reason to suppose that because Mono's Winforms implementation implements an API originally made by Microsoft, it is any more risky than Samba or the many other free reimplementations of proprietary APIs.
Sun has committed only to not asserting patents against their own GPL implementation; any other implementation is fair game for their intellectual property lawyers.
Not true, as far as I can see: the Java SE licence says 'Sun also grants you a... license... to create and/or distribute an Independent Implementation of the Specification...'. From my reading of the legalese it seems that any compliant Java implementation is covered.
But remember that not only Sun owns software patents which cover your Java program, and not only Microsoft owns swpats covering your.NET program. A legal risk assessment is not merely an evilness competition between Microsoft and Sun!
If I'm migrating.net apps to Linux, I would target Java or other known Linux platform, rather than Mono with unknown status in terms of.net framework compatibility.
As others have pointed out, that's not migrating an existing app, that's rewriting it. As for 'unknown compatibility', not everything in.NET is implemented in Mono (WPF for example), but the libraries that are there work well. There is a migration analyser which will tell you if your app uses Windows-specific calls or APIs not yet supported by Mono. There is also the new project M/Invoke which can let.NET apps that call native Windows APIs run under Linux by replacing the P/Invoke call with a call to some managed code (which needs to be written, Wine-like).
I'm sorry, but wasn't part of the point of Mono (and.NET, actually) compatibility and cross-platform independence? So if I require Mono-specific libraries to use Mono, and Microsoft-owned libraries to use.NET, what is the advantage of using the framework?
Mono runs on Windows and Mac OS X too, so even if you are using something totally Mono-specific, you still have a cross-platform application. (Banshee and Tomboy have been ported to Windows without too much bother.) If you're talking of a pure C# library (for example, Mono.Addins) rather than a native binding, then it can easily be used with either runtime. Finally, you can use Winforms, ASP.NET and ADO.NET with Mono, which provides its own free implementation; you won't be covered by the patent promise in today's announcement, but you may not think that matters.
Nowadays there's a case to be argued that Mono is 'the' C# and CLR implementation which runs everywhere (Linux, Playstation 3, iPhone, Windows, etc) and can be easily adapted to your needs, while Microsoft's implementation is a reasonable alternative for people who are stuck on Windows. Kind of like how gcc is the standard C and C++ compiler, even though most Windows native programs are still built with proprietary compilers. This is overstating the case a bit - Mono isn't there yet, and new developments in the C# language still come out of Redmond - but Mono is certainly a strong enough competitor to stop C# being synonymous with Microsoft's implementation.
Hmm, you are right since SharpDevelop is a free app using Winforms, and so is Paint.NET. I was thinking of free Linux apps (that might also be ported to Windows one day) rather than free Windows apps (that might be ported to Linux). I meant to say that nobody would write *Linux* free applications using Winforms.
Are you sure? It has less noise made on Internet discussion forums about patents, that is certain. That doesn't mean the risk is less. Don't assume that only Sun holds patents relevant to Java, or that only Microsoft holds patents relevant to.NET.
For what it's worth I really like and prefer Mono - especially Banshee (is there an equivalent for Java?) and I want to develop for it but the Community Promise only covers the ECMA part of.net. Without the other libraries I fear Mono is hamstrung.
It depends what you want to do. I assume you are developing on Linux? In that case you will probably want to use Linux native libraries with C# bindings, not the Winforms implementation shipped by Mono.
At least with Java I know where I stand, all the libraries are included and the functionality is already there.
I think this is the big difference: in Java you tend to program in a 'pure Java' bubble where almost all the libraries you use are in Java. Mono/C# applications like Banshee link to a lot of native Linux libraries like GTK+ and GStreamer. Of course there is nothing to stop Java using native libraries too (see java-gnome) but so far, this hasn't caught on to the extent it has for Mono. Remember that Mono was originally created by Linux desktop programmers as an easier way to make GNOME applications, while Java's heritage is as the One True Platform for writing code that runs on any OS, and so needs a complete set of Java libraries.
If you program to the latest version of the language (which is the default in Mono) you are not covered by this announcement.
Only if there are enforceable patents held by Microsoft which are specific to C# (the language) version 3. You see, C# 3 compiles to the same bytecode as C# 2, and runs on the same virtual machine. The MS patents that people worry about are on implementation techniques for the virtual machine. You use the same ECMA-specified virtual machine to run bytecode compiled from C# 2 and C# 3, so it's covered.
If there are (enforceable) software patents covering the language itself, specifically the new features in C# 3, then you have a point.
It's not FUD. One of the goals of the Mono project is compatibility with.NET applications and that means supporting things like Windows Forms.
You're right, but the most common criticism of Mono before this announcement was that free software distributed with Linux carried a patent risk. The Winforms stuff is still a goal of the Mono project, but there is no reason for Linux distributions to install it. The non-ECMA parts of Mono are still very useful for companies migrating existing Windows legacy apps to Linux, but nobody would write a new free application with Winforms starting from scratch (GTK# is a lot better).
So the Windows.Forms and other Microsoft APIs move to a separate 'Mono-non-ECMA' package, which can be treated a bit like Wine: you wouldn't really want to install it by default or develop against it, but it can be invaluable if you have existing Windows software you want to run.
So really, even if MS adds the 2 standards to their Community Promise, that still doesn't mean you get anything useful - if you write a simple app that does nothing, you're fine. If you want DB access, or web serving, or a GUI.. you're still in the same problem as before.
There are a few flaws with this argument. Firstly, if you want a GUI then Winforms is not the only choice. In fact, GTK# is a lot nicer, on Windows and Mac as well as on Linux, and all the free Mono apps such Banshee use GTK#, and C# bindings to other standard Linux libraries. They do not use ASP.NET, Winforms or other more Windowsy stuff.
Secondly, the software patents that Microsoft owns and which people are worried about are the ones on the.NET runtime engine itself (part of the ECMA standards). I'm not aware that they hold enforceable swpats for more pedestrian things like database bindings (though like every large company, they have a portfolio of crappy software patents for 'mutual assured destruction' purposes).
I think it's a good idea, though, to split the Mono distribution into the ECMA-standard part (which is now demonstrably safe from patent attacks by Microsoft, though sadly not from other software companies and patent trolls) and a more Microsoft-flavoured, free-reimplementation-of-proprietary-APIs part, which is more like Wine and other libraries used to port existing Windows apps to Linux. If you are worried that the classes for database access or Winforms GUI expose you to patent risk, don't install them - few free programs use them anyway. That should keep everyone happy.
It's not listed on Microsoft's list of products under the Community Promise so I'm going to refrain from breaking out the champagne until all the facts are finalized.
According to a comment by Miguel on his blog,
Brian Goldfarb at Microsoft has said that the update will be coming, it was just not done on time for the Peter Galli's announcement.
A processor-intensive test will show which filesystem has the most overhead WRT the processor.
Only if it's a filesystem-processor-intensive test, that is, you are making the filesystem work hard and (depending on how efficient it is) chew lots of CPU. Giving the filesystem easy work, while running something CPU-intensive like bzip2 separately, is a good benchmark for bzip2 but it doesn't tell you much about the fs.
But you also want a benchmark that shows the performance of CPU-intensive appliations while the file system is under heavy use.
You do want that, but I'm pretty sure that bzip2 isn't it. Compressing a file is actually pretty light work for the filesystem. You need to read some blocks sequentially, then write some blocks sequentially. Compressing lots of small files is better, but the access is still likely to be pretty one-at-a-time. More challenging would be a task that needs to read and write lots of files of varying size, across complex directory structures, with fairly random access patterns. A parallel kernel compile would be nearer the mark, though even that may not be demanding enough to make a really good benchmark.
The first benchmark on page 2 is 'Parallel BZIP2 Compression'. They are testing the speed of running bzip2, a CPU-intensive program, and drawing conclusions about the filesystem? Sure, there will be some time taken to read and write the large file from disk, but it is dwarfed by the computation time. They then say which filesystems are fastest, but 'these margins were small'. Well, not really surprising. Are the results statistically significant or was it just luck? (They mention running the tests several times, but don't give variance etc.)
All benchmarks are flawed, but I think these really could be improved. Surely a good filesystem benchmark is one that exercises the filesystem and the disk, but little else - unless you believe in the possibility of some magic side-effect whereby the processor is slowed down because you're using a different filesystem. (It's just about possible, e.g. if the filesystem gobbles lots of memory and causes your machine to thrash, but in the real world it's a waste of time running these things.)
On second thoughts I might be wrong - did you mean you used SORBS to help with greylisting? So a host from a block of IP addresses in SORBS could still send mail but with a few seconds' delay in the SMTP chatter? In that case you are preventing spam from being sent but without needing to drop any message, so my bad.
Wow, I am quite surprised that it's illegal to ask about drug use. Of course you have a right to privacy, and a right to refuse to answer any question you are asked - but surely, the employer equally has a right to choose who they employ. After all, nobody forces you to work there, and you are free to choose an employer more in tune with your personal beliefs. For some things, such as skin colour or religion, there are nasty scenarios where particular groups get disadvantaged, and we legislate to avoid that - but taking drugs or starting a family are personal choices.
Slashdot Mirror
How does any kind of stock trading benefit anyone other than the traders themselves?
It means when you've tried it once, you'll want some more?
If someone else downloads child porn, they are the ones committing the crime - there is no reason the cops would arrest you for it if they knew it wasn't you. The police are not in charge of inventing the law, and even if they did say something like you describe, that doesn't mean it is true.
I suppose you could recompress both images as JPEG with various quality settings, then do a pixel-by-pixel comparison computing a difference measure between each of the two source images and its recompressed version. Presumably, the one with more JPEG artefacts to start with will be more similar to its compressed version, at a certain key level of compression. This relies on your compression program generating the same kind of artefacts as the one used to make the images, but I suppose that cjpeg with the default settings has a good chance of working.
Failing that, just take the larger (in bytes) of the two JPEG files...
Right because we all know that sensible coders get it right first time, and have every feature you'll ever want already implemented in version 1.0, and so never need to push out a new version of their program, and if for some unthinkable reason they do want to make a new release, the users positively enjoy watching the download creep through as slowly as possible...
BTW, have you seen the size of the package updates for your Linux distribution recently?
Fedora is already using binary diffs to speed up downloading updates - see yum-presto. With a better binary diff algorithm, the RPM updates can hopefully be made even smaller. As the Google developers note, making smaller update packages isn't just a 'nice to have' - it really makes a difference in getting vulnerabilities patched faster and cuts the bandwidth bill for the vendor and its mirror sites. Remembering my experiences downloading updates over a 56k modem, I am also strongly in favour of anything that makes updating faster for the user.
Think 'Corvette' and change the V to a soft J or zh sound.
Obviously, the #1 market for standalone GPS receivers is the OpenStreetMap mapping community, who wander around making GPS traces to create a free world map. I've found that for this job you want the most sensitive and accurate receiver possible, and a standalone unit from Garmin seems to give better quality data than the GPS sensor built into my BlackBerry, especially in city areas where not much of the sky is visible.
Why do you suppose that ASP.NET, Winforms and so on are 'the patent infringing parts'? Just because they are APIs made by Microsoft, they must be covered by enforceable software patents held by that company? Because of the word 'Microsoft'?
The Mono project has a commitment to remove code that is found to be a patent violation; I think there is no reason to suppose that Mono's Winforms or other Microsoft-compatible APIs are any more of a patent risk than running Samba or Firefox.
Well, you know, Mono is open source, all of it. Even the parts which are not covered by Microsoft's patent promise.
The Linux kernel is another piece of software which is not covered by Microsoft's patent promise. Indeed, in the USA Microsoft owns at least one software patent (the VFAT one) which applies to Linux, and is actively suing people for it. So by your argument Linux is not open source?
As far as I know the enforceable patents held by Microsoft, the ones which cover anything at all novel, are those for the runtime engine (the CLR). These are included in the patent promise. There is no reason to suppose that because Mono's Winforms implementation implements an API originally made by Microsoft, it is any more risky than Samba or the many other free reimplementations of proprietary APIs.
Not true, as far as I can see: the Java SE licence says 'Sun also grants you a... license... to create and/or distribute an Independent Implementation of the Specification...'. From my reading of the legalese it seems that any compliant Java implementation is covered.
But remember that not only Sun owns software patents which cover your Java program, and not only Microsoft owns swpats covering your .NET program. A legal risk assessment is not merely an evilness competition between Microsoft and Sun!
As others have pointed out, that's not migrating an existing app, that's rewriting it. As for 'unknown compatibility', not everything in .NET is implemented in Mono (WPF for example), but the libraries that are there work well. There is a migration analyser which will tell you if your app uses Windows-specific calls or APIs not yet supported by Mono. There is also the new project M/Invoke which can let .NET apps that call native Windows APIs run under Linux by replacing the P/Invoke call with a call to some managed code (which needs to be written, Wine-like).
Mono runs on Windows and Mac OS X too, so even if you are using something totally Mono-specific, you still have a cross-platform application. (Banshee and Tomboy have been ported to Windows without too much bother.) If you're talking of a pure C# library (for example, Mono.Addins) rather than a native binding, then it can easily be used with either runtime. Finally, you can use Winforms, ASP.NET and ADO.NET with Mono, which provides its own free implementation; you won't be covered by the patent promise in today's announcement, but you may not think that matters.
Nowadays there's a case to be argued that Mono is 'the' C# and CLR implementation which runs everywhere (Linux, Playstation 3, iPhone, Windows, etc) and can be easily adapted to your needs, while Microsoft's implementation is a reasonable alternative for people who are stuck on Windows. Kind of like how gcc is the standard C and C++ compiler, even though most Windows native programs are still built with proprietary compilers. This is overstating the case a bit - Mono isn't there yet, and new developments in the C# language still come out of Redmond - but Mono is certainly a strong enough competitor to stop C# being synonymous with Microsoft's implementation.
Hmm, you are right since SharpDevelop is a free app using Winforms, and so is Paint.NET. I was thinking of free Linux apps (that might also be ported to Windows one day) rather than free Windows apps (that might be ported to Linux). I meant to say that nobody would write *Linux* free applications using Winforms.
Are you sure? It has less noise made on Internet discussion forums about patents, that is certain. That doesn't mean the risk is less. Don't assume that only Sun holds patents relevant to Java, or that only Microsoft holds patents relevant to .NET.
It depends what you want to do. I assume you are developing on Linux? In that case you will probably want to use Linux native libraries with C# bindings, not the Winforms implementation shipped by Mono.
I think this is the big difference: in Java you tend to program in a 'pure Java' bubble where almost all the libraries you use are in Java. Mono/C# applications like Banshee link to a lot of native Linux libraries like GTK+ and GStreamer. Of course there is nothing to stop Java using native libraries too (see java-gnome) but so far, this hasn't caught on to the extent it has for Mono. Remember that Mono was originally created by Linux desktop programmers as an easier way to make GNOME applications, while Java's heritage is as the One True Platform for writing code that runs on any OS, and so needs a complete set of Java libraries.
Only if there are enforceable patents held by Microsoft which are specific to C# (the language) version 3. You see, C# 3 compiles to the same bytecode as C# 2, and runs on the same virtual machine. The MS patents that people worry about are on implementation techniques for the virtual machine. You use the same ECMA-specified virtual machine to run bytecode compiled from C# 2 and C# 3, so it's covered.
If there are (enforceable) software patents covering the language itself, specifically the new features in C# 3, then you have a point.
You're right, but the most common criticism of Mono before this announcement was that free software distributed with Linux carried a patent risk. The Winforms stuff is still a goal of the Mono project, but there is no reason for Linux distributions to install it. The non-ECMA parts of Mono are still very useful for companies migrating existing Windows legacy apps to Linux, but nobody would write a new free application with Winforms starting from scratch (GTK# is a lot better).
So the Windows.Forms and other Microsoft APIs move to a separate 'Mono-non-ECMA' package, which can be treated a bit like Wine: you wouldn't really want to install it by default or develop against it, but it can be invaluable if you have existing Windows software you want to run.
There are a few flaws with this argument. Firstly, if you want a GUI then Winforms is not the only choice. In fact, GTK# is a lot nicer, on Windows and Mac as well as on Linux, and all the free Mono apps such Banshee use GTK#, and C# bindings to other standard Linux libraries. They do not use ASP.NET, Winforms or other more Windowsy stuff.
Secondly, the software patents that Microsoft owns and which people are worried about are the ones on the .NET runtime engine itself (part of the ECMA standards). I'm not aware that they hold enforceable swpats for more pedestrian things like database bindings (though like every large company, they have a portfolio of crappy software patents for 'mutual assured destruction' purposes).
I think it's a good idea, though, to split the Mono distribution into the ECMA-standard part (which is now demonstrably safe from patent attacks by Microsoft, though sadly not from other software companies and patent trolls) and a more Microsoft-flavoured, free-reimplementation-of-proprietary-APIs part, which is more like Wine and other libraries used to port existing Windows apps to Linux. If you are worried that the classes for database access or Winforms GUI expose you to patent risk, don't install them - few free programs use them anyway. That should keep everyone happy.
According to a comment by Miguel on his blog,
Only if it's a filesystem-processor-intensive test, that is, you are making the filesystem work hard and (depending on how efficient it is) chew lots of CPU. Giving the filesystem easy work, while running something CPU-intensive like bzip2 separately, is a good benchmark for bzip2 but it doesn't tell you much about the fs.
You do want that, but I'm pretty sure that bzip2 isn't it. Compressing a file is actually pretty light work for the filesystem. You need to read some blocks sequentially, then write some blocks sequentially. Compressing lots of small files is better, but the access is still likely to be pretty one-at-a-time. More challenging would be a task that needs to read and write lots of files of varying size, across complex directory structures, with fairly random access patterns. A parallel kernel compile would be nearer the mark, though even that may not be demanding enough to make a really good benchmark.
The first benchmark on page 2 is 'Parallel BZIP2 Compression'. They are testing the speed of running bzip2, a CPU-intensive program, and drawing conclusions about the filesystem? Sure, there will be some time taken to read and write the large file from disk, but it is dwarfed by the computation time. They then say which filesystems are fastest, but 'these margins were small'. Well, not really surprising. Are the results statistically significant or was it just luck? (They mention running the tests several times, but don't give variance etc.)
All benchmarks are flawed, but I think these really could be improved. Surely a good filesystem benchmark is one that exercises the filesystem and the disk, but little else - unless you believe in the possibility of some magic side-effect whereby the processor is slowed down because you're using a different filesystem. (It's just about possible, e.g. if the filesystem gobbles lots of memory and causes your machine to thrash, but in the real world it's a waste of time running these things.)
On second thoughts I might be wrong - did you mean you used SORBS to help with greylisting? So a host from a block of IP addresses in SORBS could still send mail but with a few seconds' delay in the SMTP chatter? In that case you are preventing spam from being sent but without needing to drop any message, so my bad.
Wow, I am quite surprised that it's illegal to ask about drug use. Of course you have a right to privacy, and a right to refuse to answer any question you are asked - but surely, the employer equally has a right to choose who they employ. After all, nobody forces you to work there, and you are free to choose an employer more in tune with your personal beliefs. For some things, such as skin colour or religion, there are nasty scenarios where particular groups get disadvantaged, and we legislate to avoid that - but taking drugs or starting a family are personal choices.