I don't have a URL, but was involved in several HPC procurements at the time (and knew some insiders at SGI and Cray). The poster is basically correct.
The sequence of events was:
SGI (at the time still called Silicon Graphics Inc) purchased Cray Research.
Well before the purchase, Cray had a hand in developing and marketing Suns larger machine, the "Super Dragon", sold by Sun as the 64SC, and referred to within by Cray as the 64CS -- I'm probably messing up the number, but I do recall the difference in the letter ordering.:-)
Prior to the purchase, Cray had completed the design for a
new shared memory system based on a high speed switch and single image OS.
Prior to the purchase SGI had already completed the design of the first NUMAflex systems, the Origin2000 and Onyx2.
So after the purchase, the new merged Cray/SGI had two large SMP/NUMA systems, the Origin line and the Cray developed line. Since they didn't need two, they sold the Cray design to Sun, where it was marketed as the E10000. They also called they NUMA fabric on the Origin2K "CrayLink" even though Cray had little or nothing to do with its design.
For a few years afterwards, there were a few within Cray CF (Chippewa Falls) that were somewhat bitter about SGI's decision to pawn off the E10000 design, pointing out repeatedly that Sun was selling plenty of E10000s...
If it matters, the HPC procurement I was involved in opted for the SGI, which was probably the correct decision. As unstable as the SGI hardware was, the sites I knew running E10000's for general HPC loads had far worse stability problems (though the E10K's undoubtedly better at running Oracle).
As far as the E10000 being NUMA or SMP -- depends on how you look at it. The Origin line used a bristled hypercube interconnect topology, so memory on the same node as a CPU was one hop thru the fabric, memory on another node connected to the same router was three hops, on a distant node might be multiple routre hops. The E10K (and I think the E15K) used a star topology where memory was ether on the same bus as the CPU or was on another bus that had to go through the switch. So the Sun has basically two levels of memory latency, whereas the SGI could have many levels. The SGI is definitely NUMA, the Sun is either SMP or "slightly NUMA", or however you want to parse it.
If you've never seen it, the tech papers on how the SGI NUMA systems work are worth reading. Build a fast 8-port crossbar chip (the "spyder chip"), then use it to glue CPUs, memory, and peripherals together. Keep a couple ports open, and you can glue the crossbars together in a fabric. Presto, you can now build a system with 200 CPUs or 100 PCI busses.
Pretty cool, even if it was expensive, proprietary, and all the rest.
Say the card supports some nifty feature, let's call it texture compression. It would be nifty because textures could be compressed by the CPU. Then when the GPU needed them, it could suck them across the video bus in compressed form, then uncompress them on the card. Doing so would definitely provide a performance boost (since it would allow more data to traverse the GPU bus in a given amount of time) but would also require that the driver implments texture compression since that operation has to happen on the CPU side.
OK so far, but what if NVidia licensed this texture compression alogrithm from a 3rd party that's unwilling to allow public release of their codec? There are two choices: 1) Ship a closed-source or partially closed-source driver or 2) ship an open source-driver that can't support texturing. If I were NVidia, trying to make a profit by providing the fastest graphics hardware, I'd pick option 1 in a heartbeat.
Now repeat the above problem a couple dozen times and you've got the picture. I don't expect to see a fully open-source driver for cutting edge graphics hardware from any vendor anytime soon.
Actually I did take a few physics classes -- in graduate school. I'd be happy to compare grades if you'd like to continue the name-calling.
Try opening google and searching for "motorcycle highside dynamics" then get back to me on that Harley's don't tip over thing. Oh, and I commute about 15,000 miles a year on a Buell, in the Bay Area, so I'm well versed on how exciting two wheel vehicles can get during evasive maneuvers (though I haven't gone rubber side up yet).
The Sparrow is, for all practical purposes, an enclosed motorcycle. You'd have to be a pretty big moron to purchase something that registers like a motorcycle, is the same size as a motorcycle, and weighs about the same as a (touring) motorcycle, and then expect it to behave like a Volvo. While I agree with you that it won't prevent some moron from trying a lawsuit, it's a long way from saying that the company is going to be finanically ruined after the first fatal crash.
It probably was a Limbaugh quote, since the statement is incorrect.
Type "idaho falls nrts accident" into google and choose the link of your choice to learn about the three people killed when the SL-1 reactor went critical. Last I checked, Ted's Olds has only killed one person. [Though based on the rumors of his alcohol consumption level, I'd wager that if he still owns the '67 Olds, he might yet be able to catch up....]
Yup, that's absolutely correct. They'll be sued into bankrupcy just like all those companies that tried to produe those insanely stupid two wheel vehicles. Honda, Harley-Davidson, Yamaha, Kawasaki, Schwinn, Trek, Huffy...........
that's because the other tools are PBS, Condor and LoadLever, all complete crap. Grid Engine is also crap, but at least doesn't have the 80s baggage.
What's funny about this is that the actual lineage of GridEngine is DQS-->Codine-->Codine/GRD-->GRD-->GridEngine . So grid engine is indeed carrying that "80's baggage". And for that matter, LoadLeveler is actually a decendant of Condor (though it branched off so long ago I doubt there is much of the orignal left). You also left out the half-dozen or so decendents of NQS that all carry the same baggage. Actually, if I had to choose, I'd say Condor has the least baggage, mainly because it's been targeted for something rather different than what most batch schedulers do (in particular, the classad stuff is an interesting direction).
Personally, I found PBS to be the best open source solution last time I had to choose, but that was just prior to the Sun buyout of GRD, so things may have changed. [My current employer rolls their own batch scheduler, so I haven't had a need to survey the field for a few years.]
There are also some things
Condor rocks at (cycle scavanging, userspace checkpoint/restart/migration) which none of the others even attempt,
so it's definitely worth a look for some sites.
If your paying $$ for your batch scheduler, LSF pretty much trumps all of them, but the price is too steep for me.
What's the value of backwards compatibility for XBox2 if there are few XBox1 games worth playing? [Keeping in mind
that maintaining backwards compatibility could add significantly to the price of an XBox2 since it is designed around a different CPU and GPU
I own a PS2 and have never used the backwards compatibility features. Since I did not own a PSOne prior to the PS2, I do not have a large library of PS1 games lying around. Though I've occasionally thought of picking up one of the bargain bin PS1 games, I've never done so -- There are plenty of good PS2 games I haven't played, not to mention that I'd also need to pick up a PS1 mem card in order to play the older games.
I'm sure that there are people who had large libraries of PS1 games that they didn't part with, but does this really apply to XBox? The PS1 had a longer, more popular run than the XBox will have had. There are plenty of "classic" PS1 games worth owning (Final Fantasy series, Metal Gear Solid, Resident Evil), how many XBox Games fall into that category?
RAID 0 is striping. No redundancy, which you won't be happy with. (One failure means losing the array.
RAID 1 is mirroring. With two drives, you still only have the size of one.
RAID 50 is nice where it does striping across redundant arrays. You lose size, but gain speed.
Most other RAID types aren't very popular for various reasons.
Acutally, the other RAID types are quite poplular, but not in low-end applications like the one being discussed.
RAID 3 is used extensively in sitiations where high-bandwith, large accesses are required (eg video streaming, sequential access of large datasets). RAID 3 and 5 differ in how the parity is stored, in 3 there is a dedicated parity drive, in 5 the parity is "distributed"
to each disk in the raid set. One benifit of RAID 3 is that
a single disk failure has little impact on performance compared to RAID 5.
IIRC, RAID 4 is used by NetApp appliances for reasons I don't remember.
RAID 5 tends to be used for things like databases as it handles smaller random accesses somewhat more gracefully than RAID 3 (though either can be tuned for better performance by twiddling cacheing and stripe sizes).
Part of my job is optimizing RAID arrays for "big data" viz -- we currently have around 30TB of fibre channel raid systems in use as scratch space, mostly RAID 3 but a couple RAID 5. Either can do the job, but there are trade-offs. [Actually we then RAID 0 the above luns into logical volumes for XFS filesystems, so we can usually sustain read rates upwards of 600MB/sec.] Beats being unemployed.:-)
But the problem is not just lack of ISA optimization, it also has to do with front-end language optimization.
As I mentioned in my post, KCC "compiles" C++ by converting it to C that gets fed into gcc, and yet produces executables that can have markedly better performance than g++..All the G5 optimizations in the world are not going to fix g++'s problems -- your looking at the wrong end of the horse.
One of the major problems is g++, not gcc. The KCC C++ compiler actually generated C code that was fed into the system's normal C compiler. When running on linux, this meant KCC was using gcc under the hood. Yet code compiled by KCC was often orders of magnitude faster than the same code compiled by g++. This was particularly true for STL heavy code.
G++ does an admirable job of being faithful to the C++ standards, but in the performance arena it gets owned. Other compilers (IRIX C++, MS C++, and ICC) produce much faster code.
As far as benchmarking goes, comparing g++ performance to anything is useless. Get a better compiler first, then benchmark.
As far as MacOS goes -- hope that the IBM compilers eventually become the defaults, or that the g++ maintainers eventually admit that their optimization blows and then fix things. The former is probably more likely than the latter.
For example, OS X by default installs some 20 languages for everything, including tutorials and help files. Removing these afforded me 10 gig of space.
I call bs.
My current OS X 10.3 install, plus some additional apps, plus some source tarballs of projects, plus the Xcode enviroment, plus an archive copy of 10.2, is using 10.61 GB of space. The lproj files are not very large.
While it is true that you can save space by not installing
all the language support, it isn't 10GB of space. Languages
can selected/deselected during the initial install.
The poster is correct though, that the granularity of control
over install is much rougher than with Gentoo or Debian.
Given the target audiences, this shouldn't be surprising.
Mac has tried breaking into the PC gamining scene for decades. They even had that "bigass game thats only available on that platform" called "Marathon."
After which, Marathon's developers worked on an even better FPS for the Mac-- a game called "Halo". Oops, sounds like there are at least two flaws in the "people flocking to Linux for the games" plan.
Yes they are blackdown's ports of the Sun JDK in deb packaging.
Which means that they are closed/evil/etc, but they are free (as in beer) enough to apt-get in without a hassle. Personally, I prefer C++, but if the job requires java, there is a way to get it under debian without resorting to alien, waiting for Sun to open source them, or (gasp) using another Linux distro.
cat "deb ftp://ftp.tux.org/pub/java/debian side main non-free"\ >>/etc/apt/source.list
apt-get install j2sdk1.4
Yes, it's non-free/evil/etc. For those of us that like debian and need java, it gets the job done. [Please note use of "like" vs "need" in the above sentence. One implies a preference, the other implies a (temporary) work necessity.]
After that, debian gets much better -- my laptop has gone through three major debian releases (potato, woody, and now sid) using nothing more that apt-get commands. [Actually, I guess I'm not really qualified to comment on the debian install process since I haven't really installed it in the last three years -- I just keep updating the existing install.]
At the time I did the initial install of potato, the installer dumped you into dselect, which is confusing if you've never seen it before. It may be better now, but even if it isn't, you can always apt-get anything you forgot. And building your own kernel is a snap (get the sources from kernel.org, make xconfig to select what you want, make-kpkg clean, make-kpkg kerne_image modules_image, then dpkg -i to install your shiny new kernel.
I've also had good luck using alien to translate rpm->deb for the occasional time when I needed some software that wasn't available as a deb. YMMV. In a related vein, I've had good luck with the blackdown java debs (debian doesn't provide Java due to conflicts with Sun's license terms).
Overall, I've had fewer problems with Debian than I have with Red Hat (which I maintain for my employer) and Mandrake (which was my personal distro of choice before Debian). In particular, I find maintenance and bug-fixes much much easier
(just run apt-get update, apt-get upgrade) and everything ``just works''.
Last time I checked, XFree86 does not support DRI to the second video card, so OpenGL apps only worked on the monitor driven by the primary graphics card. Xinerama only takes care of the X11 drawing, not the GLX DRI rendering.
Of course if you only have a single graphics card, this is no big deal. But if you want to build your own mini powerwall by adding a few PCI graphics cards, you need something like chromium if you plan to render openGL across more than a single GPU.
Since AppleScript has been part of MacOS since around '94, I don't think Ruby would have been a contender. Considering how differnent the underlying OS was from Unix at that time, I'd find it surprising if scripting languages like Python or Perl fit into MacOS 7 very well (surprising, but not impossible).
The first time I saw Tcl was in the Alpha editor under MacOS 7, so it was available there. Wether or not Tcl would have been a good choice for a system-wide scripting language is another arguement.
Note that there are now AppleScript libraries for
Python, and
Perl has Mac::AppleScript and Mac::Glue modules, among others, so it's fairly easy to trigger AppleScript events from something other than applescript. In fact with the PerlObjCBridge it's possible to make
Perl the data model for an objective-C gui.
Re:Encryption ain't it all tapped out to be...
on
Feds Want to Tap VoIP
·
· Score: 5, Interesting
Wow, you should really take off the tinfoil hat and read up on cryptography a little before your next post.
The secrecy of a cypher should rely entirely in the key (see D. A. Kerckhoffs). Put another way, knowing the algorithm used should not compromise a good cypher. In fact, most of the better, more trusted cyphers are published, and have been subjected to many many man-years of cryptanalysis without yielding attacks that do much better than brute force key searches (which is why we trust them and conversely why propriatary/homebrew/secret algorithms are shunned).
In the case of blowfish, to my knowledge there are no known attacks that are effective against the full 16-round cypher. There are weak keys, but it's unlikely that such keys are exploitable in practice. So it would seem unlikely (though not impossible) that blowfish has been successfully attacked by NSA. So given a large enough keyspace, the NSA would have to be willing to dedicate a large number of CPUs/FPGAs to a brute force attack. Since blowfish supports keylenghts up to 448bits, such attacks could take a while even with NSA's extensive resources. [In this context, "a while" means effectively never.]
Yes, if they are claiming, and can prove, that DirectCD infringes, then it's likely that UDF also infringes. If UDF infringes, a lot of the packet-writing DVD software is affected (but probably not batch-oriented writers like cdrecord). Unfortunately that's still a major PITA since it means doing the ``build tree, make isofs, burn isofs'' sequence rather than quicker UDF on-the-fly burning.
Slashdot Mirror
- SGI (at the time still called Silicon Graphics Inc) purchased Cray Research.
- Well before the purchase, Cray had a hand in developing and marketing Suns larger machine, the "Super Dragon", sold by Sun as the 64SC, and referred to within by Cray as the 64CS -- I'm probably messing up the number, but I do recall the difference in the letter ordering.
:-)
- Prior to the purchase, Cray had completed the design for a
new shared memory system based on a high speed switch and single image OS.
- Prior to the purchase SGI had already completed the design of the first NUMAflex systems, the Origin2000 and Onyx2.
- So after the purchase, the new merged Cray/SGI had two large SMP/NUMA systems, the Origin line and the Cray developed line. Since they didn't need two, they sold the Cray design to Sun, where it was marketed as the E10000. They also called they NUMA fabric on the Origin2K "CrayLink" even though Cray had little or nothing to do with its design.
- For a few years afterwards, there were a few within Cray CF (Chippewa Falls) that were somewhat bitter about SGI's decision to pawn off the E10000 design, pointing out repeatedly that Sun was selling plenty of E10000s...
If it matters, the HPC procurement I was involved in opted for the SGI, which was probably the correct decision. As unstable as the SGI hardware was, the sites I knew running E10000's for general HPC loads had far worse stability problems (though the E10K's undoubtedly better at running Oracle).As far as the E10000 being NUMA or SMP -- depends on how you look at it. The Origin line used a bristled hypercube interconnect topology, so memory on the same node as a CPU was one hop thru the fabric, memory on another node connected to the same router was three hops, on a distant node might be multiple routre hops. The E10K (and I think the E15K) used a star topology where memory was ether on the same bus as the CPU or was on another bus that had to go through the switch. So the Sun has basically two levels of memory latency, whereas the SGI could have many levels. The SGI is definitely NUMA, the Sun is either SMP or "slightly NUMA", or however you want to parse it.
If you've never seen it, the tech papers on how the SGI NUMA systems work are worth reading. Build a fast 8-port crossbar chip (the "spyder chip"), then use it to glue CPUs, memory, and peripherals together. Keep a couple ports open, and you can glue the crossbars together in a fabric. Presto, you can now build a system with 200 CPUs or 100 PCI busses. Pretty cool, even if it was expensive, proprietary, and all the rest.
How about an example:
Say the card supports some nifty feature, let's call it texture compression. It would be nifty because textures could be compressed by the CPU. Then when the GPU needed them, it could suck them across the video bus in compressed form, then uncompress them on the card. Doing so would definitely provide a performance boost (since it would allow more data to traverse the GPU bus in a given amount of time) but would also require that the driver implments texture compression since that operation has to happen on the CPU side.
OK so far, but what if NVidia licensed this texture compression alogrithm from a 3rd party that's unwilling to allow public release of their codec? There are two choices: 1) Ship a closed-source or partially closed-source driver or 2) ship an open source-driver that can't support texturing. If I were NVidia, trying to make a profit by providing the fastest graphics hardware, I'd pick option 1 in a heartbeat.
Now repeat the above problem a couple dozen times and you've got the picture. I don't expect to see a fully open-source driver for cutting edge graphics hardware from any vendor anytime soon.
Try opening google and searching for "motorcycle highside dynamics" then get back to me on that Harley's don't tip over thing. Oh, and I commute about 15,000 miles a year on a Buell, in the Bay Area, so I'm well versed on how exciting two wheel vehicles can get during evasive maneuvers (though I haven't gone rubber side up yet).
The Sparrow is, for all practical purposes, an enclosed motorcycle. You'd have to be a pretty big moron to purchase something that registers like a motorcycle, is the same size as a motorcycle, and weighs about the same as a (touring) motorcycle, and then expect it to behave like a Volvo. While I agree with you that it won't prevent some moron from trying a lawsuit, it's a long way from saying that the company is going to be finanically ruined after the first fatal crash.
Type "idaho falls nrts accident" into google and choose the link of your choice to learn about the three people killed when the SL-1 reactor went critical. Last I checked, Ted's Olds has only killed one person. [Though based on the rumors of his alcohol consumption level, I'd wager that if he still owns the '67 Olds, he might yet be able to catch up....]
Yup, that's absolutely correct. They'll be sued into bankrupcy just like all those companies that tried to produe those insanely stupid two wheel vehicles. Honda, Harley-Davidson, Yamaha, Kawasaki, Schwinn, Trek, Huffy...........
Personally, I found PBS to be the best open source solution last time I had to choose, but that was just prior to the Sun buyout of GRD, so things may have changed. [My current employer rolls their own batch scheduler, so I haven't had a need to survey the field for a few years.] There are also some things Condor rocks at (cycle scavanging, userspace checkpoint/restart/migration) which none of the others even attempt, so it's definitely worth a look for some sites.
If your paying $$ for your batch scheduler, LSF pretty much trumps all of them, but the price is too steep for me.
I don't think you can compare:
What's the value of backwards compatibility for XBox2 if there are few XBox1 games worth playing? [Keeping in mind that maintaining backwards compatibility could add significantly to the price of an XBox2 since it is designed around a different CPU and GPU
OK, I'll bite.
I own a PS2 and have never used the backwards compatibility features. Since I did not own a PSOne prior to the PS2, I do not have a large library of PS1 games lying around. Though I've occasionally thought of picking up one of the bargain bin PS1 games, I've never done so -- There are plenty of good PS2 games I haven't played, not to mention that I'd also need to pick up a PS1 mem card in order to play the older games.
I'm sure that there are people who had large libraries of PS1 games that they didn't part with, but does this really apply to XBox? The PS1 had a longer, more popular run than the XBox will have had. There are plenty of "classic" PS1 games worth owning (Final Fantasy series, Metal Gear Solid, Resident Evil), how many XBox Games fall into that category?
RAID 3 is used extensively in sitiations where high-bandwith, large accesses are required (eg video streaming, sequential access of large datasets). RAID 3 and 5 differ in how the parity is stored, in 3 there is a dedicated parity drive, in 5 the parity is "distributed" to each disk in the raid set. One benifit of RAID 3 is that a single disk failure has little impact on performance compared to RAID 5.
IIRC, RAID 4 is used by NetApp appliances for reasons I don't remember.
RAID 5 tends to be used for things like databases as it handles smaller random accesses somewhat more gracefully than RAID 3 (though either can be tuned for better performance by twiddling cacheing and stripe sizes).
Part of my job is optimizing RAID arrays for "big data" viz -- we currently have around 30TB of fibre channel raid systems in use as scratch space, mostly RAID 3 but a couple RAID 5. Either can do the job, but there are trade-offs. [Actually we then RAID 0 the above luns into logical volumes for XFS filesystems, so we can usually sustain read rates upwards of 600MB/sec.] Beats being unemployed. :-)
But the problem is not just lack of ISA optimization, it also has to do with front-end language optimization.
.All the G5 optimizations in the world are not going to fix g++'s problems -- your looking at the wrong end of the horse.
As I mentioned in my post, KCC "compiles" C++ by converting it to C that gets fed into gcc, and yet produces executables that can have markedly better performance than g++.
One of the major problems is g++, not gcc. The KCC C++ compiler actually generated C code that was fed into the system's normal C compiler. When running on linux, this meant KCC was using gcc under the hood. Yet code compiled by KCC was often orders of magnitude faster than the same code compiled by g++. This was particularly true for STL heavy code.
G++ does an admirable job of being faithful to the C++ standards, but in the performance arena it gets owned. Other compilers (IRIX C++, MS C++, and ICC) produce much faster code.
As far as benchmarking goes, comparing g++ performance to anything is useless. Get a better compiler first, then benchmark.
As far as MacOS goes -- hope that the IBM compilers eventually become the defaults, or that the g++ maintainers eventually admit that their optimization blows and then fix things. The former is probably more likely than the latter.
My current OS X 10.3 install, plus some additional apps, plus some source tarballs of projects, plus the Xcode enviroment, plus an archive copy of 10.2, is using 10.61 GB of space. The lproj files are not very large. While it is true that you can save space by not installing all the language support, it isn't 10GB of space. Languages can selected/deselected during the initial install.
The poster is correct though, that the granularity of control over install is much rougher than with Gentoo or Debian. Given the target audiences, this shouldn't be surprising.
Apple has released a statment that the price change rumor is not true:
Apple Denies Report of Online Music Price Boost
After which, Marathon's developers worked on an even better FPS for the Mac-- a game called "Halo". Oops, sounds like there are at least two flaws in the "people flocking to Linux for the games" plan.
Yes they are blackdown's ports of the Sun JDK in deb packaging.
Which means that they are closed/evil/etc, but they are free (as in beer) enough to apt-get in without a hassle. Personally, I prefer C++, but if the job requires java, there is a way to get it under debian without resorting to alien, waiting for Sun to open source them, or (gasp) using another Linux distro.
oops, make that sid and sources. :-)
Yes, it's non-free/evil/etc. For those of us that like debian and need java, it gets the job done. [Please note use of "like" vs "need" in the above sentence. One implies a preference, the other implies a (temporary) work necessity.]
Advice? The first install is the worst. :-)
After that, debian gets much better -- my laptop has gone through three major debian releases (potato, woody, and now sid) using nothing more that apt-get commands. [Actually, I guess I'm not really qualified to comment on the debian install process since I haven't really installed it in the last three years -- I just keep updating the existing install.]
At the time I did the initial install of potato, the installer dumped you into dselect, which is confusing if you've never seen it before. It may be better now, but even if it isn't, you can always apt-get anything you forgot. And building your own kernel is a snap (get the sources from kernel.org, make xconfig to select what you want, make-kpkg clean, make-kpkg kerne_image modules_image, then dpkg -i to install your shiny new kernel.
I've also had good luck using alien to translate rpm->deb for the occasional time when I needed some software that wasn't available as a deb. YMMV. In a related vein, I've had good luck with the blackdown java debs (debian doesn't provide Java due to conflicts with Sun's license terms).
Overall, I've had fewer problems with Debian than I have with Red Hat (which I maintain for my employer) and Mandrake (which was my personal distro of choice before Debian). In particular, I find maintenance and bug-fixes much much easier (just run apt-get update, apt-get upgrade) and everything ``just works''.
Last time I checked, XFree86 does not support DRI to the second video card, so OpenGL apps only worked on the monitor driven by the primary graphics card. Xinerama only takes care of the X11 drawing, not the GLX DRI rendering.
Of course if you only have a single graphics card, this is no big deal. But if you want to build your own mini powerwall by adding a few PCI graphics cards, you need something like chromium if you plan to render openGL across more than a single GPU.
Using the above definitions, the figures are not too outragous for well-commented source code (probably on-par with Linux's comment-to-code ratio).
The first time I saw Tcl was in the Alpha editor under MacOS 7, so it was available there. Wether or not Tcl would have been a good choice for a system-wide scripting language is another arguement.
Note that there are now AppleScript libraries for Python, and Perl has Mac::AppleScript and Mac::Glue modules, among others, so it's fairly easy to trigger AppleScript events from something other than applescript. In fact with the PerlObjCBridge it's possible to make Perl the data model for an objective-C gui.
Wow, you should really take off the tinfoil hat and read up on cryptography a little before your next post.
The secrecy of a cypher should rely entirely in the key (see D. A. Kerckhoffs). Put another way, knowing the algorithm used should not compromise a good cypher. In fact, most of the better, more trusted cyphers are published, and have been subjected to many many man-years of cryptanalysis without yielding attacks that do much better than brute force key searches (which is why we trust them and conversely why propriatary/homebrew/secret algorithms are shunned).
In the case of blowfish, to my knowledge there are no known attacks that are effective against the full 16-round cypher. There are weak keys, but it's unlikely that such keys are exploitable in practice. So it would seem unlikely (though not impossible) that blowfish has been successfully attacked by NSA. So given a large enough keyspace, the NSA would have to be willing to dedicate a large number of CPUs/FPGAs to a brute force attack. Since blowfish supports keylenghts up to 448bits, such attacks could take a while even with NSA's extensive resources. [In this context, "a while" means effectively never.]
You wanted photos, here ya go:
Yes, if they are claiming, and can prove, that DirectCD infringes, then it's likely that UDF also infringes. If UDF infringes, a lot of the packet-writing DVD software is affected (but probably not batch-oriented writers like cdrecord). Unfortunately that's still a major PITA since it means doing the ``build tree, make isofs, burn isofs'' sequence rather than quicker UDF on-the-fly burning.
some UDF basics