Assuming that the identifying factor in the ink really was an amplified portion of someone's DNA, it wouldn't be hard to replicate simply by doing PCR on all the notable strands in the broth. If there's enough for some Olympic "official" to wave a wand over and detect, there's enough to replicate. PCR is not hard - the July 2000 issue of Scientific American has a method by which you can perform it at home with a couple hundred dollars worth of easily-obtained equipment (which they will sell you at cost). If it's worth going to the trouble of sewing in labels to counterfeit this junk clothing, it'll be just as worth brewing up a big batch of ink to spray on (in fact it'll probably be cheaper). Further assuming they're not full of horse manure with this announcement, why would they use human DNA? Symbolic value? Any sort of plant or animal DNA would have worked, and there are probably other kinds better suited to this sort of application - but it makes a better, more mystically valid-seeming announcement if it's a human athlete. I suspect they're using some typical glow-in-the-dark chemical ink of the sort that's been in use for at least a decade, and the DNA nonsense is just misdirection. I don't believe the Olympic brownshirts running after street vendors would really have the equipment or clue to test for a particular sequence of human DNA, though they could test for the presence of any DNA (as many other not particularly remarkable chemicals). The existing special inks would probably be harder to replicate, ironically enough, because that's one of their specific design goals. This is trendy, high-tech seeming hype. Fortunately for the Olympic committee, this clothing and paraphrenalia is destined to have it's valuelessness exposed in a few months anyway, so their "security" measures (including this obfuscation) don't have to hold up for very long anyway. Personally I'll just watch the Special Olympics, the last bastion of what the modern Olympics were supposed to stand for before T-shirts and $#@$!ing pins took over...
Assuming I didn't go out of my way to ignore advertising of all kinds (which I do) why would I need targeted ads to tell me about things I already know I'm interested in? If I'm interested, I can and will seek things out on my own.
The one thing that ads are potentially good for is in introducing you to something that might be useful and wholly unexpected. I've yet to see how profiling is going to help with this - so far it seems to be more about convincing cola addicts to drink even more cola / a different brand than they already do. Before you can accept that targeted advertising is *good*, you have to accept that advertising in general is good, or at least that it can be. As opposed to being, say, a continuous drain on spending from everyone involved without any real demonstrated benefit. Maybe targeting can fix that, but I'm not holding my breath - it's not even really in Madison Avenue's interest if it does.
Actually, you do have various rights to TV - the airwaves are public property in the US and Canada. You actually bequeath the right to broadcast programs and ads to the TV station, via your elected representatives.
Your point is certainly valid (you don't have a citizenship right to Tivo service), but not as broadly applicable as you suggest.
Well, it's at least innaccurate - the name of the site (and more importantly, it's domain name) is "fuckedcompany.com". An asterisk isn't even legal in a domain name, at that. You can't include a link without spelling it out at least once, so any other munging is pointless at best and hypocritical at worst (if it's not ok to say "fuck", it shouldn't really be ok to link to a page that will sprinkle that term liberally around unless there's a substantial warning of the fact - which is obviously not going to appear on/.). Even if it's only the headline that was munged, as in this case.
In this particular case I'd say the/. article (in part *because* of the RDF propagation) should spell it correctly without euphemism. The site (which is quite interesting in concept) *really is* about completely fucked companies, not f*cked ones or fscked ones or mildly addled ones. Sometimes a rose needs to be called a rose. If it's offensive to a site receiving the story via RDF, they should probably just reconsider whether they really want to be associated with slashdot, because it's going to happen in future with far more objectionable content than this.
The baseline incidence is an important fact in these issues, and as you imply it's nearly always glossed over in favour of "doubled risk" or some other multiple. But the point made by the growth curve chart on the New Scientist page is that there are 500M cellphone users now, and more in the future. If there are a billion users in two years and an extra 1/100K risk of a lethal tumor, 10,000 people will be killed by their cellphones. That's a lot of preventable human pain and loss.
The real point of these cellphone articles is being consistently lost - we don't know yet because we need good *nonbiased* studies starting now. All of the ones to date have been done either via cellphone industry funding (the vast majority in fact) or by people with an ax to grind. Both of these are equally useful. As you note, the effects are likely to be longterm - if there are real cases happening now it's because those people happened to be the canaries in this coalmine - so the studies will need to be longterm too. It'd be nice to get a leg up on this if it does introduce real danger, instead of waiting 300 years the way we did with tobacco.
I have a question for all the IANALs out there. I know that normally one isn't liable for purchases made on one's credit card by other people - the card company takes the responsibility of chasing down the offender. However, in a case like this where a subsection of card numbers have been stolen and the cardholders have been warned by the entity that lost them does the onus begin to shift to those cardholders? Maybe I'm paranoid, but I'm visualising a scenario where the card company says "well you were warned and you failed to cancel your card, so you have some responsibility too". Could this happen? Could it happen if instead of Western Union warning the customers affected, it was the card company(s)?
The reason it occurs to me that the card companies might want to partially reverse their long practice of not blaming the customer is that (a) these things are going to become more frequent, and especially (b) when this does happen, it happens en masse instead of a single, easily-tracked theft. If 50,000 cards are stolen and used for 50,000 medium-size automated purchases, it could be hard to seek redress. Indeed the paperwork in tracking down all the unauthorised purchases would probably be more expensive for the card company than the actual purchases themselves.
Actually, you can. The Mac DivX player (you can keep the capitalisation straight by noticing it stands for Div[1-4]) actually seems to work by registering the MS-MPEG4.x codecs in Windows Media Player with Quicktime (they're actually present as Quicktime components - "thng" resources - in WiMP already, presumably it uses Quicktime for its display on the Mac, making it basically an interpreter for the proprietary.asf file format).
That means that you can leave the DivX player running in the background and be able to play MS-MPEG4/DivX encoded AVI files in Quicktime. You can't play.asf, though, because Quicktime doesn't know how to read that file format yet. I'm not sure why Captain Stux (author of this Mac DivX hack) didn't just make the codecs contained in WiMP 6.3 into "thng" extension files so they could load as separate QT components - some technical reason perhaps, or just to avoid annoying M$'s lawyers.
The people snarking about QT player don't understand Quicktime at all, though - it's just a shell, and really has nothing to do with QT except as a cheap way to call the API. Quicktime proper is more akin to an operating system than an application - it can do damn near anything, and it's very elegantly designed. QT player is an abomination, but there are lots of alternatives (including plain old Movieplayer 3.0 or 2.5). Windows might not have any alternates yet, but they wouldn't be hard to write. I expect Apple's QT player will change substantially in its next (pun intended) incarnation to match the Aqua interface anyway.
It's not clear if you specifically mean video codecs, and the definition of "come out" might be stretched, but Ogg Vorbis appears to be a very good music codec (even partially completed), and it is open source.
Give this stuff a chance - the real thrust of open source development only reached critical mass a year or two ago (assuming it even has!), and it takes time to develop these scientifically complex projects. The reason we've so far seen Unix reimplementation and catchup work could simply be that those are the relatively easy tasks, as well as representing the infrastructure for future open source work. There just aren't that many people who get into highly refined fields like perceptual encoding, but those who do invariably do it from sheer internal drive, not because they want to get rich quick. Whatever the other arguments for or against open source media codecs might be, I don't think the added financial incentive of propriety is going to be a real issue here. And even if it were, it seems that many companies grok the sell-service-not-software business model and are willing to bankroll the development of new codecs and techniques (Ogg is an example again).
As for the deep scientific angle on codec development, it's often overstated - a lot of successes come from good luck or from treating human subjects as black boxes. The story of how the MPEG-1 layer III algorithm was refined by one engineer listening to Tom's Diner a few hundred times comes to mind.;)
This post was written by a hack with just enough understanding of the MacOS and AppleScript to screw it up.
(grin) I'll certainly plead to the AppleScript part - just enough knowledge to make a mess of my own scripts. As for the Mac OS, however, I wasn't referring to the remote scripting mechanism or to Program Linking, and I should have been more clear. The problem is that applications can themselves originate AppleEvents, and if a web browser or server (say) can be compromised and includes AppleScript invocation as a feature of its own internal scripability, you can compromise the entire OS and not just that one application - it breaks out of its sandbox. I do think this is very comparable to the effects of the system(2) call in Unix.
Additionally, saying that AppleScript is comparable to the Bourne shell is a crock of shit. For better or worse, the Bourne shell has far more power than AppleScript does. AppleScript is more along the lines of TCL than a shell.
Applescript is comparable to the Bourne shell because like the shell, it gains its strength from the other mechanisms it can invoke. Applescript can be used to create processes and to direct those processes in any arbitrary activity they include in their dictionary - its abilities are open-ended. It's also stronger in terms of what can be done internally by the language itself (the Bourne shell is actually pretty damn weak on its own, even simple math is out of the question). But the real issue here is the ability to invoke other processes external to itself. Hope that clarifies my comment somewhat.
This strikes me as a good thing - if I had a kid, I wouldn't want her watching extremely violent movies without my knowledge, or playing with toy guns without my knowledge. This extends that to interactive "movies" and virtually-held toy guns.
Better still, if enough outlets follow the lead (or legislation ensues) that it becomes difficult to sell violent games to the target market (15 years old, or so), perhaps game makers will actually (gasp) have to go back to making games that are stimulating and interesting, instead of always falling back on a bunch of boring big guns and big explosions. The current crop of shooter games are no different than the lowest-common-denominator action crap that Hollywood spits out - in lieu of real writing or acting, they find a marketable star (in this case a marketable game line) and fill in for plot with flashy violent special effects. One reason there are a *few* half-decent movies without too much violence is the MPAA and equivalent rating schemes, so hopefully this will have a similar effect and encourage game companies to look in other, more interesting directions.
First off, the CNet story is a crock written by a hack with just enough understanding of the subject to screw it up. Par for the CNet course.
There is a valid point made by the people suggesting that this problem is endemic to any software linked to the standard C library, or more specifically to software that abuses the printf() family of functions. This obviously isn't Unix-specific - the locale mechanism just happens to be the exploit that was described.
However, there *is* a gem of truth to the Unix vulnerability idea, and it's rooted in the power of the shell as well as the existence of (and overeliance on) the system(2) call. This is why the US Army moved their web servers from NT to (gasp) the "classic" Mac OS - not just because it offers no network services by default (this can trivially be accomplished on any OS), but because it doesn't have a command-line shell that's easy to exploit (note that I don't agree with their decision and would never deploy the non-Unix Mac OS for any production network server - also note that their assumption isn't even correct, because AppleScript is quite comparable to the Bourne shell and *can* be remotely invoked in some cases).
Part of the problem here is that we have come to rely on models for Unix network software that either need to put strings through the shell (and thus have to deal with baroque quoting issues) or can be tricked into doing so. CGIs are an example of this - it's now obvious that the CGI wasn't a particularly good choice for scalability *or* security. These issues do need to be addressed, so perhaps we can get a modicum of real use out of this latest CNet drivel.
Exactly. But given that it attempts to turn a rather pathetic whimper into a (still very small) bang, you can't blame them.
Well, ok, yes you can - it's noxious spin control that tries to milk goodwill without doing *anything* of value to earn it. Pretty much exactly like Bill Gates emitting tiny burps of cash to M$-friendly charities the day after each instance of particularly absurd and damaging testimony in the DOJ trial.
I'd still prefer to have seen the damn patent overturned. Now it's legally expired and everyone will move in, which actually strengthens the idea of patenting basic algebraic concepts.
Fortunately this press release will probably buy RSA pretty much exactly what it cost them - nothing.
Microsoft does seem to have gone out of their way to avoid the OS's native services in Office (up to and including '98). Thankfully the IE team (apparently largely ex-Claris types) is a bit more open minded. In most cases anyone who would store a path as a text string instead of just calling the Alias manager (requiring much less actual coding as well as the other attendant benefits) is either clueless, or has a political reason to screw up in advance.
Unix is a different environment, with lots of different tradeoffs; you'll find when you've switched to OS X that some things will simply change so much that you won't miss the old behaviour. It's true that there are a few nice things in HFS that will be missed (the ability to almost instantly search for files on a volume with tens of thousands of them, for instance), but there are some pretty cool things in Unix too (like the hardlinks an AC mentioned, and no, there's nothing like them on the Mac - an open file or application can be moved around and renamed, but for different reasons - there's still exactly one pathname per file, not two, not zero (meaning an open file can't be deleted from the directory).
You're right about there being less absolute pathing now that I think of it, though - another reason for that is that there's a parallel namespace for a lot of folders in the System Folder (which can be anywhere because of an HFS feature) and the root of a volume (like the Documents or Applications folders). "spcl-extn" or something like that refers to the Extensions folder, for instance. But I suspect the real reason for that was originally to provide for localisation, because an abstraction layer is required to allow those names to be different in all the locales the OS is sold in. Good layered & abstracted design tends to reap unexpected benefits. But that's another reason not to worry too much about Unix - in terms of well-abstracted OSes, it's still way ahead of the current Mac OS (W2K isn't even a contender).
Actually, there is a special database (the Desktop DB). It's just updated automatically, so most people never need to know about it (especially since it doesn't tend to get corrupted like it used do in the earlier days of System 7). This is possible because of the underlying architectural decision to use unique application "creator" types and filetypes that aren't part of the filename, and the higher-level objects and tools that are built on those concepts (bundle resources etc).
It's also not true that there aren't absolute paths stored - there are. But they're a fallback, and they're not stuck with silly drive letters (or with changeable mount points, which is weakness of absolute symbolic links on Unix): Changes can be repaired automatically because file aliases and "alis" resources store multiple, redundant methods of finding a target, and the Alias Manager tries them successively when one fails. There are open file ID's (somewhat equivalent to inodes), folder IDs in the B*tree (equivalent to pretty much nothing on UFS or ext2fs), volume names, volume partition IDs and device types for when a volume has been renamed, and file names, type/creator info, and yes, paths for when the other methods fail. If something changes and a file can't be found the other methods are used to find it, and when that succeeds the alis resource is updated with the new, fresh information (so the path or whatever was used won't be needed next time and redundancy is restored).
All of this means that I can rename a file and the link doesn't break, because paths aren't the only method or even the first one used - but alternately I can trash a file or an entire application folder (say with an upgraded version of an app) and replace it with one of the same name *in the same path* and the link still doesn't break, even though the old file ID is gone (the path is used to find the new one). Only when all of these tricks are exhausted with no joy do you have to see the "delete/fix manually" dialog. It's a pretty good system, but it's not yet fully clear how some parts of it will work under Mac OS X and on UFS filesystems. NeXT-style app and folder bundles can provide a lot of it, and there was an interesting article by Fred Sanchez linked to from slashdot on the subject a while back.
One of the small hurdles pointed out on the openpackages.org page is the lack of an equivalent utility to FreeBSD's fetch(1) for NetBSD or OpenBSD (or presumably Darwin / Mac OS X). The solution is pretty obvious - port fetch and the small amount of underlying infrastructure - but the benefits will be great.
For the Linux people who haven't tried out FreeBSD yet, fetch is a tool something like wget that takes URLs to retrieve a resource noninteractively. Having a good tool like this can be indispensible for more than just building a package system, and fetch is a very good tool, with useful options and workarounds for lots of cases that come up in retrieving files by FTP or HTTP. I've made use of it elsewhere and solved problems that might have required a C or perl program with just a shell script. Having it on Mac OS X and OpenBSD will be a boon. The only things it doesn't currently do (that I could sometimes use to work around braindamaged web design) is the ability to set the Referer and User-agent header values, as http_get can do. Perhaps those'll be added when it's ported.
Oh yeah, the rest of the unified packaging system will be cool too.;)
Nothing too new in that article save for the commercial aspect, which was arguably inevitable. I'll be more impressed when people start building distributed computing clients into embedded devices that need to be on all the time. Distributed projects aren't about getting fast hardware hooked up, but about getting *huge* numbers of mediocre devices working on little bits of the problem - so things like microwaves and VCRs and even car trip computers could, given a way to connect, out-CPU all the supercomputers in the world. That raises interesting issues of how to pay people back for the use of the electronic gizmos they've bought. Even though I don't always like the leased or licenced (as opposed to owned) approach to buying hardware devices (or software for that matter), it does make a natural fit here, where you could receive a discount on the lease price for the use of a device's spare CPU. Companies that make hardware would probably contract out the actual distributed networking and computing aspects.
That also leads into the other point, about wasting power and generating heat. Some devices really are intended to stay on 24*7 (whether they always really need to or not), so they may as well be recruited for this. Things like SETI@home, on the other hand, strike me as very wasteful - not only will people leave their power-hogging computer on & awake where they might not otherwise, they'll even stop the monitor from sleeping so they can see the "screen saver" display (and here I thought we'd finally gotten over burning power for useless animation). Wasn't there a/. article a short while back on the burgeoning power demands of all our overfast computers in the years to come?
This is why many security features (and certifications, like C2) are really more about bulletproof audit trails than about prevention. You can't prevent abuse of any remotely automated system (this includes noncomputerised systems, as you note), but you can keep track of everything that's done so that the damage can be undone. This works poorly for cases like hospital equipment and space shuttles where the damage is irreversible, but very well indeed for financial stuff (which isn't strictly "real world" anyway, since money is a shared delusion).
Many people look at certifications like C2 and think "what's the point just logging the break-in - shouldn't we prevent it?" These people are usually frontline types (sysadmins who fear an open port, for instance), but there's a lot of security that goes on after the fact, and much of it is done by people in apparently less exciting lines of work (accountants, say;). Indeed one common use of the term "security" pertains to how people will feel about the *next* time even if there is a problem now - if they see that the people in charge of a system can track down the perps and make amends in damn near every case, they'll feel ok even knowing that an abuse is possible.
It's almost enough to convince you to stop choosing the dancing pigs.
This last line of the article is telling. A user of an Internet-connected computer is in possession of a powerful, potentially dangerous tool - maybe it's been long enough that people look at them as some kind of silly toy. On the one hand computing ought to be fun and people shouldn't have to do it in fear (implying they should be given software tools that, though they can never be completely secure, at least aren't braindamagedly insecure). On the other hand they should probably need some bare cognizance of what they're getting into and what they might, through ignorance and negligence, allow someone else to do in the world. Dancing pigs (or penguins) might be cute, but people need to consider that there can be real-world consequences of what they allow to be done to their networked computer.
We tell our kids not to take toys from strangers, but then we go and download and play with the software equivalent without a second thought...
If the idea of patents is supposed to be allowing the innovator to release the specs for their design publicly and still be protected (by the right to litigate, as in this case), why don't companies like Nvidia open their hardware and driver specifications so people can write open-source drivers to an open hardware spec?
The argument that "our competition will steal our secrets" falls apart when they've so clearly patented their designs up the yin-yang and are even more clearly willing to sue over them. Seems like Nvidia wants to have their cake (patent rights) and eat it too (keep their specs closed and proprietary).
The original designers of the idea of patents must be constantly spinning in their graves by now.
Kind of, but FreeBSD's -RELEASE just ends up being a symlink to -STABLE very quickly. Since everything that goes into -STABLE is tested, you wouldn't really want the original released version anyway because you might be missing some important bugfixes and security updates. As someone else mentioned, this is pretty much the same system that Debian has used for its stable branch all along.
Actually it seems that they do just as you suggest for the stable branch, at least to an extent. I know that I've run dselect in the past and had it present a bunch of minor updates to various installed packages, both common and uncommon. And the entire Debian package management system then pursues the dependencies where necessary. I think it's only minor updates that get "folded in" this way, though, otherwise they might break the QA testing on the stable release.
FreeBSD does a similar thing with the -STABLE versions. Someone once noted that each -RELEASE version stays fixed for about fifteen seconds, then it points to -STABLE.
On the other hand, Merriam-Webster specifically mentions automation (meaning, an automaton), and doesn't mention remote control. Pocket Oxford doesn't mention remote control and also wants it to look like a human. Dictionaries differ, none of them is gospel, and very few of them are written by robotics experts. And there's more than one way to shoot off your mouth.;)
More importantly, your definition is too broad - by that standard your VCR is a robot when you tell it to play, rewind and eject a tape. If we extend "complex actions" to include solid-state devices, so are a lot of other things with no ability to run even the simplest program.
The popular definition of robots makes them automatons. Many people will also agree with Oxford that they ought to be human-seeming, though that's changed in the last fifteen years since most people have seen a car-building robot. The remote-control devices in this game show aren't much different from the video representations in an arcade game where you select your player's abilities from a menu and then whack on your opponent with the punch and kick buttons. That doesn't mean it won't be entertaining to watch, though, and it'll probably be popular among the subsection of the teen male crowd that's too proud to watch actual human wrestling.
Slashdot Mirror
Assuming that the identifying factor in the ink really was an amplified portion of someone's DNA, it wouldn't be hard to replicate simply by doing PCR on all the notable strands in the broth. If there's enough for some Olympic "official" to wave a wand over and detect, there's enough to replicate. PCR is not hard - the July 2000 issue of Scientific American has a method by which you can perform it at home with a couple hundred dollars worth of easily-obtained equipment (which they will sell you at cost). If it's worth going to the trouble of sewing in labels to counterfeit this junk clothing, it'll be just as worth brewing up a big batch of ink to spray on (in fact it'll probably be cheaper).
Further assuming they're not full of horse manure with this announcement, why would they use human DNA? Symbolic value? Any sort of plant or animal DNA would have worked, and there are probably other kinds better suited to this sort of application - but it makes a better, more mystically valid-seeming announcement if it's a human athlete.
I suspect they're using some typical glow-in-the-dark chemical ink of the sort that's been in use for at least a decade, and the DNA nonsense is just misdirection. I don't believe the Olympic brownshirts running after street vendors would really have the equipment or clue to test for a particular sequence of human DNA, though they could test for the presence of any DNA (as many other not particularly remarkable chemicals). The existing special inks would probably be harder to replicate, ironically enough, because that's one of their specific design goals.
This is trendy, high-tech seeming hype. Fortunately for the Olympic committee, this clothing and paraphrenalia is destined to have it's valuelessness exposed in a few months anyway, so their "security" measures (including this obfuscation) don't have to hold up for very long anyway.
Personally I'll just watch the Special Olympics, the last bastion of what the modern Olympics were supposed to stand for before T-shirts and $#@$!ing pins took over...
Assuming I didn't go out of my way to ignore advertising of all kinds (which I do) why would I need targeted ads to tell me about things I already know I'm interested in? If I'm interested, I can and will seek things out on my own.
The one thing that ads are potentially good for is in introducing you to something that might be useful and wholly unexpected. I've yet to see how profiling is going to help with this - so far it seems to be more about convincing cola addicts to drink even more cola / a different brand than they already do. Before you can accept that targeted advertising is *good*, you have to accept that advertising in general is good, or at least that it can be. As opposed to being, say, a continuous drain on spending from everyone involved without any real demonstrated benefit. Maybe targeting can fix that, but I'm not holding my breath - it's not even really in Madison Avenue's interest if it does.
Actually, you do have various rights to TV - the airwaves are public property in the US and Canada. You actually bequeath the right to broadcast programs and ads to the TV station, via your elected representatives.
Your point is certainly valid (you don't have a citizenship right to Tivo service), but not as broadly applicable as you suggest.
Well, it's at least innaccurate - the name of the site (and more importantly, it's domain name) is "fuckedcompany.com". An asterisk isn't even legal in a domain name, at that. You can't include a link without spelling it out at least once, so any other munging is pointless at best and hypocritical at worst (if it's not ok to say "fuck", it shouldn't really be ok to link to a page that will sprinkle that term liberally around unless there's a substantial warning of the fact - which is obviously not going to appear on /.). Even if it's only the headline that was munged, as in this case.
/. article (in part *because* of the RDF propagation) should spell it correctly without euphemism. The site (which is quite interesting in concept) *really is* about completely fucked companies, not f*cked ones or fscked ones or mildly addled ones. Sometimes a rose needs to be called a rose. If it's offensive to a site receiving the story via RDF, they should probably just reconsider whether they really want to be associated with slashdot, because it's going to happen in future with far more objectionable content than this.
In this particular case I'd say the
The baseline incidence is an important fact in these issues, and as you imply it's nearly always glossed over in favour of "doubled risk" or some other multiple. But the point made by the growth curve chart on the New Scientist page is that there are 500M cellphone users now, and more in the future. If there are a billion users in two years and an extra 1/100K risk of a lethal tumor, 10,000 people will be killed by their cellphones. That's a lot of preventable human pain and loss.
The real point of these cellphone articles is being consistently lost - we don't know yet because we need good *nonbiased* studies starting now. All of the ones to date have been done either via cellphone industry funding (the vast majority in fact) or by people with an ax to grind. Both of these are equally useful. As you note, the effects are likely to be longterm - if there are real cases happening now it's because those people happened to be the canaries in this coalmine - so the studies will need to be longterm too. It'd be nice to get a leg up on this if it does introduce real danger, instead of waiting 300 years the way we did with tobacco.
The reason it occurs to me that the card companies might want to partially reverse their long practice of not blaming the customer is that (a) these things are going to become more frequent, and especially (b) when this does happen, it happens en masse instead of a single, easily-tracked theft. If 50,000 cards are stolen and used for 50,000 medium-size automated purchases, it could be hard to seek redress. Indeed the paperwork in tracking down all the unauthorised purchases would probably be more expensive for the card company than the actual purchases themselves.
Actually, you can. The Mac DivX player (you can keep the capitalisation straight by noticing it stands for Div[1-4]) actually seems to work by registering the MS-MPEG4.x codecs in Windows Media Player with Quicktime (they're actually present as Quicktime components - "thng" resources - in WiMP already, presumably it uses Quicktime for its display on the Mac, making it basically an interpreter for the proprietary .asf file format).
.asf, though, because Quicktime doesn't know how to read that file format yet. I'm not sure why Captain Stux (author of this Mac DivX hack) didn't just make the codecs contained in WiMP 6.3 into "thng" extension files so they could load as separate QT components - some technical reason perhaps, or just to avoid annoying M$'s lawyers.
That means that you can leave the DivX player running in the background and be able to play MS-MPEG4/DivX encoded AVI files in Quicktime. You can't play
The people snarking about QT player don't understand Quicktime at all, though - it's just a shell, and really has nothing to do with QT except as a cheap way to call the API. Quicktime proper is more akin to an operating system than an application - it can do damn near anything, and it's very elegantly designed. QT player is an abomination, but there are lots of alternatives (including plain old Movieplayer 3.0 or 2.5). Windows might not have any alternates yet, but they wouldn't be hard to write. I expect Apple's QT player will change substantially in its next (pun intended) incarnation to match the Aqua interface anyway.
The Mac DivX player is at http://mac.divx.st/ .
It's not clear if you specifically mean video codecs, and the definition of "come out" might be stretched, but Ogg Vorbis appears to be a very good music codec (even partially completed), and it is open source.
;)
Give this stuff a chance - the real thrust of open source development only reached critical mass a year or two ago (assuming it even has!), and it takes time to develop these scientifically complex projects. The reason we've so far seen Unix reimplementation and catchup work could simply be that those are the relatively easy tasks, as well as representing the infrastructure for future open source work. There just aren't that many people who get into highly refined fields like perceptual encoding, but those who do invariably do it from sheer internal drive, not because they want to get rich quick. Whatever the other arguments for or against open source media codecs might be, I don't think the added financial incentive of propriety is going to be a real issue here. And even if it were, it seems that many companies grok the sell-service-not-software business model and are willing to bankroll the development of new codecs and techniques (Ogg is an example again).
As for the deep scientific angle on codec development, it's often overstated - a lot of successes come from good luck or from treating human subjects as black boxes. The story of how the MPEG-1 layer III algorithm was refined by one engineer listening to Tom's Diner a few hundred times comes to mind.
(grin) I'll certainly plead to the AppleScript part - just enough knowledge to make a mess of my own scripts. As for the Mac OS, however, I wasn't referring to the remote scripting mechanism or to Program Linking, and I should have been more clear. The problem is that applications can themselves originate AppleEvents, and if a web browser or server (say) can be compromised and includes AppleScript invocation as a feature of its own internal scripability, you can compromise the entire OS and not just that one application - it breaks out of its sandbox. I do think this is very comparable to the effects of the system(2) call in Unix.
Applescript is comparable to the Bourne shell because like the shell, it gains its strength from the other mechanisms it can invoke. Applescript can be used to create processes and to direct those processes in any arbitrary activity they include in their dictionary - its abilities are open-ended. It's also stronger in terms of what can be done internally by the language itself (the Bourne shell is actually pretty damn weak on its own, even simple math is out of the question). But the real issue here is the ability to invoke other processes external to itself. Hope that clarifies my comment somewhat.
This strikes me as a good thing - if I had a kid, I wouldn't want her watching extremely violent movies without my knowledge, or playing with toy guns without my knowledge. This extends that to interactive "movies" and virtually-held toy guns.
Better still, if enough outlets follow the lead (or legislation ensues) that it becomes difficult to sell violent games to the target market (15 years old, or so), perhaps game makers will actually (gasp) have to go back to making games that are stimulating and interesting, instead of always falling back on a bunch of boring big guns and big explosions. The current crop of shooter games are no different than the lowest-common-denominator action crap that Hollywood spits out - in lieu of real writing or acting, they find a marketable star (in this case a marketable game line) and fill in for plot with flashy violent special effects. One reason there are a *few* half-decent movies without too much violence is the MPAA and equivalent rating schemes, so hopefully this will have a similar effect and encourage game companies to look in other, more interesting directions.
First off, the CNet story is a crock written by a hack with just enough understanding of the subject to screw it up. Par for the CNet course.
There is a valid point made by the people suggesting that this problem is endemic to any software linked to the standard C library, or more specifically to software that abuses the printf() family of functions. This obviously isn't Unix-specific - the locale mechanism just happens to be the exploit that was described.
However, there *is* a gem of truth to the Unix vulnerability idea, and it's rooted in the power of the shell as well as the existence of (and overeliance on) the system(2) call. This is why the US Army moved their web servers from NT to (gasp) the "classic" Mac OS - not just because it offers no network services by default (this can trivially be accomplished on any OS), but because it doesn't have a command-line shell that's easy to exploit (note that I don't agree with their decision and would never deploy the non-Unix Mac OS for any production network server - also note that their assumption isn't even correct, because AppleScript is quite comparable to the Bourne shell and *can* be remotely invoked in some cases).
Part of the problem here is that we have come to rely on models for Unix network software that either need to put strings through the shell (and thus have to deal with baroque quoting issues) or can be tricked into doing so. CGIs are an example of this - it's now obvious that the CGI wasn't a particularly good choice for scalability *or* security. These issues do need to be addressed, so perhaps we can get a modicum of real use out of this latest CNet drivel.
Exactly. But given that it attempts to turn a rather pathetic whimper into a (still very small) bang, you can't blame them.
Well, ok, yes you can - it's noxious spin control that tries to milk goodwill without doing *anything* of value to earn it. Pretty much exactly like Bill Gates emitting tiny burps of cash to M$-friendly charities the day after each instance of particularly absurd and damaging testimony in the DOJ trial.
I'd still prefer to have seen the damn patent overturned. Now it's legally expired and everyone will move in, which actually strengthens the idea of patenting basic algebraic concepts.
Fortunately this press release will probably buy RSA pretty much exactly what it cost them - nothing.
Microsoft does seem to have gone out of their way to avoid the OS's native services in Office (up to and including '98). Thankfully the IE team (apparently largely ex-Claris types) is a bit more open minded. In most cases anyone who would store a path as a text string instead of just calling the Alias manager (requiring much less actual coding as well as the other attendant benefits) is either clueless, or has a political reason to screw up in advance.
Unix is a different environment, with lots of different tradeoffs; you'll find when you've switched to OS X that some things will simply change so much that you won't miss the old behaviour. It's true that there are a few nice things in HFS that will be missed (the ability to almost instantly search for files on a volume with tens of thousands of them, for instance), but there are some pretty cool things in Unix too (like the hardlinks an AC mentioned, and no, there's nothing like them on the Mac - an open file or application can be moved around and renamed, but for different reasons - there's still exactly one pathname per file, not two, not zero (meaning an open file can't be deleted from the directory).
You're right about there being less absolute pathing now that I think of it, though - another reason for that is that there's a parallel namespace for a lot of folders in the System Folder (which can be anywhere because of an HFS feature) and the root of a volume (like the Documents or Applications folders). "spcl-extn" or something like that refers to the Extensions folder, for instance. But I suspect the real reason for that was originally to provide for localisation, because an abstraction layer is required to allow those names to be different in all the locales the OS is sold in. Good layered & abstracted design tends to reap unexpected benefits. But that's another reason not to worry too much about Unix - in terms of well-abstracted OSes, it's still way ahead of the current Mac OS (W2K isn't even a contender).
Actually, there is a special database (the Desktop DB). It's just updated automatically, so most people never need to know about it (especially since it doesn't tend to get corrupted like it used do in the earlier days of System 7). This is possible because of the underlying architectural decision to use unique application "creator" types and filetypes that aren't part of the filename, and the higher-level objects and tools that are built on those concepts (bundle resources etc).
It's also not true that there aren't absolute paths stored - there are. But they're a fallback, and they're not stuck with silly drive letters (or with changeable mount points, which is weakness of absolute symbolic links on Unix): Changes can be repaired automatically because file aliases and "alis" resources store multiple, redundant methods of finding a target, and the Alias Manager tries them successively when one fails. There are open file ID's (somewhat equivalent to inodes), folder IDs in the B*tree (equivalent to pretty much nothing on UFS or ext2fs), volume names, volume partition IDs and device types for when a volume has been renamed, and file names, type/creator info, and yes, paths for when the other methods fail. If something changes and a file can't be found the other methods are used to find it, and when that succeeds the alis resource is updated with the new, fresh information (so the path or whatever was used won't be needed next time and redundancy is restored).
All of this means that I can rename a file and the link doesn't break, because paths aren't the only method or even the first one used - but alternately I can trash a file or an entire application folder (say with an upgraded version of an app) and replace it with one of the same name *in the same path* and the link still doesn't break, even though the old file ID is gone (the path is used to find the new one). Only when all of these tricks are exhausted with no joy do you have to see the "delete/fix manually" dialog. It's a pretty good system, but it's not yet fully clear how some parts of it will work under Mac OS X and on UFS filesystems. NeXT-style app and folder bundles can provide a lot of it, and there was an interesting article by Fred Sanchez linked to from slashdot on the subject a while back.
One of the small hurdles pointed out on the openpackages.org page is the lack of an equivalent utility to FreeBSD's fetch(1) for NetBSD or OpenBSD (or presumably Darwin / Mac OS X). The solution is pretty obvious - port fetch and the small amount of underlying infrastructure - but the benefits will be great.
;)
For the Linux people who haven't tried out FreeBSD yet, fetch is a tool something like wget that takes URLs to retrieve a resource noninteractively. Having a good tool like this can be indispensible for more than just building a package system, and fetch is a very good tool, with useful options and workarounds for lots of cases that come up in retrieving files by FTP or HTTP. I've made use of it elsewhere and solved problems that might have required a C or perl program with just a shell script. Having it on Mac OS X and OpenBSD will be a boon. The only things it doesn't currently do (that I could sometimes use to work around braindamaged web design) is the ability to set the Referer and User-agent header values, as http_get can do. Perhaps those'll be added when it's ported.
Oh yeah, the rest of the unified packaging system will be cool too.
Nothing too new in that article save for the commercial aspect, which was arguably inevitable. I'll be more impressed when people start building distributed computing clients into embedded devices that need to be on all the time. Distributed projects aren't about getting fast hardware hooked up, but about getting *huge* numbers of mediocre devices working on little bits of the problem - so things like microwaves and VCRs and even car trip computers could, given a way to connect, out-CPU all the supercomputers in the world. That raises interesting issues of how to pay people back for the use of the electronic gizmos they've bought. Even though I don't always like the leased or licenced (as opposed to owned) approach to buying hardware devices (or software for that matter), it does make a natural fit here, where you could receive a discount on the lease price for the use of a device's spare CPU. Companies that make hardware would probably contract out the actual distributed networking and computing aspects.
/. article a short while back on the burgeoning power demands of all our overfast computers in the years to come?
That also leads into the other point, about wasting power and generating heat. Some devices really are intended to stay on 24*7 (whether they always really need to or not), so they may as well be recruited for this. Things like SETI@home, on the other hand, strike me as very wasteful - not only will people leave their power-hogging computer on & awake where they might not otherwise, they'll even stop the monitor from sleeping so they can see the "screen saver" display (and here I thought we'd finally gotten over burning power for useless animation). Wasn't there a
This is why many security features (and certifications, like C2) are really more about bulletproof audit trails than about prevention. You can't prevent abuse of any remotely automated system (this includes noncomputerised systems, as you note), but you can keep track of everything that's done so that the damage can be undone. This works poorly for cases like hospital equipment and space shuttles where the damage is irreversible, but very well indeed for financial stuff (which isn't strictly "real world" anyway, since money is a shared delusion).
;). Indeed one common use of the term "security" pertains to how people will feel about the *next* time even if there is a problem now - if they see that the people in charge of a system can track down the perps and make amends in damn near every case, they'll feel ok even knowing that an abuse is possible.
Many people look at certifications like C2 and think "what's the point just logging the break-in - shouldn't we prevent it?" These people are usually frontline types (sysadmins who fear an open port, for instance), but there's a lot of security that goes on after the fact, and much of it is done by people in apparently less exciting lines of work (accountants, say
This last line of the article is telling. A user of an Internet-connected computer is in possession of a powerful, potentially dangerous tool - maybe it's been long enough that people look at them as some kind of silly toy. On the one hand computing ought to be fun and people shouldn't have to do it in fear (implying they should be given software tools that, though they can never be completely secure, at least aren't braindamagedly insecure). On the other hand they should probably need some bare cognizance of what they're getting into and what they might, through ignorance and negligence, allow someone else to do in the world. Dancing pigs (or penguins) might be cute, but people need to consider that there can be real-world consequences of what they allow to be done to their networked computer.
We tell our kids not to take toys from strangers, but then we go and download and play with the software equivalent without a second thought...
If the idea of patents is supposed to be allowing the innovator to release the specs for their design publicly and still be protected (by the right to litigate, as in this case), why don't companies like Nvidia open their hardware and driver specifications so people can write open-source drivers to an open hardware spec?
The argument that "our competition will steal our secrets" falls apart when they've so clearly patented their designs up the yin-yang and are even more clearly willing to sue over them. Seems like Nvidia wants to have their cake (patent rights) and eat it too (keep their specs closed and proprietary).
The original designers of the idea of patents must be constantly spinning in their graves by now.
Great typo. It seems to me that if you're an Xtian with kids, the more people praying on them, the better.
Hey, keep your innuendo to yourself...not to mention your "sword". Damn Xtians. Go back to Xenu.
Kind of, but FreeBSD's -RELEASE just ends up being a symlink to -STABLE very quickly. Since everything that goes into -STABLE is tested, you wouldn't really want the original released version anyway because you might be missing some important bugfixes and security updates. As someone else mentioned, this is pretty much the same system that Debian has used for its stable branch all along.
Actually it seems that they do just as you suggest for the stable branch, at least to an extent. I know that I've run dselect in the past and had it present a bunch of minor updates to various installed packages, both common and uncommon. And the entire Debian package management system then pursues the dependencies where necessary. I think it's only minor updates that get "folded in" this way, though, otherwise they might break the QA testing on the stable release.
FreeBSD does a similar thing with the -STABLE versions. Someone once noted that each -RELEASE version stays fixed for about fifteen seconds, then it points to -STABLE.
On the other hand, Merriam-Webster specifically mentions automation (meaning, an automaton), and doesn't mention remote control. Pocket Oxford doesn't mention remote control and also wants it to look like a human. Dictionaries differ, none of them is gospel, and very few of them are written by robotics experts. And there's more than one way to shoot off your mouth. ;)
More importantly, your definition is too broad - by that standard your VCR is a robot when you tell it to play, rewind and eject a tape. If we extend "complex actions" to include solid-state devices, so are a lot of other things with no ability to run even the simplest program.
The popular definition of robots makes them automatons. Many people will also agree with Oxford that they ought to be human-seeming, though that's changed in the last fifteen years since most people have seen a car-building robot. The remote-control devices in this game show aren't much different from the video representations in an arcade game where you select your player's abilities from a menu and then whack on your opponent with the punch and kick buttons. That doesn't mean it won't be entertaining to watch, though, and it'll probably be popular among the subsection of the teen male crowd that's too proud to watch actual human wrestling.