Apple's stuff is very slick, and if MacOs X had come out just a couple of years earlier I might stick with it -- but now I'm pretty entrenched in an Athlon/Pentium world, and don't see a lot of reason to switch. Sure, if I were starting from scratch I might be tempted by the really slick Apple interface -- after all, I was one of the diehards who stuck around for an effing decade waiting for the true memory-protected, pre-emptive multitasking. (OS 9 is where I ditched Apple -- after OS 8 turned out to be a rehash of OS 7 -- which was supposed to be the pre-emptive system way back when we all ran OS 6. And wasn't pre-emption one of the goals for OS 6? I seem to remember that, 'way back in the early MultiFinder days of OS 5, people were already talking about the need for real multitasking...)
But now I'm not about to learn an entirely new filesystem layout, when Red Hat is working just fine. Once, I could complain that not all the tools are in Linux -- but with the recent spate of video drivers, audio editing tools, and cool CAD and drawing software, there's no ``killer app'' that draws me irresistibly back to the Apples.
There are several device-independent graphics packages for PDL. The main one is PGPLOT, a venerable but powerful package written in FORTRAN in days of yore. PGPLOT has output modules for everything from a PASCAL turtle to (yes) eps. There are interactive devices (X windows and such) and hardcopy devices (PostScript, EPS, gif, jpeg, png, and such).
What impressed me most about PGPLOT when I started using it is the strong device-independence. For example, it's difficult to say "Give me a 600x400 pixel X window" since pixels aren't device independent. It's much easier to say "Give me a 6-inch by 4-inch X window". Takes some getting used to, but then when you go to stick your output into a publication you can generate the same plot and send it to (say) the eps device instead of the X-windows device.
The PDL front-end has a record-and-play feature, too, so you can define a PGPLOT X window, noodle around with it, and then say "Replay all that into this hard-copy device" and get exactly the same plot, rendered on the other device.
Heh. Touche on the symbolic logic stuff, though calling PDL a Perl interface to LAPACK is like calling Maple a graphing calculator. Yes, it can do those things -- but that's a tiny part of the functionality.
The GIS stuff is a collection of vector and pixel coordinate-transform methods that allow you to plot, overlay, and compare map data from all the conventional formats. There are some sample global-scale maps of Earth included in the distribution, but they're not especially high resolution since they're mainly intended to demonstrate the capability.
We designed the GIS code to be useful for planetary, astronomical, and solar work -- it's "just" a set of tools for dealing with sampled and vector data in a spherical system.
Yep, you're right that Mathematica is not a good comparison -- I stuck that in mainly as a reference to the numerical part of Mathematica, but the symbolic stuff is pretty much unmatched (though Maple fans might disagree).
Much of PDL's development has been motivated by a need for something "like IDL, but more powerful", and I think that's really where PDL shines best: in remote sensing and image processing tasks. It helps a lot that all of CPAN is already present, and that the file I/O and indexing have many fewer "gotchas" than those of IDL. The PGPLOT back-end is great, too, for actual device-independent plotting: how many hours have you spent tweaking your IDL plots to actually print right on the PostScript device?
It's (IMHO) a Good Thing that we have all three of numpy/scipy, Octave, and PDL: each has a different set of strengths. Ultimately, each group really should use the tool that suits them best (and it shouldn't cost more than the workstation it runs on...). The reason I've more-or-less committed to perl development rather than Python or Octave is that it has a nice "natural language", expressive feel to it: it's easy to build pipeline-style, imperative-style, or evaluated-style constructs, whichever is most convenient for the current application.
Of course, the open-source languages have the added benefit that results derived using them are actually reproducible, whereas closed-source languages might conceal irreproducible bugs (in the language or the reduction code) that other groups can't identify.
Actually, I'm not an employee of the U.S. Government, I'm an employee of Southwest Research Institute. What we do is produce scientific results under contract to NASA (and elsewhere). The actual results that we produce are (I believe, but IANAL) required to be in the public domain, but the software tools and intermediate data products are certainly not: in fact, much of NASA's scientific work is done using proprietary, closed-source software, something I'm actively combating within my community.
So, the intermediate products and tools that I use are in general copyrighted, and I do what I can to ensure that they are licensed universally under GPL, Perl Artistic, or other approved open source licenses.
Needless to say, the contributions I make to open-source projects (like, say, PDL) count as tools and/or intermediate data products and hence are released back into the community from whence they came.
If you are in a position to negotiate contracts of this sort (ie to get a particular result) I encourage you to write-in that the tools will be released under a free software license, or into the public domain -- that way you can give back to the software community that helps support you.
The work I do is mostly funded by NASA, under scientific grants. Every grant proposal I submit contains the words "All software and intermediate data products will be freely released to the general public" (or minor variations on that sentence). That way I'm actually required to release stuff, and the most restrictive license I can put on it is something like GPL (public domain would also work, of course). Haven't had any problems with management over it.
or instance, at some point there was a trick for a test with lots of occlusion to clip (discard) polygons that would eventually be occluded. However, these discarded polygons were actually calculated at run-time and not precomputed, so if you changed the test, it would still work right.
You have just described an optimization, not a cheat. The point of cheats is that they take advantage of knowledge that's not available to normal processes. If your "cheat" takes no such advantage (e.g. calculating its shortcuts at runtime based only on the actual rendering data) then it's actually an optimization.
Lets face it, working on a FreeBSD box after working on an old mainframe is like driving a VW bug with flowers all over it after driving a boss 69 camereo.
Except that the VW bug, while it still looks tiny on the outside, has as much room as a doublewide trailer on the inside -- and someone replaced the air-cooled four-banger with a J-2 rocket engine. There are still no seat-belts.
In 1993/1994 I was a graduate student at Stanford University and designed a simple challenge/response spam filtering system that works substantially the same as the one being advertised. Unknown incoming addresses were entered into simple ASCII database, and the associated mails were stashed in individual files in a particular directory. Unique challenge letters were to be sent out, and the mail was to be delivered or canned depending on the response (or lack thereof) from the challenge.
I never finished implementing the system (I wrote my dissertation instead) but still have a midsized collection of emails about it.
Challenge/response has got to be "obvious to one versed in the art" -- I can think of at least three other people at Stanford who had the same idea at about the same time.
Thanks, editors -- that article is a good reminder of what the web is supposed to be about: communicating things that are happening in real life.
So what if generators are "old technology"? How many have you made?
Why by ProTools? Audacity is free...
on
Cheap Audio Production
·
· Score: 2, Interesting
Audacity has come a looong way in the last year -- I believe they're finally supporting professional-grade digital audio and not just CD-quality (not that I can tell the difference, or anything...).
I have been gritting my teeth over the similar tactics that Epson uses -- their Photo 780, for example, is a great printer but the ink cartridges have counter chips on them that prevent refilling.
You can get around that by buying one of the many
"chip resetters" that are now on the market -- or you can use a simple trick to transfer the counter value between cartridges, due to a design error in most epson printers' firmware.
I found the trick on the web after about a half-hour of googling around, and it worked fine our printer -- but it was hard enough to find, and trivial enough, that I figure it's worth posting here.
Here it is. You'll need (1) a chipped ink cartridge that "thinks" it is full; (2) a similar ink cartridge that "thinks" it is empty; (3) your printer. Do this:
Press the appropriate panel buttons to change the ink cartridge.
Load the new ink cartridge into the printer carriage.
Press the approriate panel buttons to put the printer online. The carriage will move off to the right side of the printer, in its normal parked position.
Manually pull the carriage out to an accessible location (where it would normally be when you're changing the cartridge). This requires very little force but does require releasing the parking latch under the print carriage -- use a shim of some kind to sweep under the carriage from back to front. (The blunt side of a leatherman blade works great.)
Swap out the new cartridge and put in the old cartridge.
Push the carriage back into place. Listen for the latch.
Print something.
The firmware in the printer reads in the chip counter values when you first load the cartridge, then writes them back after each swipe of the carriage. By swapping cartridges you write the "full" value into the empty cartridge. Then just reload with your favorite refill ink.
(This is starting to get off-topic, but what the heck) Raising insurance rates for drivers is certainly another way to tackle the problem -- but it has the problem that it shifts blame for the massive head injuries to the drivers that hit the motorcyclists.
It's arguable that, if you ride without proper protection, you're a stupidhead and anything that happens to you is your own idiot fault. Certainly, as a car (and motorcycle) driver, I don't want to assume liability for those idiots who choose to be stupid.
On the other hand, it seems really stupid to a libertarian (small "L") like me to legislate self-destructive behavior.
I agree about not giving legislative powers to the insurance companies. It still gets my goat, a decade later.
It would be entirely reasonable for them to restrict the use of that application (via the EULA) to avoid deployment on other OS's, due to the unpredictable issues that will pop up.
Actually, no, it wouldn't be. Yes, attempting to regulate use of the application is one way to solve the problem. No, it's far from the best way.
In California in the mid-1990s, there was a problem that insurance companies were getting hit hard by large court awards to the families of motorcyclists. It seems that a lot of motorcyclists were getting killed in collisions with cars, where the cars were at fault. The solution that was adopted was to require all riders to wear motorcycle helmets -- in other words, to assume a paternalistic attitude toward the riders. The correct solution (in the sense of being minimally intrusive while solving the problem) would have been to legally limit the liability of car drivers who hit helmetless motorcyclists.
Likewise, restricting the operating system is a bad move from the point of view of the customer: a better solution (for the customer) is just to refute any warranty or support for other platforms than Windows. The only reason to try restricting the output environment is to preserve Microsoft's monopoly, at the expense of the customer.
Yah. My objection is that those are alleged documentary photos -- all the objects in them should physically exist, even if they're "not-for-flight" mockup nozzles. The pair-of-ducks picture clearly has such a "not-for-flight" nozzle on board.
Most folks don't realize the enormous difficulty of getting into orbit, compared to getting into space. Just lifting yourself up 150 miles or so is no big deal compared to getting up the tremendous speed required to orbit the Earth. For example, when the Space Shuttle launches, it start out straight up, then rapidly tilts over to thrust eastward, then continues onward, rockets firing, past the horizon. Think about that. In order to go under the horizon, rockets firing, it must now be thrusting slightly downward compared to the original launch. By far the largest part of the effort of a satellite launch is developing orbital speed (order of 5 miles per second); compared to that, tiny things like getting out of the atmosphere are trivial.
A manned orbital vehicle would have to have a completely different shape than the SpaceShipOne -- the rocket motor assembly would be more than 50x bigger than the passengers, rather than comparable to them in size. (For example, compare the boosters used for the Mercury/Redstone flights and the Mercury orbital flights).
Slashdot Mirror
Heh. International Fed Ex probably isn't that reliable or quick during wartime... :-P
You had a 4.7 MHz computer? I wrote graphics shoot-em-ups in INTEGER BASIC on a 1.077 MHz Apple ][. And they were cool.
Before that, we used to go down the university in the middle of the night and play ADVENTURE on the PDP-11.
But now I'm not about to learn an entirely new filesystem layout, when Red Hat is working just fine. Once, I could complain that not all the tools are in Linux -- but with the recent spate of video drivers, audio editing tools, and cool CAD and drawing software, there's no ``killer app'' that draws me irresistibly back to the Apples.
Try xine -- works great for me, under Red Hat 9.
just install the "kernel-devel" option, switch on the SMP options, and recompile. Takes less time than writing to Ask Slashdot, that's for sure.
XV's been leapfrogged for most stuff -- eog works so much better for casual browsing...
(My personal fave was the foam blob from a few months back).
There are several device-independent graphics packages for PDL. The main one is PGPLOT, a venerable but powerful package written in FORTRAN in days of yore. PGPLOT has output modules for everything from a PASCAL turtle to (yes) eps. There are interactive devices (X windows and such) and hardcopy devices (PostScript, EPS, gif, jpeg, png, and such).
What impressed me most about PGPLOT when I started using it is the strong device-independence. For example, it's difficult to say "Give me a 600x400 pixel X window" since pixels aren't device independent. It's much easier to say "Give me a 6-inch by 4-inch X window". Takes some getting used to, but then when you go to stick your output into a publication you can generate the same plot and send it to (say) the eps device instead of the X-windows device.
The PDL front-end has a record-and-play feature, too, so you can define a PGPLOT X window, noodle around with it, and then say "Replay all that into this hard-copy device" and get exactly the same plot, rendered on the other device.
Heh. Touche on the symbolic logic stuff, though calling PDL a Perl interface to LAPACK is like calling Maple a graphing calculator. Yes, it can do those things -- but that's a tiny part of the functionality.
The GIS stuff is a collection of vector and pixel coordinate-transform methods that allow you to plot, overlay, and compare map data from all the conventional formats. There are some sample global-scale maps of Earth included in the distribution, but they're not especially high resolution since they're mainly intended to demonstrate the capability.
We designed the GIS code to be useful for planetary, astronomical, and solar work -- it's "just" a set of tools for dealing with sampled and vector data in a spherical system.
Yep, you're right that Mathematica is not a good comparison -- I stuck that in mainly as a reference to the numerical part of Mathematica, but the symbolic stuff is pretty much unmatched (though Maple fans might disagree).
Much of PDL's development has been motivated by a need for something "like IDL, but more powerful", and I think that's really where PDL shines best: in remote sensing and image processing tasks. It helps a lot that all of CPAN is already present, and that the file I/O and indexing have many fewer "gotchas" than those of IDL. The PGPLOT back-end is great, too, for actual device-independent plotting: how many hours have you spent tweaking your IDL plots to actually print right on the PostScript device?
It's (IMHO) a Good Thing that we have all three of numpy/scipy, Octave, and PDL: each has a different set of strengths. Ultimately, each group really should use the tool that suits them best (and it shouldn't cost more than the workstation it runs on...). The reason I've more-or-less committed to perl development rather than Python or Octave is that it has a nice "natural language", expressive feel to it: it's easy to build pipeline-style, imperative-style, or evaluated-style constructs, whichever is most convenient for the current application.
Of course, the open-source languages have the added benefit that results derived using them are actually reproducible, whereas closed-source languages might conceal irreproducible bugs (in the language or the reduction code) that other groups can't identify.
So, the intermediate products and tools that I use are in general copyrighted, and I do what I can to ensure that they are licensed universally under GPL, Perl Artistic, or other approved open source licenses.
Needless to say, the contributions I make to open-source projects (like, say, PDL) count as tools and/or intermediate data products and hence are released back into the community from whence they came.
If you are in a position to negotiate contracts of this sort (ie to get a particular result) I encourage you to write-in that the tools will be released under a free software license, or into the public domain -- that way you can give back to the software community that helps support you.
The work I do is mostly funded by NASA, under scientific grants. Every grant proposal I submit contains the words "All software and intermediate data products will be freely released to the general public" (or minor variations on that sentence). That way I'm actually required to release stuff, and the most restrictive license I can put on it is something like GPL (public domain would also work, of course). Haven't had any problems with management over it.
You have just described an optimization, not a cheat. The point of cheats is that they take advantage of knowledge that's not available to normal processes. If your "cheat" takes no such advantage (e.g. calculating its shortcuts at runtime based only on the actual rendering data) then it's actually an optimization.
Except that the VW bug, while it still looks tiny on the outside, has as much room as a doublewide trailer on the inside -- and someone replaced the air-cooled four-banger with a J-2 rocket engine. There are still no seat-belts.
I never finished implementing the system (I wrote my dissertation instead) but still have a midsized collection of emails about it.
Challenge/response has got to be "obvious to one versed in the art" -- I can think of at least three other people at Stanford who had the same idea at about the same time.
So what if generators are "old technology"? How many have you made?
Audacity has come a looong way in the last year -- I believe they're finally supporting professional-grade digital audio and not just CD-quality (not that I can tell the difference, or anything...).
I found the trick on the web after about a half-hour of googling around, and it worked fine our printer -- but it was hard enough to find, and trivial enough, that I figure it's worth posting here.
Here it is. You'll need (1) a chipped ink cartridge that "thinks" it is full; (2) a similar ink cartridge that "thinks" it is empty; (3) your printer. Do this:
- Press the appropriate panel buttons to change the ink cartridge.
- Load the new ink cartridge into the printer carriage.
- Press the approriate panel buttons to put the printer online. The carriage will move off to the right side of the printer, in its normal parked position.
- Manually pull the carriage out to an accessible location (where it would normally be when you're changing the cartridge). This requires very little force but does require releasing the parking latch under the print carriage -- use a shim of some kind to sweep under the carriage from back to front. (The blunt side of a leatherman blade works great.)
- Swap out the new cartridge and put in the old cartridge.
- Push the carriage back into place. Listen for the latch.
- Print something.
The firmware in the printer reads in the chip counter values when you first load the cartridge, then writes them back after each swipe of the carriage. By swapping cartridges you write the "full" value into the empty cartridge. Then just reload with your favorite refill ink.Integer divide can overflow even if the operands have the same size as the destination. Consider
-32768 / -1 = 32768
That would overflow a signed short.
It's arguable that, if you ride without proper protection, you're a stupidhead and anything that happens to you is your own idiot fault. Certainly, as a car (and motorcycle) driver, I don't want to assume liability for those idiots who choose to be stupid.
On the other hand, it seems really stupid to a libertarian (small "L") like me to legislate self-destructive behavior.
I agree about not giving legislative powers to the insurance companies. It still gets my goat, a decade later.
Actually, no, it wouldn't be. Yes, attempting to regulate use of the application is one way to solve the problem. No, it's far from the best way.
In California in the mid-1990s, there was a problem that insurance companies were getting hit hard by large court awards to the families of motorcyclists. It seems that a lot of motorcyclists were getting killed in collisions with cars, where the cars were at fault. The solution that was adopted was to require all riders to wear motorcycle helmets -- in other words, to assume a paternalistic attitude toward the riders. The correct solution (in the sense of being minimally intrusive while solving the problem) would have been to legally limit the liability of car drivers who hit helmetless motorcyclists.
Likewise, restricting the operating system is a bad move from the point of view of the customer: a better solution (for the customer) is just to refute any warranty or support for other platforms than Windows. The only reason to try restricting the output environment is to preserve Microsoft's monopoly, at the expense of the customer.
The "mated" image includes the shadows of the landing gear from the non-mated image in the litho.
Well spotted!
Yah. My objection is that those are alleged documentary photos -- all the objects in them should physically exist, even if they're "not-for-flight" mockup nozzles. The pair-of-ducks picture clearly has such a "not-for-flight" nozzle on board.
A manned orbital vehicle would have to have a completely different shape than the SpaceShipOne -- the rocket motor assembly would be more than 50x bigger than the passengers, rather than comparable to them in size. (For example, compare the boosters used for the Mercury/Redstone flights and the Mercury orbital flights).