It will not. The Chinese are well aware that wind and solar power are not going to produce liquid fuels required to run vehicle fleets, and are setting up oil barter agreements with just about every oil-producing country in Africa (usually in exchange for small arms, police gear and infrastructure projects). And just in case all that goes kaput, they are also building coal-to-gasoline conversion plants at breakneck pace.
Most mailers supporting encryption (including Outlook with PGP and Thunderbird with Enigmail) will automatically encrypt using the recipient's key and have no way of inferring whether the recipient address is correct.
So, in this case, I'm not sure how encryption would have helped at all.
Ghostscript ships with ps2pdf(1), which works in most cases for converting EPS and plain PS documents to PDF.
Ghostscript, however, is not a particularly good PDF renderer. The Poppler engine (which is used by kpdf, the official KDE PDF viewer) is much better. With kpdf:
Incremental searches are fast; search results are not listed, but hilit in the thumbnails.
Marquee copy-selects are possible.
The anti-aliasing on vector art and text is fine (but maybe not quite on par with the Apple or Adobe viewers).
I agree with your larger point, though. Apple puts far more usability spit-and-polish into their products than KDE or GNOME does, and it really shows more than any one particular technical feature.
There's compelling data suggesting otherwise (at least in children):
Children tend to snack on nutritionally-unbalanced food when watching television, eat unconsciously and eat enough to skewtheir daily caloric intake.
For some reason, children watching television burn fewer calories than they would at just about any other physical activity, including just idly sitting or lying down.
Children who were forced to watch less television lost weight.
I thought I'd talk about the next 50 years of computer security, partly
because people say getting the next 50 years right is the hardest bit.
So, if I get it wrong, I've got an excuse.
If we're going to talk about security, we need to talk about the threat.
What is the biggest threat out there? Well, as far as we can tell--as
far as I can tell, at least--in the longer term, the nightmare security
risk is the employee, or the person in general using the computer
system. They're really inconvenient things:
You can't formally verify people; it just doesn't work.
They operate inside of your security system, in most cases so they can
actually do their job.
They work for you. And worse than that, they mean well. If they were
malicious, you could get rid of them. If they mean well, they're
harder to deal with.
So a lot of security in the future has to be around stopping people who
mean well doing things they shouldn't.
We'll start with the easy stuff. There's been a lot going on recently
in terms of programming tools for verification. It's not new science:
the mathematics, the ideas behind these are 30 years old. What's
happened is that people have built useable tools based on these ideas.
As computer systems get faster, they get more and more able to make use
of these tools. Some of these are even now getting into the compiler.
The newest version of gcc can do things like certain kinds of buffer
overflow checks, the memory handling functions--strlen, strcpy and
stuff--can spot running over the end of the stack. At Red Hat we
compiled a very large number of applications just with these basic
checks. And then we tried to run them. The results were not brilliant.
The bugs were always out there--they just weren't being found. Some of
this code should have been hand-inspected again and again and again.
Language tools are another one: it's something Sun in particular took up
with Java--trying to build language systems where you can't have things
like buffer overflows, where your locking model is based around making
it schemes where it's hard to forget to do things like release locks. So
a lot of your synchronization is implicit, or you just say "this is
synchronized with the other" and don't handle locks directly.
With a lot of design improvements, people are starting to think much
more about modularity in software. To improve code security, we need to
think a lot more about modularity, dividing things into logical
sections.
The final thing that which has come with this is mathematical models--which
is the bit I really hate, because I don't like mathematics. You can do
really detailed, full-on mathematical models of computer systems. We're
at the point that you can build a mathematically provably-secure system.
What we don't know how to do is build one which is usable. You also
have to remember is that a mathematically-secure system is not
necessarily correct. There's a real difference between being correct
and secure. A secure system won't break its security properties, but it
might do completely wrong things.
We're starting to think more about defence: we're seeing better hardware
defence. Desktop PCs today have finally discovered non-executable
stacks, something I think the mainframe people discovered in the late
1950s. We're learning from the virus world, and the real world. If we
have randomization systems--which we're just starting to do a little bit
of--if we randomize the way your memory is laid out, you randomize
the way your machine behaves, then it's much much harder to write an
exploit because it might work on one machine, but it won't work on
another--or it could work on some fraction of machines in an office.
What we have so far is fairly primitive: moving memory around,
rearranging memory layouts. There's a lot of scope to do this--probably
not within the Unix model, because the Unix model defines some things so
rigidly.
It's a common misconception that a complete open source consumer desktop is all that's needed for businesses to ditch all their current proprietary software. The enterprise, on the other hand, really needs easy-to-use tools for managing large networks of users, printers, computers.
One major problem is a lack of a directory service on par with Microsoft's Active Directory--a directory service that's seamlessly integrated into just about everything: authentication & public key management, printing, desktop settings, package management, filesystem access control and contact lists in IM and e-mail. (Novell's eDirectory is a proprietary product, and does not count as open source.) Right now, there are many individual components--OpenLDAP, PAM, NFS4, POSIX ACLs, GConf and Evolution--which are more or less complete in themselves, but are poorly-integrated with each other. Getting them to work in concert with the directory service as glue is fiddly, frustrating and in many cases, would involve substantial amounts of coding.
Also needed is groupware on par with Exchange Server (Novell's Groupwise does not count because it's not open source.) that can seamlessly integrate scheduling, contact management, backup and archival, search, IMAP/POP access, load-balancing & replication and server-side mail filtering. Again, there are a whole lot of individual open source components which have to be stitched tediously together to get anywhere near the same functionality.
gcj (the GNU Java compiler) allows Java programs and bytecode to be compiled into native code. It can even generate statically-linked executables which do not require a runtime. These executables tend to start up much more quickly.
Sun, on the other hand, does not allow anything of the sort with their own Java stack and has held off on open-sourcing because it sees its Java runtime environment as a beachhead through which it can colonize your system (especially on Windows, where it comes bundled with all sorts of seemingly-unrelated stuff, like browser toolbars). Allowing third parties to ship stand-alone executables would undermine this.
This is probably to the long-term detriment of the Java platform because the runtime environment is now large and unwieldy enough to really complicate app deployment.
I believe Sun intentionally obfuscates the issue by pointing out that native code is not portable, is somewhat more fragile (because it is not insulated from system dependencies by a VM) and does not necessarily perform better than bytecode in a VM with an aggressive JIT. All these are true, but is besides the point.
The VMWare Player is locked to a particular disk image. You will need to buy the full product to make your own players or to run your choice of software.
What you can use, though, is QEMU (in the Debian "qemu" package), an LGPLed emulator. It's also quite straightforward to use:
gksudo qemu -boot c -hda/dev/hda -m 128
This will boot a 128MB virtual machine from your first IDE disk, map its video display mapped to a window and bring up a NAT firewall for outgoing network connections.
If you're booting into Windows, keep in mind that the Windows plug-and-play agent will kick in at boot time, take a long time to finish working and may require several further reboots because the simulated hardware in the virtual machine is quite different to the physical hardware in the host system. If you don't want the virtual machine to make any changes to your Windows installation, add the "-snapshot" option to redirect writes to a temporary file.
QEMU 0.8.0 is nowhere as fast as VMWare, but appears to be robust enough to install and run Windows XP without problems.
In practice, this is not a great help because gij and gcj are so slow. You may be able to get much better results compiling directly from Java source to machine code, and then prelinking the resulting executables and shared objects to reduce startup time.
I don't think there's any irony here, because Gates was being sarcastic. The letter itself was bitter complaint about the majority of Altair users not paying for copies of BASIC and hence "stealing" the development effort he had put into writing it.
At the time, this was rather novel concept. The mainframe and minicomputer vendors of the era basically sold hardware, the cost of which far dwarfed that of hiring programmers to write the operating system and application software they ran. Thus, turnkey solutions were not common; institutions like universities, banks and government agencies simply hired large computer departments to support their software.
When cheap, mass-produced microprocessor-based computers appeared, a sort of upside-down market appeared. The unit cost of each computer was low enough for hobbyists to buy a computer each; each hobbyist could be separately sold software as one would boxed goods to recoup any up-front development costs.
As with selling other kinds of consumer goods, selling software like this can be very marketing intensive: so much so that today, in this age of web-based services, the shrink-wrapped cardboard box frames the wider public's perception of what software is. It's interesting to see that many newly-arrived computer graduates, having used consumer hardware all their lives, are sometimes shocked (or even offended) to see tangles of homebrew, site-specific stuff running behind the scenes in the enterprise. Surprisingly, many managers also hold similar views and believe complicated systems can always be snapped together easily (a la Lego) from off-the-shelf boxed products.
That letter was Gates on the cusp of realizing that he had a viable future business model. It looks like he really went on to change the world—whether for better or for worse, I don't really know.
For example, many of Red Hat's larger customers have service contracts where they pay for 1 and 2. People who buy their shrink-wrapped product pay for a bit of 3.
Here's a semi-realistic example: suppose I have an intrusion detection system, and I'm logging packets into a table. I now want a tally of inbound traffic by source address and protocol, but want to ignore loopback and any source addresses from which I get fewer than 10 packets.
SELECT
INET_NTOA(src), prot, SUM(len) FROM packets
WHERE
src INET_ATON('127.0.0.1')
GROUP BY
src, prot
HAVING
COUNT(*) >= 10;
There's no natural way to express aggregates. To do what GROUP BY does, one has to nest all-solutions predicates like bagof/3 and setof/3.
There's no syntax for named fields.
The query is no longer concise and not easy to understand.
This just covers SELECT queries. Transactional INSERT and UPDATE queries would be more complicated, because of the way backtracking works in Prolog.
In short, I think Prolog is too general a language to be useful for queries on relational data. One really needs purpose-designed syntax to accommondate common queries.
I'm a LAMP programmer, and I think it's a reasonably good platform for web applications. I'd like it to succeed because I really want free software, both as a movement and technical solution, to flourish.
But I really worry that Microsoft has opened a large lead here with.NET, at least in the medium term. Most people have simply compared C# and the.NET framework classes against Java and base their assessment of.NET as a platform on that. But I think it misses the point somewhat.
The Bourne shell is powerful because it allows entire programs--even ones not specifically designed to work together--to be connected together: the utility of the system as a whole increases dramatically because of this network effect. With.NET, it's the same, except with classes and objects across languages previously incommunicado.
On Unix, every scripting language, by contrast, is pretty much an island by itself.
If you need a binding for say, MySQL, you'd have to implement it for Python, Ruby, Perl, Tcl and whatnot. Although tools like SWIG try to automate this, in general, every new binding (N x M of them) is written from scratch. One might argue that doing it this way makes the binding conform best to the spirit of each scripting language, but in practice bindings for important libraries are often buggy and incomplete, perhaps because the cumulative effort is too great or too much language-specific expertise is needed. This is especially true for complex GUI toolkits like Gtk or Qt, which cause headaches with complicated data structures..NET bindings, on the other hand, are only necessary if they're for unmanaged code; even then, they need only be written once.
Re-using code from different scripting languages is very difficult. Suppose if, for example, a PHP programmer doing screen-scraping is fed up with the PHP/Curl bindings and wants to use Perl's excellent LWP::UserAgent module. Or, say, someone writing a Ruby shopping cart would like to borrow one of the payment library bindings in PHP? How is that possible? Wrapping the functionality into a stand-alone program (and hence using the shell and IPC as glue) is often so much of a hassle that people simply don't bother and end up re-implementing it from scratch. In.NET, this is almost trivial.
Every scripting language has to implement its own interpreter/virtual machine/compiler. Making a thread-safe and efficient one is not easy; making a JIT fast enough to even come near the efficiency of native C/C++ involves a great deal of messy, architecture-specific work. The CLR, by contrast, is common to all.NET languages and any performance enhancement to it is inherited by all. It's well-tuned enough that, for example, PHP.NET actually runs faster than the native PHP interpreter, even with the Zend accellerator product.
Packaging, deployment and building are different in each language. This can be a major problem when trying to glue scripts written in different languages together into the same project or getting the mess to install on the target system. Suppose it was an application which needs Perl 5.8 for one component, PHP 4.3.x (with mcrypt an GMP support enabled) for another and Python 2.3 (with PostgreSQL or MySQL bindings present) for others? How does one deploy this if the target system does not have one or more of these installed? Is there a simple way to put such an application in a test harness or even build it without resorting to a hodgepodge of install.py, MakeMaker and PHPAR? On the other hand, the only prerequisite for.NET applications need be the.NET runtime itself. Everything is compiled into the same common executable bytecode, so no additional interpreters are needed. Any assemblies the application depends on can be safely bundled with it even if the target system already has different versions of those assemblies installed.
I believe, after putting seeing all of these advantages put together, that Miguel de Icaza was right and that we cannot afford to dismiss.NET as merely a Java work-alike.
Has anyone noticed that the author of the article is from Sleepycat (which sells commercial licenses for Berkeley DB to embedded systems developers)?
She puts forth a case against SQL and relational databases in general and claims that many applications (like directory services and search engines) have read-heavy, hierarchial access patterns which favour lighter-weight, non-relational, transaction-optional databases.
And.. it just so happens that Sleepycat's flagship products are Berkeley DB (a flat-file database) and DBXML (an XQuery engine built on top of that).
You'll have to provide the reliable node yourself.
"Trackerless" is probably a misnomer. "Self-tracker" or "embedded tracker" might be more accurate, given what this new scheme does.
So, this is not anonymous file sharing. That would require a solution to the naming problem, which would probably necessitate extensions to TCP/IP itself.
When creating a trackerless torrent file, you still have to embed in it the IP address of at least one "reliable node". In other words, at least one BitTorrent client must remain in the swarm at all times to seed others with addresses of their peers.
The intent is not to make anonymous file-sharing any easier, but to allow that torrent's swarm to scale more easily in absence of sufficient bandwidth to run a real tracker.
It's ironic that this is coming from a company that, for many years, kept the (encrypted) file format of Postscript Type 1 fonts a closely-guarded secret.
It took a combined threat from Bitstream (who successfully reverse-engineered the format), Apple and Microsoft (who teamed up to produce a serious alternative, TrueType) to force Adobe to open the file format to the public.
So I guess the same would apply here--either reverse-engineer the Nikon format (a legal course of action in the US, UK and Australia), refuse to buy their products or design and popularize with an superior alternative file format.
The original quote:
Best case
Salary from America, house in England, Japanese wife, Chinese food.
Pretty good case
Salary from England, house in America, Chinese wife, Japanese food.
Worst case
Salary from China, house in Japan, British wife, American food.
--Bungei Shunju magazine
The Internet Archive (which would be its counterpart in the US) was recently granted a similar exemption from the DMCA for the archival of vintage software.
jpegoptim is an open-source utility which already does this.
The JPEG algorithm breaks up the image into chunks of 8x8 pixels, takes the DCT coefficients of those chunks, then packs them into a Huffman-encoded stream.
If you can repack an existing JPEG file with a better Huffman code, then you can shrink the file without any loss of image data, while still remaining fully compatible.
jpegoptim usually can't further shrink JPEG files produced by the GIMP and Photoshop (which have their own optimized JPEG routines). It seems to do a lot better, though, on JPEG files coming out of digital cameras (gains of 30% - 50% are pretty common).
Slashdot Mirror
It will not. The Chinese are well aware that wind and solar power are not going to produce liquid fuels required to run vehicle fleets, and are setting up oil barter agreements with just about every oil-producing country in Africa (usually in exchange for small arms, police gear and infrastructure projects). And just in case all that goes kaput, they are also building coal-to-gasoline conversion plants at breakneck pace.
So, in this case, I'm not sure how encryption would have helped at all.
How would encryption have helped? The staffer in question did not have her mail intercepted, but mistakenly sent mail to the Times reporter.
Installing from an apt suppository enables the --purge switch. *ducks*
- Ghostscript ships with ps2pdf(1), which works in most cases for converting EPS and plain PS documents to PDF.
Ghostscript, however, is not a particularly good PDF renderer. The Poppler engine (which is used by kpdf, the official KDE PDF viewer) is much better. With kpdf:I agree with your larger point, though. Apple puts far more usability spit-and-polish into their products than KDE or GNOME does, and it really shows more than any one particular technical feature.
It's a common misconception that a complete open source consumer desktop is all that's needed for businesses to ditch all their current proprietary software. The enterprise, on the other hand, really needs easy-to-use tools for managing large networks of users, printers, computers.
One major problem is a lack of a directory service on par with Microsoft's Active Directory--a directory service that's seamlessly integrated into just about everything: authentication & public key management, printing, desktop settings, package management, filesystem access control and contact lists in IM and e-mail. (Novell's eDirectory is a proprietary product, and does not count as open source.) Right now, there are many individual components--OpenLDAP, PAM, NFS4, POSIX ACLs, GConf and Evolution--which are more or less complete in themselves, but are poorly-integrated with each other. Getting them to work in concert with the directory service as glue is fiddly, frustrating and in many cases, would involve substantial amounts of coding.
Also needed is groupware on par with Exchange Server (Novell's Groupwise does not count because it's not open source.) that can seamlessly integrate scheduling, contact management, backup and archival, search, IMAP/POP access, load-balancing & replication and server-side mail filtering. Again, there are a whole lot of individual open source components which have to be stitched tediously together to get anywhere near the same functionality.
gcj (the GNU Java compiler) allows Java programs and bytecode to be compiled into native code. It can even generate statically-linked executables which do not require a runtime. These executables tend to start up much more quickly.
Sun, on the other hand, does not allow anything of the sort with their own Java stack and has held off on open-sourcing because it sees its Java runtime environment as a beachhead through which it can colonize your system (especially on Windows, where it comes bundled with all sorts of seemingly-unrelated stuff, like browser toolbars). Allowing third parties to ship stand-alone executables would undermine this.
This is probably to the long-term detriment of the Java platform because the runtime environment is now large and unwieldy enough to really complicate app deployment.
I believe Sun intentionally obfuscates the issue by pointing out that native code is not portable, is somewhat more fragile (because it is not insulated from system dependencies by a VM) and does not necessarily perform better than bytecode in a VM with an aggressive JIT. All these are true, but is besides the point.
What you can use, though, is QEMU (in the Debian "qemu" package), an LGPLed emulator. It's also quite straightforward to use:
This will boot a 128MB virtual machine from your first IDE disk, map its video display mapped to a window and bring up a NAT firewall for outgoing network connections.
If you're booting into Windows, keep in mind that the Windows plug-and-play agent will kick in at boot time, take a long time to finish working and may require several further reboots because the simulated hardware in the virtual machine is quite different to the physical hardware in the host system. If you don't want the virtual machine to make any changes to your Windows installation, add the "-snapshot" option to redirect writes to a temporary file.
QEMU 0.8.0 is nowhere as fast as VMWare, but appears to be robust enough to install and run Windows XP without problems.
If literacy rates seem to be falling, as the Wired commentary notes, it's likely because:
All these makes illiteracy, which has always been present in American society, much more conspicuous and difficult to hide.
GCC 4.1 has not been released yet.
A modified version of Classpath has been included with GCJ since 3.2.
Azureus may start in GIJ 4.0, but won't work properly because it relies on parts of the Sun JDK which aren't completely implemented yet in GCJ.
The caching JIT has been available since 3.4, but is disabled by default. To turn it on, you'll need to add these switches to your gij command line:
-Dgnu.gcj.jit.compiler=/usr/bin/gcj -Dgnu.gcj.jit.cachedir=/tmp -Dgnu.gcj.jit.options=-O2
In practice, this is not a great help because gij and gcj are so slow. You may be able to get much better results compiling directly from Java source to machine code, and then prelinking the resulting executables and shared objects to reduce startup time.
I don't think there's any irony here, because Gates was being sarcastic. The letter itself was bitter complaint about the majority of Altair users not paying for copies of BASIC and hence "stealing" the development effort he had put into writing it.
At the time, this was rather novel concept. The mainframe and minicomputer vendors of the era basically sold hardware, the cost of which far dwarfed that of hiring programmers to write the operating system and application software they ran. Thus, turnkey solutions were not common; institutions like universities, banks and government agencies simply hired large computer departments to support their software.
When cheap, mass-produced microprocessor-based computers appeared, a sort of upside-down market appeared. The unit cost of each computer was low enough for hobbyists to buy a computer each; each hobbyist could be separately sold software as one would boxed goods to recoup any up-front development costs.
As with selling other kinds of consumer goods, selling software like this can be very marketing intensive: so much so that today, in this age of web-based services, the shrink-wrapped cardboard box frames the wider public's perception of what software is. It's interesting to see that many newly-arrived computer graduates, having used consumer hardware all their lives, are sometimes shocked (or even offended) to see tangles of homebrew, site-specific stuff running behind the scenes in the enterprise. Surprisingly, many managers also hold similar views and believe complicated systems can always be snapped together easily (a la Lego) from off-the-shelf boxed products.
That letter was Gates on the cusp of realizing that he had a viable future business model. It looks like he really went on to change the world—whether for better or for worse, I don't really know.
- Customization/enhancement work.
- Migration and deployment.
- User support.
For example, many of Red Hat's larger customers have service contracts where they pay for 1 and 2. People who buy their shrink-wrapped product pay for a bit of 3.This just covers SELECT queries. Transactional INSERT and UPDATE queries would be more complicated, because of the way backtracking works in Prolog.
In short, I think Prolog is too general a language to be useful for queries on relational data. One really needs purpose-designed syntax to accommondate common queries.
But I really worry that Microsoft has opened a large lead here with .NET, at least in the medium term. Most people have simply compared C# and the .NET framework classes against Java and base their assessment of .NET as a platform on that. But I think it misses the point somewhat.
The Bourne shell is powerful because it allows entire programs--even ones not specifically designed to work together--to be connected together: the utility of the system as a whole increases dramatically because of this network effect. With .NET, it's the same, except with classes and objects across languages previously incommunicado.
On Unix, every scripting language, by contrast, is pretty much an island by itself.
If you need a binding for say, MySQL, you'd have to implement it for Python, Ruby, Perl, Tcl and whatnot. Although tools like SWIG try to automate this, in general, every new binding (N x M of them) is written from scratch. One might argue that doing it this way makes the binding conform best to the spirit of each scripting language, but in practice bindings for important libraries are often buggy and incomplete, perhaps because the cumulative effort is too great or too much language-specific expertise is needed. This is especially true for complex GUI toolkits like Gtk or Qt, which cause headaches with complicated data structures. .NET bindings, on the other hand, are only necessary if they're for unmanaged code; even then, they need only be written once.
Re-using code from different scripting languages is very difficult. Suppose if, for example, a PHP programmer doing screen-scraping is fed up with the PHP/Curl bindings and wants to use Perl's excellent LWP::UserAgent module. Or, say, someone writing a Ruby shopping cart would like to borrow one of the payment library bindings in PHP? How is that possible? Wrapping the functionality into a stand-alone program (and hence using the shell and IPC as glue) is often so much of a hassle that people simply don't bother and end up re-implementing it from scratch. In .NET, this is almost trivial.
Every scripting language has to implement its own interpreter/virtual machine/compiler. Making a thread-safe and efficient one is not easy; making a JIT fast enough to even come near the efficiency of native C/C++ involves a great deal of messy, architecture-specific work. The CLR, by contrast, is common to all .NET languages and any performance enhancement to it is inherited by all. It's well-tuned enough that, for example, PHP.NET actually runs faster than the native PHP interpreter, even with the Zend accellerator product.
Packaging, deployment and building are different in each language. This can be a major problem when trying to glue scripts written in different languages together into the same project or getting the mess to install on the target system. Suppose it was an application which needs Perl 5.8 for one component, PHP 4.3.x (with mcrypt an GMP support enabled) for another and Python 2.3 (with PostgreSQL or MySQL bindings present) for others? How does one deploy this if the target system does not have one or more of these installed? Is there a simple way to put such an application in a test harness or even build it without resorting to a hodgepodge of install.py, MakeMaker and PHPAR? On the other hand, the only prerequisite for .NET applications need be the .NET runtime itself. Everything is compiled into the same common executable bytecode, so no additional interpreters are needed. Any assemblies the application depends on can be safely bundled with it even if the target system already has different versions of those assemblies installed.
I believe, after putting seeing all of these advantages put together, that Miguel de Icaza was right and that we cannot afford to dismiss .NET as merely a Java work-alike.
Word processor? Emacs.
E-mail? Emacs.
Browser? Emacs.
Spreadsheet? Emacs.
The transistor? Em...*ducks for cover*
Has anyone noticed that the author of the article is from Sleepycat (which sells commercial licenses for Berkeley DB to embedded systems developers)?
.. it just so happens that Sleepycat's flagship products are Berkeley DB (a flat-file database) and DBXML (an XQuery engine built on top of that).
She puts forth a case against SQL and relational databases in general and claims that many applications (like directory services and search engines) have read-heavy, hierarchial access patterns which favour lighter-weight, non-relational, transaction-optional databases.
And
You'll have to provide the reliable node yourself.
"Trackerless" is probably a misnomer. "Self-tracker" or "embedded tracker" might be more accurate, given what this new scheme does.
So, this is not anonymous file sharing. That would require a solution to the naming problem, which would probably necessitate extensions to TCP/IP itself.
When creating a trackerless torrent file, you still have to embed in it the IP address of at least one "reliable node". In other words, at least one BitTorrent client must remain in the swarm at all times to seed others with addresses of their peers.
The intent is not to make anonymous file-sharing any easier, but to allow that torrent's swarm to scale more easily in absence of sufficient bandwidth to run a real tracker.
It's ironic that this is coming from a company that, for many years, kept the (encrypted) file format of Postscript Type 1 fonts a closely-guarded secret.
It took a combined threat from Bitstream (who successfully reverse-engineered the format), Apple and Microsoft (who teamed up to produce a serious alternative, TrueType) to force Adobe to open the file format to the public.
So I guess the same would apply here--either reverse-engineer the Nikon format (a legal course of action in the US, UK and Australia), refuse to buy their products or design and popularize with an superior alternative file format.
The original quote: Best case Salary from America,
house in England,
Japanese wife,
Chinese food. Pretty good case Salary from England,
house in America,
Chinese wife,
Japanese food. Worst case Salary from China,
house in Japan,
British wife,
American food. --Bungei Shunju magazine
The Internet Archive (which would be its counterpart in the US) was recently granted a similar exemption from the DMCA for the archival of vintage software.
The JPEG algorithm breaks up the image into chunks of 8x8 pixels, takes the DCT coefficients of those chunks, then packs them into a Huffman-encoded stream.
If you can repack an existing JPEG file with a better Huffman code, then you can shrink the file without any loss of image data, while still remaining fully compatible.
jpegoptim usually can't further shrink JPEG files produced by the GIMP and Photoshop (which have their own optimized JPEG routines). It seems to do a lot better, though, on JPEG files coming out of digital cameras (gains of 30% - 50% are pretty common).