No, the interesting point of TFA is that people don't understand that RFID tag data is just as untrustworthy as data you get from a random web form. That's their wakeup call: if you read and parse RFID data, sanitize it first!
Ummm, no. It uses the data in an evil tag to create a SQL injection attack which causes the vulnerable backend db to infect other tags (admittedly in a contrived but quite possible scenario). It is definitely viral. (They show other attacks such as buffer overflows which are not viral as well.)
We just bought one for doing desktop video and special effects (and demos of same). Highest-powered desktop-replacement portable we could find. Had a bad video card which they replaced immediately.
Definitely worth a look for the professional. And in the video/post-production/special-effects biz, believe me the alien head is NOT a problem!
I used to run FB2000, but switched to Media Monkey. Best MP3 manager/player/jukebox I've ever seen. For instance: you have two Zappa albums, one under Zappa, Frank and the other under Frank Zappa. Just drag the second album into the first artist name and it automatically retags all the files' artist names.
Also scales easily to the 10,000 track range while still being fast, and has excellent device connectivity options. Plus it's fully scriptable.
(I have no relation to it other than very happy user)
Thanks, I didn't know that. I guess it's just regular Java overhead that makes it slow to start.
As for Swing's problems: not truly native look & feel (doesn't behave like other Windows/Mac apps), terrible event model (bad queuing design - pretty much mandates a separate gui thread), slow slow slow, memory hogging, even more increase in startup time. I could go on, but for a serious GUI app (e.g. a desktop front-end to a web app) its performance is unacceptable and it is too buggy. In our testing, it was not very cross-platform either. We ended up having a fair amount of platform-specific code. Admittedly that was some time ago; it may have gotten better since then.
> If you're writing a web app, Swing is an irrelevance
That's true. However I'd really like to not have to switch languages between all the different stuff I do. Python's sufficient for admin scripts, glue scripts, generic command-line programs, build scaffolding, web apps, and small gui apps. I imagine ruby can do all those things too (Its regexp support is better, so it's probably almost as good as perl for heavy text processing which is pretty much all I use perl for anymore).
But Java's Swing problems, startup time, and memory requirements pretty much lock it out of all those categories except web apps. Not to mention difficult interop with other languages/libs and having to compile it.
(Yes, azureus is pretty beautiful -- but look at its startup time. No problem for an app like that, but I hate waiting for apps to start up.)
Oh, just that. Sorry, I thought you had a substantive issue in mind. (We use emacs so the whitespace thing is not an issue for us, python-mode is very nice.)
[This is not a troll, it's a serious question from someone who's about to start a major db-driven web app.]
OK, everyone knows Java's a nonstarter these days. Ack, why did they kill it with Swing instead of a decent lightweight GUI (like wxWidgets or FLTK or something)? And they never got the memory usage under control.
But why Ruby and not python? What sort of errors is python prone to that ruby avoids? We have a bunch of python code here (scons and other stuff) and a bunch of older perl, and I'm reluctant to start a big web app in Yet Another Language. We all know python pretty well now. Is ruby going to be that much more maintainable? What about TurboGears for instance?
Also there seems to be a wider variety of libs available for python than ruby. And the python docs are very good. So I'm very interested to hear about the error-prone nature of large web-app development in python.
Unfortunately you simply didn't understand the OP's point. Many DRMed CDs include the original audio tracks as standard redbook audio, AND highly-compressed audio files in a separate session visible only to CDROM drives (not CD audio drives) at the end (outside) of the disc. When played on a PC, the DRM software forces the machine to only play the compressed files from the second session on the disc, not the original uncompressed audio tracks. They generally get hidden by the DRM driver somehow.
Glad you agree!:-) It'd sure make Discreet's lives easier, and their customers' lives easier... yes, and warez d00dz lives no harder than they are now.
Yeah, good luck reverse engineering a high performance realtime filesystem (with its own API only used from a closed-source app) from a binary driver. Especially one where you need custom hardware to run the app anyway.
Sure it's possible in principle. In practice, not likely.
The real point of my post (which I failed to make strongly enough) is that there are niche Linux-based apps which don't fall into the open-source world's usual pigeonholes; this is one of them. Please make their lives easier, not harder.
Discreet (now Autodesk Media & Entertainment yadda yadda) ships Flint and Flame on Linux (yes, x86 only). They have a proprietary high performance realtime file system that lives on attached SCSI drives ("Stone"). Are they likely to give away their "crown jewels", the source to that driver? Not bloody likely. Would their customers like to be able to pop that driver into any version of Linux other than the exact kernel and options that Discreet ships? Certainly! Would Discreet even like to allow their customers to do this? Definitely! They wouldn't have to ship an update for every RedHat kernel update for instance.
Currently that driver has all the mangled kernel symbols in it, as well as the well-known struct-size/offset etc. issues. If there were a binary layer like nvidia uses for their drivers, this would be easy.
Note that this is not a hardware device that is portable to PPC, Alpha, whatever other devices you might want to run Linux on so the portability concerns are moot. And the chances of getting the driver "into the tree" are zero. It's a Flame ferchrissakes. Discreet has a right to control access to its hardware and its custom software. But it would sure make everyone's life easier if their driver could install on more than just one exact kernel build!
The default adblock version does work to block ads, but clicking the Adblock button in the lower right shows nothing, and should show all the blockable elements. There's a new dev build (0.5.2.054) at the Adblock Forums which seems to work better for me with Firefox 1.5rc1.
That's a start for sure. (Well, part of a start -- assuming you've already dealt with the UTF8/unicode conversion.) But you have to save that alias to the file system in a resource fork, set the type and creator of the alias file to the same as the original, copy the badg resource if the source is a folder rather than a file, set the alias bit on the resulting file... and so on.
And if you're making aliases for things that don't exist yet, you have a whole other set of issues like how to make an FSRef for a nonexistent file.
Actually we ended up blowing off FSNewAlias() altogether most of the time because it was hard to keep open finder windows in sync and other issues. We ended up sending AppleEvents to the Finder in most cases. That's only about 70 lines, but it can have issues in certain corner cases.
Have you ever tried to create an alias on OSX programmatically? I have 750 lines of code just to do that, handling all the cases of OS9 & OSX, UTF8 filesystems, making sure the Finder updates to show it properly... and that's not even counting the Apple Events code from MoreFilesX that's linked in! All that to just emulate
symlink(const char *oldpath, const char *newpath).
Sorry, OSX aliases are, from a programmer perspective, about the worst nightmare I could imagine. Other than of course not being allowed to use paths to get to files, of course.
Another useful way to look at it is in terms of film stops, where 1 stop is log2(ratio). Print film reproduces about 7 stops between the darkest and lightest exposures. The eye can see around 9 stops in a single normally lit scene (without varying the iris opening or changing adaptation, and assuming enough light for rods & cones), or about 500:1 contrast ratio. 1,000,000:1 ratio would be 20 stops, which is over the top for anything I can think of. If the brightness is in the normal LCD backlight range, even a tiny film of dust on the surface would cut that ratio down by a factor of 1000!
I was 11th in the National Spelling Bee a few years ago (OK, more than a few now). I still love language, writing, and yes, even spelling. I'm a programmer by trade, and judging from the kids in the spelling bee with me, more of them were heading for the sciences than the liberal arts.
And yes, it has definitely helped my career. Communication skills become more and more valuable and in demand as you become more senior. So don't neglect that part of your brain! - ST
They called out the Pentium 4 3.6 GHz by name, meaning they are *probably* targeting x86-64.
No, read the Universal Binary spec. It clearly says it's IA32, and goes on to say sizeof(int)=4, sizeof(long)=4, sizeof(void *)=4. I.e. IA32 only, not x86_64/AMD64.
I agree this is a brain-dead move on Apple's part. I mean there's still a whole year before they start shipping any product based on this, and with Apple's focus on media, the address space limits of IA32 will kill them. Look at what Discreet/Autodesk and others are doing; 64-bit is necessary for video/film work. The Intel compiler already produces fine x86_64 code. Yes, the larger datatypes mean data structures are larger and you can get caching issues, but caches are growing quickly too. It just means we're all going to have to do this again a few years down the road.
The third option is to wait for Intel to recompile their x86 compiler to run under OSX. Shouldn't take them long (no new backend, it's just a command line app -- just need the new obj/lib/executable formats), and it's a sweet compiler for sure. Really good autovectorization, tight code, the Intel image/signal processing libs, etc. etc.
I'm sure it'll be available as a backend to Xcode for those like that sort of thing, and for folks like me who still like a common dev env (emacs, scons, and command-line compilers) across all platforms it'll be there even quicker.
Yeah, there isn't a Copenhagen-style collapse, but there is an unimaginably complicated topology to space-time, with some vague hand-wavy idea about how we only perceive one of these surfaces, and no explanation of how the topological development is actually brought about by any kind of physical mechanism.
What we perceive is determined by decoherence in the MWI (i.e. what decoheres from the experimenter is not perceived). Yes there's a lot of "stuff" in the multiverse, but it's not clear the topology is more complicated; it's certainly lots less complicated than string theory, for example.
"Decoherence" is the more careful calculation which justifies the Copenhagen treatment, and is applicable to modern experiments on systems with "long-lived" quantum coherence.
AFAIK, copenhagen-style decoherence still implies FTL communication (though no information exchange). MWI is strictly subluminal, which to me is more than enough all by itself. But IANAP, so what do I know.
Many-worlds is just escaping from one philosophical conundrum by postulating an even more confusing mechanism, with no detectable improvement in the physics.
Is the mechanism so much more confusing? All it says is that all solutions to the SWE exist in reality. That seems pretty simple to me. The removal of collapse, simple subluminal signaling, no preferred basis functions, and the bonus of philosophical underpinnings for counterfactuals and probability all make it much more comfortable for me than Copenhagen. But of course the jury is still out.
If quantum computers can be made large enough to factor very large numbers in reasonable time, this will be reasonable proof of an MWI-like multiverse, because such a task would require more computation than is available in a lab-sized chunk of a single universe. But we're nowhere near such a device yet, and error correction and other "details" may make it permanently impractical. We'll see.
Well, the Slashdot story is not a hoax, nor is the ABC News article, though the original article in vol 233 issue 4 of Journal of Theoretical Biology might be. (If that link doesn't work, go to Science Direct and do a search for kanazawa.)
Re:On-Demand non-commerical TV would ruin networks
on
Television Reloaded
·
· Score: 2, Interesting
This is how cable was originally promoted -- you pay for the privilege of not having commercials. Then along came MTV which was one big commercial, and that was the beginning of the end. (More or less.)
Slashdot Mirror
No, the interesting point of TFA is that people don't understand that RFID tag data is just as untrustworthy as data you get from a random web form. That's their wakeup call: if you read and parse RFID data, sanitize it first!
Ummm, no. It uses the data in an evil tag to create a SQL injection attack which causes the vulnerable backend db to infect other tags (admittedly in a contrived but quite possible scenario). It is definitely viral. (They show other attacks such as buffer overflows which are not viral as well.)
We just bought one for doing desktop video and special effects (and demos of same). Highest-powered desktop-replacement portable we could find. Had a bad video card which they replaced immediately.
Definitely worth a look for the professional. And in the video/post-production/special-effects biz, believe me the alien head is NOT a problem!
-- ST
I used to run FB2000, but switched to Media Monkey. Best MP3 manager/player/jukebox I've ever seen. For instance: you have two Zappa albums, one under Zappa, Frank and the other under Frank Zappa. Just drag the second album into the first artist name and it automatically retags all the files' artist names.
Also scales easily to the 10,000 track range while still being fast, and has excellent device connectivity options. Plus it's fully scriptable.
(I have no relation to it other than very happy user)
> Azureus isn't Swing it's SWT
Thanks, I didn't know that. I guess it's just regular Java overhead that makes it slow to start.
As for Swing's problems: not truly native look & feel (doesn't behave like other Windows/Mac apps), terrible event model (bad queuing design - pretty much mandates a separate gui thread), slow slow slow, memory hogging, even more increase in startup time. I could go on, but for a serious GUI app (e.g. a desktop front-end to a web app) its performance is unacceptable and it is too buggy. In our testing, it was not very cross-platform either. We ended up having a fair amount of platform-specific code. Admittedly that was some time ago; it may have gotten better since then.
> If you're writing a web app, Swing is an irrelevance
That's true. However I'd really like to not have to switch languages between all the different stuff I do. Python's sufficient for admin scripts, glue scripts, generic command-line programs, build scaffolding, web apps, and small gui apps. I imagine ruby can do all those things too (Its regexp support is better, so it's probably almost as good as perl for heavy text processing which is pretty much all I use perl for anymore).
But Java's Swing problems, startup time, and memory requirements pretty much lock it out of all those categories except web apps. Not to mention difficult interop with other languages/libs and having to compile it.
(Yes, azureus is pretty beautiful -- but look at its startup time. No problem for an app like that, but I hate waiting for apps to start up.)
-- SilentTristero
Oh, just that. Sorry, I thought you had a substantive issue in mind. (We use emacs so the whitespace thing is not an issue for us, python-mode is very nice.)
-- SilentTristero
[This is not a troll, it's a serious question from someone who's about to start a major db-driven web app.]
OK, everyone knows Java's a nonstarter these days. Ack, why did they kill it with Swing instead of a decent lightweight GUI (like wxWidgets or FLTK or something)? And they never got the memory usage under control.
But why Ruby and not python? What sort of errors is python prone to that ruby avoids? We have a bunch of python code here (scons and other stuff) and a bunch of older perl, and I'm reluctant to start a big web app in Yet Another Language. We all know python pretty well now. Is ruby going to be that much more maintainable? What about TurboGears for instance?
Also there seems to be a wider variety of libs available for python than ruby. And the python docs are very good. So I'm very interested to hear about the error-prone nature of large web-app development in python.
-- SilentTristero
Yup. I only buy from emusic anymore.
Unfortunately you simply didn't understand the OP's point. Many DRMed CDs include the original audio tracks as standard redbook audio, AND highly-compressed audio files in a separate session visible only to CDROM drives (not CD audio drives) at the end (outside) of the disc. When played on a PC, the DRM software forces the machine to only play the compressed files from the second session on the disc, not the original uncompressed audio tracks. They generally get hidden by the DRM driver somehow.
> help them delude themselves? sure, why not.
:-) It'd sure make Discreet's lives easier, and their customers' lives easier... yes, and warez d00dz lives no harder than they are now.
Glad you agree!
Yeah, good luck reverse engineering a high performance realtime filesystem (with its own API only used from a closed-source app) from a binary driver. Especially one where you need custom hardware to run the app anyway.
Sure it's possible in principle. In practice, not likely.
The real point of my post (which I failed to make strongly enough) is that there are niche Linux-based apps which don't fall into the open-source world's usual pigeonholes; this is one of them. Please make their lives easier, not harder.
Discreet (now Autodesk Media & Entertainment yadda yadda) ships Flint and Flame on Linux (yes, x86 only). They have a proprietary high performance realtime file system that lives on attached SCSI drives ("Stone"). Are they likely to give away their "crown jewels", the source to that driver? Not bloody likely. Would their customers like to be able to pop that driver into any version of Linux other than the exact kernel and options that Discreet ships? Certainly! Would Discreet even like to allow their customers to do this? Definitely! They wouldn't have to ship an update for every RedHat kernel update for instance.
Currently that driver has all the mangled kernel symbols in it, as well as the well-known struct-size/offset etc. issues. If there were a binary layer like nvidia uses for their drivers, this would be easy.
Note that this is not a hardware device that is portable to PPC, Alpha, whatever other devices you might want to run Linux on so the portability concerns are moot. And the chances of getting the driver "into the tree" are zero. It's a Flame ferchrissakes. Discreet has a right to control access to its hardware and its custom software. But it would sure make everyone's life easier if their driver could install on more than just one exact kernel build!
Anyway enough ranting for now.
The default adblock version does work to block ads, but clicking the Adblock button in the lower right shows nothing, and should show all the blockable elements. There's a new dev build (0.5.2.054) at the Adblock Forums which seems to work better for me with Firefox 1.5rc1.
Rosyna wrote: ... use FSNewAlias()...
That's a start for sure. (Well, part of a start -- assuming you've already dealt with the UTF8/unicode conversion.) But you have to save that alias to the file system in a resource fork, set the type and creator of the alias file to the same as the original, copy the badg resource if the source is a folder rather than a file, set the alias bit on the resulting file... and so on.
And if you're making aliases for things that don't exist yet, you have a whole other set of issues like how to make an FSRef for a nonexistent file.
Actually we ended up blowing off FSNewAlias() altogether most of the time because it was hard to keep open finder windows in sync and other issues. We ended up sending AppleEvents to the Finder in most cases. That's only about 70 lines, but it can have issues in certain corner cases.
Have you ever tried to create an alias on OSX programmatically? I have 750 lines of code just to do that, handling all the cases of OS9 & OSX, UTF8 filesystems, making sure the Finder updates to show it properly... and that's not even counting the Apple Events code from MoreFilesX that's linked in! All that to just emulate
symlink(const char *oldpath, const char *newpath).
Sorry, OSX aliases are, from a programmer perspective, about the worst nightmare I could imagine. Other than of course not being allowed to use paths to get to files, of course.
Another useful way to look at it is in terms of film stops, where 1 stop is log2(ratio). Print film reproduces about 7 stops between the darkest and lightest exposures. The eye can see around 9 stops in a single normally lit scene (without varying the iris opening or changing adaptation, and assuming enough light for rods & cones), or about 500:1 contrast ratio. 1,000,000:1 ratio would be 20 stops, which is over the top for anything I can think of. If the brightness is in the normal LCD backlight range, even a tiny film of dust on the surface would cut that ratio down by a factor of 1000!
I see you've never tried Shake. Useless without a 3-button mouse (check the Tech Specs; it even lists 3-button mouse as a requirement.)
I was 11th in the National Spelling Bee a few years ago (OK, more than a few now). I still love language, writing, and yes, even spelling. I'm a programmer by trade, and judging from the kids in the spelling bee with me, more of them were heading for the sciences than the liberal arts.
And yes, it has definitely helped my career. Communication skills become more and more valuable and in demand as you become more senior. So don't neglect that part of your brain!
- ST
Umm, that article from MacObserver was an April Fools' joke from 2002 (just look at the URL even).
;-)
Sorry you fell for it... again!
No, read the Universal Binary spec. It clearly says it's IA32, and goes on to say sizeof(int)=4, sizeof(long)=4, sizeof(void *)=4. I.e. IA32 only, not x86_64/AMD64.
I agree this is a brain-dead move on Apple's part. I mean there's still a whole year before they start shipping any product based on this, and with Apple's focus on media, the address space limits of IA32 will kill them. Look at what Discreet/Autodesk and others are doing; 64-bit is necessary for video/film work. The Intel compiler already produces fine x86_64 code. Yes, the larger datatypes mean data structures are larger and you can get caching issues, but caches are growing quickly too. It just means we're all going to have to do this again a few years down the road.
The third option is to wait for Intel to recompile their x86 compiler to run under OSX. Shouldn't take them long (no new backend, it's just a command line app -- just need the new obj/lib/executable formats), and it's a sweet compiler for sure. Really good autovectorization, tight code, the Intel image/signal processing libs, etc. etc.
I'm sure it'll be available as a backend to Xcode for those like that sort of thing, and for folks like me who still like a common dev env (emacs, scons, and command-line compilers) across all platforms it'll be there even quicker.
What we perceive is determined by decoherence in the MWI (i.e. what decoheres from the experimenter is not perceived). Yes there's a lot of "stuff" in the multiverse, but it's not clear the topology is more complicated; it's certainly lots less complicated than string theory, for example.
"Decoherence" is the more careful calculation which justifies the Copenhagen treatment, and is applicable to modern experiments on systems with "long-lived" quantum coherence.
AFAIK, copenhagen-style decoherence still implies FTL communication (though no information exchange). MWI is strictly subluminal, which to me is more than enough all by itself. But IANAP, so what do I know.
Many-worlds is just escaping from one philosophical conundrum by postulating an even more confusing mechanism, with no detectable improvement in the physics.
Is the mechanism so much more confusing? All it says is that all solutions to the SWE exist in reality. That seems pretty simple to me. The removal of collapse, simple subluminal signaling, no preferred basis functions, and the bonus of philosophical underpinnings for counterfactuals and probability all make it much more comfortable for me than Copenhagen. But of course the jury is still out.
If quantum computers can be made large enough to factor very large numbers in reasonable time, this will be reasonable proof of an MWI-like multiverse, because such a task would require more computation than is available in a lab-sized chunk of a single universe. But we're nowhere near such a device yet, and error correction and other "details" may make it permanently impractical. We'll see.
Well, the Slashdot story is not a hoax, nor is the ABC News article, though the original article in vol 233 issue 4 of Journal of Theoretical Biology might be. (If that link doesn't work, go to Science Direct and do a search for kanazawa.)
This is how cable was originally promoted -- you pay for the privilege of not having commercials. Then along came MTV which was one big commercial, and that was the beginning of the end. (More or less.)