Inserting data into OSM which came from a copyrighted source is definitely a no-no (unless that source explicitly gave permission, which has happened in several cases).
If you find some data in OSM which you think looks suspicious, there's a procedure to report it.
Quite often it's down to ignorance, rather than malicious intent, where a new mapper doesn't realise that the map they're copying from is either copyrighted or under a licence which prohibits derivative works.
You've probably just got lucky - commercial data is ahead of OSM in terms of addressing, however you will find errors in pretty much every country (roads that aren't there, roads with the wrong name, roads in the wrong place, etc).
If (when:-) you do find an error, please check it out on OSM and see what it looks like there - if it's wrong in OSM, you can at least fix it.:-)
The map tiles are certainly Apple's own - they have defined their own stylesheet, with their own look.
However the map data those tiles were rendered from appears to be a mix of TIGER in the US and OSM elsewhere. TIGER is a public domain dataset from the US Census Bureau, and OSM is CC-BY-SA.
Looking at the shape of the data is often enough to tell you where it came from. One one level it's modelling the same reality, but in practice mappers tend to make slightly different versions of "the same" object (a road might be smoothly curved, or quite angular, depending on how much effort they went to). As such you can quite easily see when data comes from the same source, even if it's rendered in a different style.
It's pretty conclusively OSM if you look at which small features (footpaths, lanes within a car park, etc) are rendered. This data isn't present in the commercial datasets you can licence from people like TomTom, however it is in OSM (neither Navteq nor TeleAtlas have footpaths, or this kind of micro-mapping of lanes within parking areas).
Based on things like this, typos which appear on both maps, and roads that are in OSM now but aren't in Apple's tiles - it looks pretty clear that they used a snapshot of OSM, specifically one from early April 2010.
GPS devices normally have much worse vertical accuracy than horizontal, unless they have a barometric altimeter.
OSM's database currently just holds latitude and longitude for objects, and you can tag things with a z-level to indicate when something is over or under something else. For 99.99% of objects, that's perfectly fine and sufficient for topological modelling (if you mean topological in the sense of the connections between objects, so that you can calculate a route from A-B-C-D).
For some objects a specific altitude might be worth recording, and since OSM uses an arbitrary key=value store for data you can easily record the altitude for a point if you think it's useful (you might want to record the elevation of a mountain peak, but you probably don't want to record the altitude of a post office or public toilet).
Using a key-value store means OSM has an inclusive data model; you can store whatever data you think might be useful, within reason.
It is not yet under ODbL - the licence changeover is planned for the 1st April 2012 (however Apple appear to be using data from circa 2010, which was definitely under CC-BY-SA).
In practice the problem you see (ambiguities in the endgame) are only really an issue for computer Go. Human players rarely disagree over when a game is "over", as typically the outcome becomes obvious long before each stone is played out to the absolute end.
Perhaps a good analogy is poetry: it is perfectly possible for a poem to convey meaning, even if it does not conform to the rules of the language or have a literal meaning (and yet, people still understand it).
The thick book of "how to interpret patterns" is simply a set of standard plays that people have found empirically to work well (in exactly the same way as opening books are used in chess). Like chess, you are free to ignore those patterns if you like, but typically that leaves you in a weaker position than you would be in otherwise.
These patterns are most commonly used in the opening moves, but local instances of them pop up all the time ("if he moves there, I should move here, then he *has* to move there I'll capture these stones").
The rule is that game is over when both players agree that it is over: if there is a disagreement, the game is played on. Some positions lead to an infinite repeat (A captures B, B captures A, A captures B, etc) but thee plays typically don't determine the final score (if the score was equal, and there was an infinite repeat, then humans would simply call it a draw). Computers can recognise trivial cases of this easily, and do OKish with heuristics for simple cases.
However the real difficulty in computer Go is understanding just why humans make the moves they do, as outside of the standard sequences a move is often made intuitively as a way to steer the other player even though the consequences of that move may be some way off (or may need to be abandoned, or redirected, or reused in some unplanned way).
Go is a truly fascinating game, and also a very human one (computers will play it well one day, but probably about the same time that they get good at writing poems, playing tricks, or asking why).
Has Metrowerks suddenly developed an allergy to generating x86 code? I doubt it.
Pretty much - they sold their x86 tools to Nokia a month or so before WWDC, and that type of transfer typically includes a "you don't get to claw it back later" clause. Which I guess would have been a reasonable thing to agree to at the time, as what are the chances Apple are going to switch to x86...
Based on the little evidence I have been given, I see no legal stance from Apple that will hold up in court.
You might want to scroll down a little from the line you quoted, where you'll see:
"California is one of approximately 44 or 45 states that have adopted [the] Uniform Trade Secrets Act. That statute makes it wrongful to acquire or publish without authorization information you know or have a reasonable basis to know is a trade secret of another"
That may or may not be enough in this case, but they're hardly likely to take the decision to spend hundreds of thousands of $ in court if they're not fairly sure they're on solid ground.
Granted Ciarelli can hardly hope to outspend them, but I doubt they care about bankrupting him - they want him to give up names, as that's the most efficient way to stop future leaks (would you leak info to a rumour site in the future if you knew Apple can and will get your name out of them eventually?).
Wrong. It will rip existing MP3 files to that format. Downloaded files from the ITunes site are MP4 DRM'd, period.
Wrong. They're DRM'd until you burn them onto an audio CD - you can then rip them again to whatever format you like.
Yyou can't burn the same playlist more than 10 times, but of course if you're going to re-rip then you can burn your re-ripped copies as often as you'd like since they're just plain MP3/AAC files.
That refutation is based on a quote from Alastair Campbell, who's the U.K. equivalent of Ari Fleischer - perhaps not the most independent of sources...
Often the data I'm working on is tough to just look at to see if it's right; being able to write something that would plug into the debugger to display some data would be cool.
This is one of the features in CodeWarrior 8 (at least in the Mac versions, and presumably the Windows version too). You can describe how the data should be organised so that the debugger can view it sensibly (e.g., where to find the string data in a std::string or that a CFloatRect is 4 floats), or write a plug-in to display it using your own code.
E.g., you could display an image as a square of RGB data and a square of alpha data - or as individual color planes, or whatever you like.
There was also a Mac tool a couple of years ago called General Edit (not by Metrowerks), although not a debugger as such - you type in a templated description of what your data looks like (with nested definitions, fields that rely on other fields, etc) and it pops up a structured view of the data. Very useful for poking around in data that normally you'd be trying to interpret with a hex editor, as you could tweak your decoding description until you had it right.
/System/Library/Frameworks/OpenGL.framework is only 5.2Mb (4.4Mb when compressed). Even if the entire bundle changed, that's not a huge chunk of the download.
Re:The Finder still needs work
on
Is Mac OS X Slow?
·
· Score: 3, Insightful
The biggest problem with the OS X finder is that is was programmed in Carbon, and not Cocoa.
The idea that Carbon is somehow slower or less efficient than Cocoa is a fiction - two of the slowest apps Apple have ever shipped (iPhoto and iCal) are Cocoa. It's frankly emabarassing that the Mac OS X 10.2 Calculator app (Cocoa) can't keep up with me typing "12345" on a 500Mhz G4.
I hope Apple makes a cocoa version soon.
There would be absolutely no point in rewriting the Finder in Cocoa, other than politics. The original Mac OS X 10.0 Finder threw away a lot of the subtelties that had built up over the years in the Mac OS 9 Finder, and starting from scratch again would undoutably have similar effects (for no real gain: the Finder has improved significantly since in 10.2 over 10.0).
By rootless he means connecting to a remote 'window" rather than a display (i.e., so you can run a session which just displays a remote Word document, rather than the entire desktop).
This crops up periodically on the vnc list, but it doesn't look like there's an easy way to implement it (at least for Windows, and certainly for the Mac where applications tend not to live inside a single window - not to mention the menu bar). There's no support in the current VNC protocol for resizing the remote framebuffer without re-establishing the connection, so just resizing a window would also mean dropping the connection and reconnecting.
What VNCThing has (I'm the author:-) is a full screen mode, where it hides your local windows/menubar and displays the remote desktop full screen (as if you had a monitor switch rigged up).
-dair (note this is a bit buggy in the current release, but an update is on its way)
The cursor doesn't modify itself, however its mask is one pixel thicker than the image - to give you a white border around the black arrow.
The border is invisible when you're over something white like a window's contents, but lets you pick out the black interior of the cursor when you mouse over something darker.
If you use a black border around a white interior, moving the cursor over a black background will make it seem to shrink slightly - the border will vanish, and you'll be left with just the interior. Doing it the other way round means the cursor always has the same appearance.
My understanding that Carbon apps contain enough legacy code that recompiling wouldn't be an option.
That's incorrect - the whole point of the Carbon exercise was to remove legacy code. It was derived from the QuickTime for Windows project, and there's nothing PPC-specific about the Carbon APIs.
The biggest problem, for either Cocoa or Carbon apps, would be to handle endian swapping - it will become less of a problem as more people use XML for their pref files, but a lot of existing code will assume structures on disk have the same layout as structures in memory (which won't hold if files were generated on a different platform).
This probably would affect Carbon code more than Cocoa code, primarily because there's a lot more Carbon code around. However this wouldn't be such a big problem for developers who already use cross-platform file formats (Photoshop, Word, etc)
it's the whole yellow box v. blue box thing.
Yellow Box was the old name for Cocoa, and Blue Box was the old name for Classic - those names date from before Carbon was even an option.
-dair (although blue box still lives as the "TruBlue" process that runs Classic)
The $20 charge was only for people who've bought new hardware recently (possibly from today until the release). Everyone else will be paying full price, at least going by what was said today.
Slashdot Mirror
Inserting data into OSM which came from a copyrighted source is definitely a no-no (unless that source explicitly gave permission, which has happened in several cases).
If you find some data in OSM which you think looks suspicious, there's a procedure to report it.
Quite often it's down to ignorance, rather than malicious intent, where a new mapper doesn't realise that the map they're copying from is either copyrighted or under a licence which prohibits derivative works.
This has been hashed out endlessly on the OSM mailing lists, and yours is definitely a minority viewpoint.
You've probably just got lucky - commercial data is ahead of OSM in terms of addressing, however you will find errors in pretty much every country (roads that aren't there, roads with the wrong name, roads in the wrong place, etc).
If (when :-) you do find an error, please check it out on OSM and see what it looks like there - if it's wrong in OSM, you can at least fix it. :-)
The map tiles are certainly Apple's own - they have defined their own stylesheet, with their own look.
However the map data those tiles were rendered from appears to be a mix of TIGER in the US and OSM elsewhere. TIGER is a public domain dataset from the US Census Bureau, and OSM is CC-BY-SA.
Looking at the shape of the data is often enough to tell you where it came from. One one level it's modelling the same reality, but in practice mappers tend to make slightly different versions of "the same" object (a road might be smoothly curved, or quite angular, depending on how much effort they went to). As such you can quite easily see when data comes from the same source, even if it's rendered in a different style.
It's pretty conclusively OSM if you look at which small features (footpaths, lanes within a car park, etc) are rendered. This data isn't present in the commercial datasets you can licence from people like TomTom, however it is in OSM (neither Navteq nor TeleAtlas have footpaths, or this kind of micro-mapping of lanes within parking areas).
Based on things like this, typos which appear on both maps, and roads that are in OSM now but aren't in Apple's tiles - it looks pretty clear that they used a snapshot of OSM, specifically one from early April 2010.
GPS devices normally have much worse vertical accuracy than horizontal, unless they have a barometric altimeter.
OSM's database currently just holds latitude and longitude for objects, and you can tag things with a z-level to indicate when something is over or under something else. For 99.99% of objects, that's perfectly fine and sufficient for topological modelling (if you mean topological in the sense of the connections between objects, so that you can calculate a route from A-B-C-D).
For some objects a specific altitude might be worth recording, and since OSM uses an arbitrary key=value store for data you can easily record the altitude for a point if you think it's useful (you might want to record the elevation of a mountain peak, but you probably don't want to record the altitude of a post office or public toilet).
Using a key-value store means OSM has an inclusive data model; you can store whatever data you think might be useful, within reason.
It is not yet under ODbL - the licence changeover is planned for the 1st April 2012 (however Apple appear to be using data from circa 2010, which was definitely under CC-BY-SA).
In practice the problem you see (ambiguities in the endgame) are only really an issue for computer Go. Human players rarely disagree over when a game is "over", as typically the outcome becomes obvious long before each stone is played out to the absolute end.
Perhaps a good analogy is poetry: it is perfectly possible for a poem to convey meaning, even if it does not conform to the rules of the language or have a literal meaning (and yet, people still understand it).
The thick book of "how to interpret patterns" is simply a set of standard plays that people have found empirically to work well (in exactly the same way as opening books are used in chess). Like chess, you are free to ignore those patterns if you like, but typically that leaves you in a weaker position than you would be in otherwise.
These patterns are most commonly used in the opening moves, but local instances of them pop up all the time ("if he moves there, I should move here, then he *has* to move there I'll capture these stones").
The rule is that game is over when both players agree that it is over: if there is a disagreement, the game is played on. Some positions lead to an infinite repeat (A captures B, B captures A, A captures B, etc) but thee plays typically don't determine the final score (if the score was equal, and there was an infinite repeat, then humans would simply call it a draw). Computers can recognise trivial cases of this easily, and do OKish with heuristics for simple cases.
However the real difficulty in computer Go is understanding just why humans make the moves they do, as outside of the standard sequences a move is often made intuitively as a way to steer the other player even though the consequences of that move may be some way off (or may need to be abandoned, or redirected, or reused in some unplanned way).
Go is a truly fascinating game, and also a very human one (computers will play it well one day, but probably about the same time that they get good at writing poems, playing tricks, or asking why).
young'in.
Get the hell off my lawn!
Has Metrowerks suddenly developed an allergy to generating x86 code? I doubt it.
Pretty much - they sold their x86 tools to Nokia a month or so before WWDC, and that type of transfer typically includes a "you don't get to claw it back later" clause. Which I guess would have been a reasonable thing to agree to at the time, as what are the chances Apple are going to switch to x86...
Get in line people, get in line...
What does being British have to do with Battlestar Galactica, seeing Battlestar Galactica, or the show being a fantastic show? Did I miss something?
For once the UK has been showing a series ahead of the US - Battlestar Galactica finished over here a couple of weeks ago.
"California is one of approximately 44 or 45 states that have adopted [the] Uniform Trade Secrets Act. That statute makes it wrongful to acquire or publish without authorization information you know or have a reasonable basis to know is a trade secret of another"
That may or may not be enough in this case, but they're hardly likely to take the decision to spend hundreds of thousands of $ in court if they're not fairly sure they're on solid ground.
Granted Ciarelli can hardly hope to outspend them, but I doubt they care about bankrupting him - they want him to give up names, as that's the most efficient way to stop future leaks (would you leak info to a rumour site in the future if you knew Apple can and will get your name out of them eventually?).
Not quite, that's just a normal Finder window.
A file open dialog is one of these (displaying list view: the 4th widget from the left will toggle it into column view).
Wrong. It will rip existing MP3 files to that format. Downloaded files from the ITunes site are MP4 DRM'd, period.
Wrong. They're DRM'd until you burn them onto an audio CD - you can then rip them again to whatever format you like.
Yyou can't burn the same playlist more than 10 times, but of course if you're going to re-rip then you can burn your re-ripped copies as often as you'd like since they're just plain MP3/AAC files.
-dair
That refutation is based on a quote from Alastair Campbell, who's the U.K. equivalent of Ari Fleischer - perhaps not the most independent of sources...
Often the data I'm working on is tough to just look at to see if it's right; being able to write something that would plug into the debugger to display some data would be cool.
This is one of the features in CodeWarrior 8 (at least in the Mac versions, and presumably the Windows version too). You can describe how the data should be organised so that the debugger can view it sensibly (e.g., where to find the string data in a std::string or that a CFloatRect is 4 floats), or write a plug-in to display it using your own code.
E.g., you could display an image as a square of RGB data and a square of alpha data - or as individual color planes, or whatever you like.
There was also a Mac tool a couple of years ago called General Edit (not by Metrowerks), although not a debugger as such - you type in a templated description of what your data looks like (with nested definitions, fields that rely on other fields, etc) and it pops up a structured view of the data. Very useful for poking around in data that normally you'd be trying to interpret with a hex editor, as you could tweak your decoding description until you had it right.
-dair
OpenGL 1.4!!!! That's why it's a 51 meg download.
/System/Library/Frameworks/OpenGL.framework is only 5.2Mb (4.4Mb when compressed). Even if the entire bundle changed, that's not a huge chunk of the download.
That's "Sinclair" - no e.
-dair
The biggest problem with the OS X finder is that is was programmed in Carbon, and not Cocoa.
The idea that Carbon is somehow slower or less efficient than Cocoa is a fiction - two of the slowest apps Apple have ever shipped (iPhoto and iCal) are Cocoa. It's frankly emabarassing that the Mac OS X 10.2 Calculator app (Cocoa) can't keep up with me typing "12345" on a 500Mhz G4.
I hope Apple makes a cocoa version soon.
There would be absolutely no point in rewriting the Finder in Cocoa, other than politics. The original Mac OS X 10.0 Finder threw away a lot of the subtelties that had built up over the years in the Mac OS 9 Finder, and starting from scratch again would undoutably have similar effects (for no real gain: the Finder has improved significantly since in 10.2 over 10.0).
-dair
One of them at least, Damon Wright, has a weblog.
-dair
By rootless he means connecting to a remote 'window" rather than a display (i.e., so you can run a session which just displays a remote Word document, rather than the entire desktop).
:-) is a full screen mode, where it hides your local windows/menubar and displays the remote desktop full screen (as if you had a monitor switch rigged up).
This crops up periodically on the vnc list, but it doesn't look like there's an easy way to implement it (at least for Windows, and certainly for the Mac where applications tend not to live inside a single window - not to mention the menu bar). There's no support in the current VNC protocol for resizing the remote framebuffer without re-establishing the connection, so just resizing a window would also mean dropping the connection and reconnecting.
What VNCThing has (I'm the author
-dair (note this is a bit buggy in the current release, but an update is on its way)
The cursor doesn't modify itself, however its mask is one pixel thicker than the image - to give you a white border around the black arrow.
The border is invisible when you're over something white like a window's contents, but lets you pick out the black interior of the cursor when you mouse over something darker.
If you use a black border around a white interior, moving the cursor over a black background will make it seem to shrink slightly - the border will vanish, and you'll be left with just the interior. Doing it the other way round means the cursor always has the same appearance.
-dair
My understanding that Carbon apps contain enough legacy code that recompiling wouldn't be an option.
That's incorrect - the whole point of the Carbon exercise was to remove legacy code. It was derived from the QuickTime for Windows project, and there's nothing PPC-specific about the Carbon APIs.
The biggest problem, for either Cocoa or Carbon apps, would be to handle endian swapping - it will become less of a problem as more people use XML for their pref files, but a lot of existing code will assume structures on disk have the same layout as structures in memory (which won't hold if files were generated on a different platform).
This probably would affect Carbon code more than Cocoa code, primarily because there's a lot more Carbon code around. However this wouldn't be such a big problem for developers who already use cross-platform file formats (Photoshop, Word, etc)
it's the whole yellow box v. blue box thing.
Yellow Box was the old name for Cocoa, and Blue Box was the old name for Classic - those names date from before Carbon was even an option.
-dair (although blue box still lives as the "TruBlue" process that runs Classic)
The 6 pin connector is found on Macs and the iPod, and uses 2 pins for power (the iPod can be charged while it's syncing with a Mac).
The 4 pin connector is a different shape, doesn't have the two power pins, and is normally what you see on camcorders (and I guess some PCs).
-dair
The $20 charge was only for people who've bought new hardware recently (possibly from today until the release). Everyone else will be paying full price, at least going by what was said today.
-dair