Sorry for being US centric in that last post... I can definitely see helping them in non-US areas.
As for US areas, I am baffled that they have no data for anywhere in my area (30 minutes from NYC in a major suburb) - well, to be truthful, they have an outline of the geography (land and water boundary line) - but thats it... especially since it is free, and doesnt take too long (for them) to import all 70GB of it into a database... for us to feed the data through their web server would take months...
So, for the US, my answer stays mostly the same... they need a base data set first before they can ask for help fixing it... and no one has taken the effort to download and import the quite very free data set for the US. So, to truly help them, would mean someone should grab all the (free) US data and upload it for them... how long does it take to send 70GB through a bunch of web scripts? I wonder... ok, nevermind... they should handle that part themselves I guess...;-)
The THEORY (ie: not mine, and dont know or care how valid it is) is that if the map data was accurate, bad people could pinpoint an exact location to within 13" +/- a few inches to do bad things, like use their imaginary WMDs to to pinpoint bombing - and (my guess) also to make the average citizen feel slightly more anonymous since the locations on the map dont actually correspond to their real location in the real world (most people wont make the connection you made - that the directions and location info will still put you within a few houses or so of their real location).
I'm not disagreeing with you - just pointing out what is *claimed* by those who compile the data (which is NOT me:-) I just USE the data... ).
The geographic portion though (street centroids, intersection *locations* (and types), town/city/county boundaries, waterways, etc) is supposed to be near 100% accurate to within those 6 decimal degrees of longitude and latitude.
Actually, Google seems to get their data from a variety of sources, NavTeq being one of them... trying out different zoom levels and different locations will show you different "contributors" for the data that Google uses.
For instance, try New York, NY... you will see the copyright statement says "Google Imagery, NASA, TerraMetrics, MapData & NavTeq" - other areas will have one or more of those and/or others that arent in that list...
As for the innaccuracies, I doubt they are by Google's or NavTeq's or TeleAtlas' design... just simply by the fact that the US Government decided upon including that innaccuracy, and the source data it all comes from is theirs (the govt's)... I just think it is all that is available for those companies to work with (at least when it comes to nearly complete data sets).
Hi... it's not quite that simple. Here is how the data works... let's assume you live on a straight street...
The data has StartLong, StartLat -> EndLong, EndLat and corresponding StartHouseLeft, EndHouseLeft, StartHouseRight, EndHouseRight for that segment (which may or may not be your whole street - depends on whether the street curves somewhere, or is intersected by other streets, etc). Google, Tele, Nav, etc take what address you enter, and interpolate it based off that data so...
If the data set says your street starts at #0 and goes to house #40 and yours is house #20, it interpolates your address to be dead center on the segment and calculates that lat/long point based off that... but... what if half the houses on your street have 150' frontages, while the other half have 80'? Well, then the data is innaccurate... or what if (which seems to be the standard) the data starts your street at 1, but your street actually starts at 14? (Mine is exactly like that... so the whole first segment is highly innacurate). And the segment data dont take into account the WIDTH of interesections... so segment one (when it hits an intersection) ends in the middle of it. Segment two starts at that exact point. If the intersecting road is a rural or suburban local road, it may be 30-40' across... if it is a highway, it may be a couple hundred feet across (depending on median size, # of lanes, etc). That also makes all data even more innacurate (because the start address gets located on the highway - as the corner is represented by a point intersection instead of by a 2D road and highway width intersection.
So, no, there is no way way to fix it - because even though the data does say what type of road each segment is, that still wont tell you how wide the road (or any median on it) is. For instance, Interstates in the middle of no-where are often 2 lanes each direction... or in Norther Jersey, hit 6 or 7 lanes each direction... they both show up as the same road type.
True... though they dont hide it, it just isnt acurate, even though the information is stored in 6 decimal places...
And as for the gang checking out our site, you will find only one difference in the data compared to Google's - I dont adjust it to the left or right to make it pretty... the Tiger-Line Data specifies road direction, and whether the address is on the "left" or "right" (ie: if the road segment goes north, left addresses are on the west side). Google takes the exact same results, and moves them a couple pixels or fraction of degrees (amount determined by returned map size) tangential to the road in the appropriate direction... I may do that one day... but for now, the data I return is dead center in the middle of the road (by "choice" ie: too lazy to care at the moment - when I put up the mapping component, I will "fix" that).
Enjoy! Take the latitude and longitude, put a , between them, and drop em in Google Maps... compare that to the address you entered on my site, and you'll find that other than moving it "left" or "right" (as the data set describes it), it is otherwise identical...
There IS a reason why Google's (and everyone else's) data is incorrect. I'm wondering if Google got their data directly, or wasted money paying for it from TeleAtlas or NavTeq or one of the other companies that gets it for free...
The US Tiger-Line Data it is based off of (SAME errors in data - I know, I've got the whole Tiger-Line set to use for comparison) clearly states in the massive 369 page "Technical Document" (well I think 369 pages is kinda large) that the data is purposefully innaccurate to ensure that it cannot be used to pinpoint the exact location of any residence to help ensure some level of privacy for each citizen.
By allowing users to correct the information, it also means the interpolative data for other addresses becomes accurate or more accurate... for instance, if my neighbor corrects his location pointer, and you look addresses on the street, even if his is in the database as an exception rule, you can easily spot the exception and re-plot the rest of the data.
For reasons of National Security (second reason cited in the Tiger-Line Docs), that also can be bad, because figuring out a pretty near exact location of sensitive areas just requires someone(s) who live on each side to correct their info.
Especially considering the data set works with 6 decimal places of latitude or longitude precision (which is about 13" give or take for most US locations... in Alaska it is far more accurate on the longitude portion at 6 decimal places)...
I'm still up in the air as to whether this ends up being a good thing or a bad thing...
I've checked out both the stuff for and against MS's DRM in Vista... I've yet to come up with too much of a definitive opinion on it.
I do know, that in testing WMP11, and disabling all of the "Talk to MS" features and "Check my Media" options, and it went right ahead and started scanning all my drives AND talking to something on the Internet anyway (even closing it didnt stop it - had to restart).
Now, maybe that's because it's an earlier WMP11 release that hasnt been updated (and is something they resolved)...
But what scares me more in the DRM and invasiveness options are their recent patents indicating intent to watch every file created on the OS or through their products to be able to serve ads...
Then of course, there's the delay in many activities that many have speculated are due to the DRM (copying images and music, playing music or videos and accessing a network, etc).
So, the jury's out still (for me) on that... but I am leaning towards seriously wondering what nightmares may soon be enabled in the OS in the lines of DRM and ad serving.
Oh well, time will tell... as for the rest, I think we're in total agreement:-)
You make very valid points - I wish the rest of the computer illiterate world understood them.
I think that understanding is severely hampered because the RIAA is going all out to try to equate file sharing apps with illegal sharing - period (as in that is ALL they are for). Since most people have no idea what BitTorrent or other P2P apps are, and all they see in the press is that they are used for illegal file sharing, the general public (which includes many computer/technology illiterate judges, jurors and journalists) believe them.
I think until public perceptions on the matter are not driven by the RIAA, things wont change nearly as fast as they need to - which is why this battle is so important - because the only leash to prevent new laws outlawing P2P software and many other technologies are currently things like the FSF... so again, in total agreement with you...
I am on the production team for Star Trek New Voyages and we use BitTorrent to legally release virtually all of our episodes. We have had something approaching 50 million or 60 million downloads so far. I for one have no idea how, an entirely volunteer effort, relying on others to help us distribute the episodes, and our own money to fund production and our own site, could ever manage to afford to deliver our episodes to that many people without something like BitTorrent (or one of us to hit the jackpot - which hasnt happened).
(Thus we have) a perfectly legal, legitimate, large scale use of P2P software - that the RIAA demonizes and wants to make illegal. One of only many examples.
I'm all for this battle and the FSF's involvement... because if the RIAA gets their way, we (and many other legitimate companies) will have crippled, costly distribution methods.
If I had MOD points, I'd mod you up as high as it would let me... (which is I guess only +1 more);-)
Hey... sorry if I seemed sarcastic (or like I was screaming - I was actually emphasizing)... too many trolls, and I guess I am getting too jaded?:-)
Why it got modded +5 Insightful, I dont know... but then again, I dont mod my own posts...;-)
As for the rest, I think that my idea of serious issues may be different than yours... or I didnt clearly state those issues...
Some is definitely code related... (some of the ones that *I* think are major - which you or others may not are, for instance, the extensive DRM, and the broken promises that many businesses were looking forward to as a reason for adopting Vista).
The other thing I thought was weird (and I made a comment saying it "seemed like" MS looked at the code and....) was that the SP1 team hugely underestimated the time they needed. That wasn't supposed to be taken as *my* opinion on the code... just what it seemed they were acting like based off the release date the SP1 Team originally talked about having changed so drastically.
.
The rest of the "serious issues" I have, are more in line with how it will affect their current and future goals... the longer it takes (or the longer it slips back) to release SP1, the less likely businesses will adopt it (and more likely they will wait for "Windows 7"). I see that as a serious issue for them... yeah, they have money... but it means the money they spent is largely wasted on that entire segment (upgrades)... and then what? Will the businesses decide to wait for a few months to see how "Windows 7" performs and/or decide/need to wait for "Windows 7"s first Service Pack? With stepping up their release cycle, Vista needs to be "perfect" now if they want a greater adoption of it before "Windows 7" (yeah, I know it cant ever be perfect - nor can any OS - that is why it's in quotes...). With the stepped up release cycle, "Windows 7" needs to work well enough on release as well for adoption of it - which STILL may not help as companies have "learned" to either wait for the first Service Pack or for a few months to see if the OS needs it (whether they are right or wrong in the case of "Windows 7" to me is irrelevant... that they are likely to wait - especially with a faster release cycle - can also be harmful to MS). When does the cycle end? Surely not when an OS requires a Service Pack to fix big issues right out the door, and surely not when that Service Pack takes over a year (from the Nov release) to put out, and surely not when they are trying to step up their release schedule so aggressively (compared to their last release... namely XP ->Vista - and the large delays and dropped features).
There had been *no* official publicly announced release dates, until possibly this one [windowsvistablog.com], and even that's dubious. Internet news services desperate for scoops are not official announcements.
The issues raised are hardly evidence of the serious flaws you implied.
So, what you are saying is this:
-MS is trying to push businesses (and home XP users) to upgrade to Vista - which isnt happening in nearly the numbers they want.
-MS will not be releasing SP1 till 1 year after Vista release (longer if you count the business GA release in Nov 2006), even though it is needed to address many issues that are preventing businesses from adopting Vista
-MS *has* announced SP1 would be ready sooner - that it wasnt an "official public" announcement is just indicative of the fact that the very team who is working on SP1 severely underestimated the time it would take to complete it (that isnt an issue? if a mechanic told you fixing your car would take a week, then told you it would take 2 and a half weeks, you wouldnt be upset - or wondering what else he found that was wrong with it?)
-MS has announced a release strategy for "Windows 7" that means in order for them to stay viable in the marketplace (ie: get more sales/adoption of Vista) requires that Vista is "adoptable" by their customers who wont touch it... thus the later the release date for SP1 (assuming, and thus giving MS a very big benefit of lots of doubt that SP1 fixes everything)... so the later SP1 is, the more likely those customers they want to switch to Vista will decide not to, and instead wait for "Windows 7"
-The fact that key issues (invasive DRM, lack of many of the wanted - but dropped Vista features, no easy business licensing path/key server setup like with certain business releases of XP/Server2003) are still not being addressed, even with the time extension from the SP1 team's original estimate, is also going to hamper adoption of Vista.
So, none of those are serious flaws? For me? No... for MS's plans of increased Vista adoption, most definitely. For businesses and consumers who need to wait a year (or more) for the SP? Probably.
I think that our definition of "serious flaws" (and I am including their "business model" in that "equation") is just quite different... and that's fine.
1. The zdnet blog my Mary Jo Foley says there will be a TAP preview of SP1 in 2nd half of 2007 -- this was shipped recently. It said nothing about the release date of SP1. Check the article, and the links in it!
You obviously need to re-read the article. Here, let me quote it for you - and the text from the link you mention:
After lots of wavering, Microsoft has finally made the due date for Windows Vista Service Pack 1 (SP1) official: The update will ship in the latter half of 2007.
(Microsoft didn't issue a press release with that pronouncement. Instead, it notified its Technology Adoption Partner testers of it via an e-mail regarding the imminent start of the Vista SP1 testing program.)
The second half 2007 date won't be too surprising to folks who believed Microsoft Server and Tools chief Bob Muglia, who confirmed reports that Vista SP1 would be timed to hit with Longhorn Server, another Microsoft product due in the latter half of 2007.
It says *SP1* will be released. It says that the ****ANNOUNCEMENT**** was sent to it's "TAP testers" It says none of the nonsense you mention.
Here's the second quote - from that very announcement (linked to by Mary Jo):
Brief Summary
Windows Vista Service Pack 1 (SP1) will be a standard service pack that will include security updates, hotfixes, as well as limited other changes focused on improving quality.
The Technology Adoption Program (TAP) is looking for customers and partners actively test and provide feedback on Windows Vista SP1 to help us prepare for its release in the second half of CY07. Customers must be willing to provide feedback and deploy pre-release builds into production environments.
I have BOLDED the appropriate line. It QUITE CLEARLY states, in discussing SP1, in preparation for its RELEASE in second half of CY07. It then goes on to mention that TAP testers can download the betas before then - which is what the whole email from MS was about - "Please download the betas and help us test them so we can release SP1 to the public by second half CY07"
It's all there - you just seem intent on misreading it - or havent had enough coffee... and as I have had those days (not enough coffee - which today isnt such a day), I will give you the benefit of doubt and allow you to have the chance of re-reading them before I assume you are a troll.
I don't remember MS making any claims about Release dates for SP1.
I haven't any signs of "bad programming decisions" in Vista. Of all the technical documentation and blog posts read the view is one of significant advancement in the underlying API's and architecture. But maybe if I was looking at this completely uninformed and ignorant, I might also come to some FUD conclusion.
Or you might do a Google Search before you claim I am wrong (re: release dates - see my other reply to another MS Fan in this thread if you are too lazy... and I just listed 2 of many links).
And (re: "bad programming decisions") what do you call the thumbnailing issue, and the file copying issue... even MS, in slightly less "derogatory" terms, admitted it was because of bad design.
This site was updated TWICE (at least) with ever changing release dates to reflect MS's change in delivery plans:
http://www.winsupersite.com/faq/vista_sp1.asp
You will notice that different people at MS were announcing different things (at the SAME time)... the one thing that seems consistent: SP1 is scheduled to be released the same time as the new server release - which was also expected by year end 2007 - and has been pushed back.
I guess "near" is a subjective thing... but as of right now, it seems they really have no real release strategy... until it is done, I am not betting on "near" or even "sometime soon"
What really interests me is that they are quite well aware of the need to address these issues quickly if they want to see a greater adoption of Vista by businesses and/or home users considering upgrading - yet the release date, for a Service Pack that only addresses some of the issues, keeps slipping.
Yes, I agree it is a good thing that they don't release the SP till it's ready - but it kinda scares me that they need to put in so much time to fix the issues that they are addressing - and scarier still, that in trying to do so, their release date keeps slipping... it kind of makes me think that when they looked at the issues and underlying code, they collectively said "Wow, this is really a mess... we need a LOT more time than we thought if we are gonna fix this" (well, I think doubling the release time is a LOT more time... though considering their recent OS release schedule, they may disagree).
It makes me seriously wonder how severely wrong some of their programming decisions (or "push it out the door, ready-or-not" decision) with Vista really were - and how adequately a Service Pack can really address those issues. (is this gonna be just another band-aid?)
Somewhat true... to avoid such loss, one should have a higher voltage with a lower amperage. But nonetheless, it also requires finding better quality wiring [both in the wire itself - which should be highly stranded, and in the insulation (and possibly the coating on the wires)]
Thus, for the same materials cost, AC is better, because finding higher quality wiring for DC applications is (1) more expensive, and (2) more difficult.
So, even using household wiring would not work, since a solid wire is not well suited to DC current carrying (for the reasons I stated in my last post).
DC has one other glaring disadvantage in a normal setup. Increase the distance you are carrying a load, and the thickness of the cable needs to be expanded greatly to compensate for loss through heat (already mentioned in more technical terms above). The alternatives for carrying DC current without such loss are far too expensive for normal use (which is in part why they are used for HVDC carrying over great distance.
Anyone who wants to test this (and risk blowing up your car battery from a dead short) can simply grab a halogen headlight, a 200' extension cord, and wire it up (a fuse might be nice if you value your battery, possibly your life as well, and dont want a flaming extension cord). You will notice that the extension cord is much thicker than the wiring in your car... but also much longer. You will also notice it turn to a puddle of slag... where if you arent lucky, it will cross short when it melts it's insulation - at which time you have to help it sufficiently melts (quick enough) that the dead short it creates doesnt make your battery do "bad things". Now, with AC, when you go from a 2' distance to a 200' distance, the necessary increase in wiring gauge is not so extreme. So, I would NOT recommend anyone testing this.
Well, I'm NOT suggesting it's the answer... I'm suggesting it's a POSSIBILITY...;-)
There is enough documentation online about weird results (or return codes or worse) if you shut down (various versions of) SAMBA (especially for Windows SAMBA shares) with active shares open... this could be one of them - or not... but without knowing more about the setup(s), who knows?
I wish I could confirm it (either way)... I do have a friend who has an Apple (well, multiple)... I'll ask him if he can try it out and see what is going on "behind the scenes" - when I next talk to him. He's both a PC and Apple tech, so he is computer saavy enough to dig behind the scenes to see whats going on at the SAMBA side...
Because, if you search (try Google... if you enter the right keywords you'll find the right info), there have been numerous issues of weird results and return codes if SAMBA is shut down with a session active.
Yeah, it could be an Apple issue as well... if it is, then I am sure there will be a patch announcement, and patch, in less time than for instance... the TCPIP throttling "issue" with Vista. No, not trying to be an Apple fanboy (I dont even own one)... but its just historical (how long the two take to fix something, and which one ignores the issues and pretends they dont exist until they take enough heat for them).
Either way, some more information would have been nice...
It depends on what tradeoff is worth less to you (and on how stable your machine(s) are). Do you want speed (cached) or less chance of data loss (flush each file from cache). I guess POV decides who is "right" - I set my caches to about 1GB with high lazywrite settings... I archive pretty regularly, and the changes to stuff on disk are minimal enough it doesnt matter. I might lose part of a log file... oh well.:-)
Error code 51 doesnt neccesarily mean the transfer failed. It can also mean lost connection to the share - which could have happened (in OSX's "mind") after it thought/was told the transfer was complete.
For instance, what if in stopping the share on the Windows session (incorrectly listed in the/. article as a FreeBSD Share), the SMB crap in Windows is "cleaning up" while shutting down and generating a "complete" code that it sends back to the Apple machine, which then in trying to communicate with the share, realizes it no longer can, and generates the correct error code as noted (51).
OSX did NOT generate a disk write error or any other error that would have been more applicable (like 43 or a bunch of other possibilities). It generated an error stating it lost communication with the other machine.
Again, still not enough info without knowing more about what the WinShare does when closed.
Actually, without more information than the complainer posted, we know NOTHING.
Consider this, Samba crashed on his FreeBSD machine... and? when? how?
If Samba (on his FreeBSD machine) crashed after accepting the data and reporting back to the machine running Leopard that the transfer was completed but BEFORE it flushed it from cache to disk, how is Leopard at fault?
If Samba (on his FreeBSD machine) reported that the files were successfully written before it crashed (and actually finished writing the files), how is it Leopard's fault?
It is actually highly unlikely that it is Leopard's fault or many more data loss scenarios would pop up, since Finder is initiating the data transfer, AND THEN, the file delete. For this to actually happen, Finder (and the underlying code) would have to "forget" to get back a status from the FS driver indicating success on copy - and then start deleting the originals anyway. This "bug" would surface under any number of scenarios unrelated to this guy's FreeBSD setup.
Is his FreeBSD share in question on an NTFS partition with a flakey NT driver (or some other file system driver that's flakey)? Some of them will (incorrectly) report files written when they are not - which would trigger Leopard to (correctly) delete the files. I've experienced this exact same problems with some early JFS builds which incorrectly report a file written, then never get to it before the system is restarted or crashes. I wouldnt blame that on the OS of the connecting machine... it did what it was supposed to.
The only possibility that could make it a MacOSX problem is if the Samba share was reporting back something (else) that MacOSX thought meant "all done" thus starting the deletion of the original. And even in that case, it could be because of a non-standard Samba implementation on the FreeBSD box that is sending back an erroneous code.
You have to remember, Finder doesnt actually CHECK each file... it checks the return codes from the FILE SYSTEM (whether local or network) and then handles its next steps based off that (ie: success, disk full, write error, etc). This is the same procedure for virtually every operating system that runs on PC (yes, there are certain file transfer methods that actually do a file verification stage, but that is NOT the default for 99% of standard, end-user file transfers).
Even in the case of using a transfer method that actually verifies the files, it can be a moot point. If the files are still in cache, or the file-system structures are cached and those caches arent flushed and then the system or protocol/FS crashes, I'll lose data... but in the meantime, if the sending system requests "verification" of each file, the receiving system, via reading what is cached, will report that the writes were successful.
I fail to see how he - or anyone else - speculates this is a Leopard bug without more information. Yeah, it might be... but it more likely isnt.
Slashdot Mirror
Sorry for being US centric in that last post... I can definitely see helping them in non-US areas.
As for US areas, I am baffled that they have no data for anywhere in my area (30 minutes from NYC in a major suburb) - well, to be truthful, they have an outline of the geography (land and water boundary line) - but thats it... especially since it is free, and doesnt take too long (for them) to import all 70GB of it into a database... for us to feed the data through their web server would take months...
So, for the US, my answer stays mostly the same... they need a base data set first before they can ask for help fixing it... and no one has taken the effort to download and import the quite very free data set for the US. So, to truly help them, would mean someone should grab all the (free) US data and upload it for them... how long does it take to send 70GB through a bunch of web scripts? I wonder... ok, nevermind... they should handle that part themselves I guess... ;-)
The THEORY (ie: not mine, and dont know or care how valid it is) is that if the map data was accurate, bad people could pinpoint an exact location to within 13" +/- a few inches to do bad things, like use their imaginary WMDs to to pinpoint bombing - and (my guess) also to make the average citizen feel slightly more anonymous since the locations on the map dont actually correspond to their real location in the real world (most people wont make the connection you made - that the directions and location info will still put you within a few houses or so of their real location).
I'm not disagreeing with you - just pointing out what is *claimed* by those who compile the data (which is NOT me :-) I just USE the data... ).
The geographic portion though (street centroids, intersection *locations* (and types), town/city/county boundaries, waterways, etc) is supposed to be near 100% accurate to within those 6 decimal degrees of longitude and latitude.
Actually, Google seems to get their data from a variety of sources, NavTeq being one of them... trying out different zoom levels and different locations will show you different "contributors" for the data that Google uses.
For instance, try New York, NY... you will see the copyright statement says "Google Imagery, NASA, TerraMetrics, MapData & NavTeq" - other areas will have one or more of those and/or others that arent in that list...
As for the innaccuracies, I doubt they are by Google's or NavTeq's or TeleAtlas' design... just simply by the fact that the US Government decided upon including that innaccuracy, and the source data it all comes from is theirs (the govt's)... I just think it is all that is available for those companies to work with (at least when it comes to nearly complete data sets).
Hi... it's not quite that simple. Here is how the data works... let's assume you live on a straight street...
The data has StartLong, StartLat -> EndLong, EndLat and corresponding StartHouseLeft, EndHouseLeft, StartHouseRight, EndHouseRight for that segment (which may or may not be your whole street - depends on whether the street curves somewhere, or is intersected by other streets, etc). Google, Tele, Nav, etc take what address you enter, and interpolate it based off that data so...
If the data set says your street starts at #0 and goes to house #40 and yours is house #20, it interpolates your address to be dead center on the segment and calculates that lat/long point based off that... but... what if half the houses on your street have 150' frontages, while the other half have 80'? Well, then the data is innaccurate... or what if (which seems to be the standard) the data starts your street at 1, but your street actually starts at 14? (Mine is exactly like that... so the whole first segment is highly innacurate). And the segment data dont take into account the WIDTH of interesections... so segment one (when it hits an intersection) ends in the middle of it. Segment two starts at that exact point. If the intersecting road is a rural or suburban local road, it may be 30-40' across... if it is a highway, it may be a couple hundred feet across (depending on median size, # of lanes, etc). That also makes all data even more innacurate (because the start address gets located on the highway - as the corner is represented by a point intersection instead of by a 2D road and highway width intersection.
So, no, there is no way way to fix it - because even though the data does say what type of road each segment is, that still wont tell you how wide the road (or any median on it) is. For instance, Interstates in the middle of no-where are often 2 lanes each direction... or in Norther Jersey, hit 6 or 7 lanes each direction... they both show up as the same road type.
True... though they dont hide it, it just isnt acurate, even though the information is stored in 6 decimal places...
And as for the gang checking out our site, you will find only one difference in the data compared to Google's - I dont adjust it to the left or right to make it pretty... the Tiger-Line Data specifies road direction, and whether the address is on the "left" or "right" (ie: if the road segment goes north, left addresses are on the west side). Google takes the exact same results, and moves them a couple pixels or fraction of degrees (amount determined by returned map size) tangential to the road in the appropriate direction... I may do that one day... but for now, the data I return is dead center in the middle of the road (by "choice" ie: too lazy to care at the moment - when I put up the mapping component, I will "fix" that).
Enjoy! Take the latitude and longitude, put a , between them, and drop em in Google Maps... compare that to the address you entered on my site, and you'll find that other than moving it "left" or "right" (as the data set describes it), it is otherwise identical...
Why help any of them? The US data is FREE anyway... 99% of the people who pay for the data just dont realize that.
There IS a reason why Google's (and everyone else's) data is incorrect. I'm wondering if Google got their data directly, or wasted money paying for it from TeleAtlas or NavTeq or one of the other companies that gets it for free...
The US Tiger-Line Data it is based off of (SAME errors in data - I know, I've got the whole Tiger-Line set to use for comparison) clearly states in the massive 369 page "Technical Document" (well I think 369 pages is kinda large) that the data is purposefully innaccurate to ensure that it cannot be used to pinpoint the exact location of any residence to help ensure some level of privacy for each citizen.
By allowing users to correct the information, it also means the interpolative data for other addresses becomes accurate or more accurate... for instance, if my neighbor corrects his location pointer, and you look addresses on the street, even if his is in the database as an exception rule, you can easily spot the exception and re-plot the rest of the data.
For reasons of National Security (second reason cited in the Tiger-Line Docs), that also can be bad, because figuring out a pretty near exact location of sensitive areas just requires someone(s) who live on each side to correct their info.
Especially considering the data set works with 6 decimal places of latitude or longitude precision (which is about 13" give or take for most US locations... in Alaska it is far more accurate on the longitude portion at 6 decimal places)...
I'm still up in the air as to whether this ends up being a good thing or a bad thing...
Morning!
I've checked out both the stuff for and against MS's DRM in Vista... I've yet to come up with too much of a definitive opinion on it.
I do know, that in testing WMP11, and disabling all of the "Talk to MS" features and "Check my Media" options, and it went right ahead and started scanning all my drives AND talking to something on the Internet anyway (even closing it didnt stop it - had to restart).
Now, maybe that's because it's an earlier WMP11 release that hasnt been updated (and is something they resolved)...
But what scares me more in the DRM and invasiveness options are their recent patents indicating intent to watch every file created on the OS or through their products to be able to serve ads...
Then of course, there's the delay in many activities that many have speculated are due to the DRM (copying images and music, playing music or videos and accessing a network, etc).
So, the jury's out still (for me) on that... but I am leaning towards seriously wondering what nightmares may soon be enabled in the OS in the lines of DRM and ad serving.
Oh well, time will tell... as for the rest, I think we're in total agreement :-)
You make very valid points - I wish the rest of the computer illiterate world understood them.
I think that understanding is severely hampered because the RIAA is going all out to try to equate file sharing apps with illegal sharing - period (as in that is ALL they are for). Since most people have no idea what BitTorrent or other P2P apps are, and all they see in the press is that they are used for illegal file sharing, the general public (which includes many computer/technology illiterate judges, jurors and journalists) believe them.
I think until public perceptions on the matter are not driven by the RIAA, things wont change nearly as fast as they need to - which is why this battle is so important - because the only leash to prevent new laws outlawing P2P software and many other technologies are currently things like the FSF... so again, in total agreement with you...
I am on the production team for Star Trek New Voyages and we use BitTorrent to legally release virtually all of our episodes. We have had something approaching 50 million or 60 million downloads so far. I for one have no idea how, an entirely volunteer effort, relying on others to help us distribute the episodes, and our own money to fund production and our own site, could ever manage to afford to deliver our episodes to that many people without something like BitTorrent (or one of us to hit the jackpot - which hasnt happened).
(Thus we have) a perfectly legal, legitimate, large scale use of P2P software - that the RIAA demonizes and wants to make illegal. One of only many examples.
I'm all for this battle and the FSF's involvement... because if the RIAA gets their way, we (and many other legitimate companies) will have crippled, costly distribution methods.
If I had MOD points, I'd mod you up as high as it would let me... (which is I guess only +1 more) ;-)
Hey... sorry if I seemed sarcastic (or like I was screaming - I was actually emphasizing)... too many trolls, and I guess I am getting too jaded? :-)
Why it got modded +5 Insightful, I dont know... but then again, I dont mod my own posts... ;-)
As for the rest, I think that my idea of serious issues may be different than yours... or I didnt clearly state those issues...
Some is definitely code related... (some of the ones that *I* think are major - which you or others may not are, for instance, the extensive DRM, and the broken promises that many businesses were looking forward to as a reason for adopting Vista).
The other thing I thought was weird (and I made a comment saying it "seemed like" MS looked at the code and....) was that the SP1 team hugely underestimated the time they needed. That wasn't supposed to be taken as *my* opinion on the code... just what it seemed they were acting like based off the release date the SP1 Team originally talked about having changed so drastically.
.
The rest of the "serious issues" I have, are more in line with how it will affect their current and future goals... the longer it takes (or the longer it slips back) to release SP1, the less likely businesses will adopt it (and more likely they will wait for "Windows 7"). I see that as a serious issue for them... yeah, they have money... but it means the money they spent is largely wasted on that entire segment (upgrades)... and then what? Will the businesses decide to wait for a few months to see how "Windows 7" performs and/or decide/need to wait for "Windows 7"s first Service Pack? With stepping up their release cycle, Vista needs to be "perfect" now if they want a greater adoption of it before "Windows 7" (yeah, I know it cant ever be perfect - nor can any OS - that is why it's in quotes...). With the stepped up release cycle, "Windows 7" needs to work well enough on release as well for adoption of it - which STILL may not help as companies have "learned" to either wait for the first Service Pack or for a few months to see if the OS needs it (whether they are right or wrong in the case of "Windows 7" to me is irrelevant... that they are likely to wait - especially with a faster release cycle - can also be harmful to MS). When does the cycle end? Surely not when an OS requires a Service Pack to fix big issues right out the door, and surely not when that Service Pack takes over a year (from the Nov release) to put out, and surely not when they are trying to step up their release schedule so aggressively (compared to their last release... namely XP ->Vista - and the large delays and dropped features).
The issues raised are hardly evidence of the serious flaws you implied.
So, what you are saying is this:
-MS is trying to push businesses (and home XP users) to upgrade to Vista - which isnt happening in nearly the numbers they want.
-MS will not be releasing SP1 till 1 year after Vista release (longer if you count the business GA release in Nov 2006), even though it is needed to address many issues that are preventing businesses from adopting Vista
-MS *has* announced SP1 would be ready sooner - that it wasnt an "official public" announcement is just indicative of the fact that the very team who is working on SP1 severely underestimated the time it would take to complete it (that isnt an issue? if a mechanic told you fixing your car would take a week, then told you it would take 2 and a half weeks, you wouldnt be upset - or wondering what else he found that was wrong with it?)
-MS has announced a release strategy for "Windows 7" that means in order for them to stay viable in the marketplace (ie: get more sales/adoption of Vista) requires that Vista is "adoptable" by their customers who wont touch it... thus the later the release date for SP1 (assuming, and thus giving MS a very big benefit of lots of doubt that SP1 fixes everything)... so the later SP1 is, the more likely those customers they want to switch to Vista will decide not to, and instead wait for "Windows 7"
-The fact that key issues (invasive DRM, lack of many of the wanted - but dropped Vista features, no easy business licensing path/key server setup like with certain business releases of XP/Server2003) are still not being addressed, even with the time extension from the SP1 team's original estimate, is also going to hamper adoption of Vista.
So, none of those are serious flaws? For me? No... for MS's plans of increased Vista adoption, most definitely. For businesses and consumers who need to wait a year (or more) for the SP? Probably.
I think that our definition of "serious flaws" (and I am including their "business model" in that "equation") is just quite different... and that's fine.
You obviously need to re-read the article. Here, let me quote it for you - and the text from the link you mention:
After lots of wavering, Microsoft has finally made the due date for Windows Vista Service Pack 1 (SP1) official: The update will ship in the latter half of 2007.(Microsoft didn't issue a press release with that pronouncement. Instead, it notified its Technology Adoption Partner testers of it via an e-mail regarding the imminent start of the Vista SP1 testing program.)
The second half 2007 date won't be too surprising to folks who believed Microsoft Server and Tools chief Bob Muglia, who confirmed reports that Vista SP1 would be timed to hit with Longhorn Server, another Microsoft product due in the latter half of 2007.
It says *SP1* will be released. It says that the ****ANNOUNCEMENT**** was sent to it's "TAP testers" It says none of the nonsense you mention.
Here's the second quote - from that very announcement (linked to by Mary Jo):
Brief SummaryWindows Vista Service Pack 1 (SP1) will be a standard service pack that will include security updates, hotfixes, as well as limited other changes focused on improving quality.
The Technology Adoption Program (TAP) is looking for customers and partners actively test and provide feedback on Windows Vista SP1 to help us prepare for its release in the second half of CY07. Customers must be willing to provide feedback and deploy pre-release builds into production environments.
I have BOLDED the appropriate line. It QUITE CLEARLY states, in discussing SP1, in preparation for its RELEASE in second half of CY07. It then goes on to mention that TAP testers can download the betas before then - which is what the whole email from MS was about - "Please download the betas and help us test them so we can release SP1 to the public by second half CY07"
It's all there - you just seem intent on misreading it - or havent had enough coffee... and as I have had those days (not enough coffee - which today isnt such a day), I will give you the benefit of doubt and allow you to have the chance of re-reading them before I assume you are a troll.
I haven't any signs of "bad programming decisions" in Vista. Of all the technical documentation and blog posts read the view is one of significant advancement in the underlying API's and architecture. But maybe if I was looking at this completely uninformed and ignorant, I might also come to some FUD conclusion.
Or you might do a Google Search before you claim I am wrong (re: release dates - see my other reply to another MS Fan in this thread if you are too lazy... and I just listed 2 of many links).
And (re: "bad programming decisions") what do you call the thumbnailing issue, and the file copying issue... even MS, in slightly less "derogatory" terms, admitted it was because of bad design.
No, YOU are either FUDding... or just have a lack of knowledge.
Jan 22nd, 2007 & Apr 20, 2007 - MS (and others) announces SP1 for second half of 2007:
http://blogs.zdnet.com/microsoft/?p=208
http://arstechnica.com/journals/microsoft.ars/2007/04/20/intel-may-have-revealed-the-release-date-for-vista-sp1
This site was updated TWICE (at least) with ever changing release dates to reflect MS's change in delivery plans:
http://www.winsupersite.com/faq/vista_sp1.asp
You will notice that different people at MS were announcing different things (at the SAME time)... the one thing that seems consistent: SP1 is scheduled to be released the same time as the new server release - which was also expected by year end 2007 - and has been pushed back.
Not to sound too much like a troll or anything, but until it is downloadable, I for one will not consider it "near".
SP1 was scheduled for release this past summer (from MS announcements shortly after Vista Consumer release).
SP1 was then delayed to "by the end of the year" (from comments made a month ago)
SP1 (from MS's latest comments which you can find here: http://www.itworld.com/Comp/2218/071115vistaskip/ ) is now scheduled for release in Q1 2008.
I guess "near" is a subjective thing... but as of right now, it seems they really have no real release strategy... until it is done, I am not betting on "near" or even "sometime soon"
What really interests me is that they are quite well aware of the need to address these issues quickly if they want to see a greater adoption of Vista by businesses and/or home users considering upgrading - yet the release date, for a Service Pack that only addresses some of the issues, keeps slipping.
Yes, I agree it is a good thing that they don't release the SP till it's ready - but it kinda scares me that they need to put in so much time to fix the issues that they are addressing - and scarier still, that in trying to do so, their release date keeps slipping... it kind of makes me think that when they looked at the issues and underlying code, they collectively said "Wow, this is really a mess... we need a LOT more time than we thought if we are gonna fix this" (well, I think doubling the release time is a LOT more time... though considering their recent OS release schedule, they may disagree).
It makes me seriously wonder how severely wrong some of their programming decisions (or "push it out the door, ready-or-not" decision) with Vista really were - and how adequately a Service Pack can really address those issues. (is this gonna be just another band-aid?)
Any of them running on Vista... I can only imagine the headaches having to have someone in front of the server:
USER29843 is sending their order information via the web... [CANCEL]/[ALLOW]?
USER29843 is trying to pay by credit card... [CANCEL]/[ALLOW]?
.
Moderator Tip: Mod +1 FUNNY
Somewhat true... to avoid such loss, one should have a higher voltage with a lower amperage. But nonetheless, it also requires finding better quality wiring [both in the wire itself - which should be highly stranded, and in the insulation (and possibly the coating on the wires)]
Thus, for the same materials cost, AC is better, because finding higher quality wiring for DC applications is (1) more expensive, and (2) more difficult.
So, even using household wiring would not work, since a solid wire is not well suited to DC current carrying (for the reasons I stated in my last post).
DC has one other glaring disadvantage in a normal setup. Increase the distance you are carrying a load, and the thickness of the cable needs to be expanded greatly to compensate for loss through heat (already mentioned in more technical terms above). The alternatives for carrying DC current without such loss are far too expensive for normal use (which is in part why they are used for HVDC carrying over great distance.
Anyone who wants to test this (and risk blowing up your car battery from a dead short) can simply grab a halogen headlight, a 200' extension cord, and wire it up (a fuse might be nice if you value your battery, possibly your life as well, and dont want a flaming extension cord). You will notice that the extension cord is much thicker than the wiring in your car... but also much longer. You will also notice it turn to a puddle of slag... where if you arent lucky, it will cross short when it melts it's insulation - at which time you have to help it sufficiently melts (quick enough) that the dead short it creates doesnt make your battery do "bad things". Now, with AC, when you go from a 2' distance to a 200' distance, the necessary increase in wiring gauge is not so extreme. So, I would NOT recommend anyone testing this.
Excellent suggestion - I hope he tries it and posts the results... that would narrow down what needs to be fixed - and where it is.
Well, I'm NOT suggesting it's the answer... I'm suggesting it's a POSSIBILITY... ;-)
There is enough documentation online about weird results (or return codes or worse) if you shut down (various versions of) SAMBA (especially for Windows SAMBA shares) with active shares open... this could be one of them - or not... but without knowing more about the setup(s), who knows?
I wish I could confirm it (either way)... I do have a friend who has an Apple (well, multiple)... I'll ask him if he can try it out and see what is going on "behind the scenes" - when I next talk to him. He's both a PC and Apple tech, so he is computer saavy enough to dig behind the scenes to see whats going on at the SAMBA side...
Because, if you search (try Google... if you enter the right keywords you'll find the right info), there have been numerous issues of weird results and return codes if SAMBA is shut down with a session active.
Yeah, it could be an Apple issue as well... if it is, then I am sure there will be a patch announcement, and patch, in less time than for instance... the TCPIP throttling "issue" with Vista. No, not trying to be an Apple fanboy (I dont even own one)... but its just historical (how long the two take to fix something, and which one ignores the issues and pretends they dont exist until they take enough heat for them).
Either way, some more information would have been nice...
It depends on what tradeoff is worth less to you (and on how stable your machine(s) are). Do you want speed (cached) or less chance of data loss (flush each file from cache). I guess POV decides who is "right" - I set my caches to about 1GB with high lazywrite settings... I archive pretty regularly, and the changes to stuff on disk are minimal enough it doesnt matter. I might lose part of a log file... oh well. :-)
Error code 51 doesnt neccesarily mean the transfer failed. It can also mean lost connection to the share - which could have happened (in OSX's "mind") after it thought/was told the transfer was complete.
For instance, what if in stopping the share on the Windows session (incorrectly listed in the /. article as a FreeBSD Share), the SMB crap in Windows is "cleaning up" while shutting down and generating a "complete" code that it sends back to the Apple machine, which then in trying to communicate with the share, realizes it no longer can, and generates the correct error code as noted (51).
OSX did NOT generate a disk write error or any other error that would have been more applicable (like 43 or a bunch of other possibilities). It generated an error stating it lost communication with the other machine.
Again, still not enough info without knowing more about what the WinShare does when closed.
Actually, without more information than the complainer posted, we know NOTHING.
Consider this, Samba crashed on his FreeBSD machine... and? when? how?
If Samba (on his FreeBSD machine) crashed after accepting the data and reporting back to the machine running Leopard that the transfer was completed but BEFORE it flushed it from cache to disk, how is Leopard at fault?
If Samba (on his FreeBSD machine) reported that the files were successfully written before it crashed (and actually finished writing the files), how is it Leopard's fault?
It is actually highly unlikely that it is Leopard's fault or many more data loss scenarios would pop up, since Finder is initiating the data transfer, AND THEN, the file delete. For this to actually happen, Finder (and the underlying code) would have to "forget" to get back a status from the FS driver indicating success on copy - and then start deleting the originals anyway. This "bug" would surface under any number of scenarios unrelated to this guy's FreeBSD setup.
Is his FreeBSD share in question on an NTFS partition with a flakey NT driver (or some other file system driver that's flakey)? Some of them will (incorrectly) report files written when they are not - which would trigger Leopard to (correctly) delete the files. I've experienced this exact same problems with some early JFS builds which incorrectly report a file written, then never get to it before the system is restarted or crashes. I wouldnt blame that on the OS of the connecting machine... it did what it was supposed to.
The only possibility that could make it a MacOSX problem is if the Samba share was reporting back something (else) that MacOSX thought meant "all done" thus starting the deletion of the original. And even in that case, it could be because of a non-standard Samba implementation on the FreeBSD box that is sending back an erroneous code.
You have to remember, Finder doesnt actually CHECK each file... it checks the return codes from the FILE SYSTEM (whether local or network) and then handles its next steps based off that (ie: success, disk full, write error, etc). This is the same procedure for virtually every operating system that runs on PC (yes, there are certain file transfer methods that actually do a file verification stage, but that is NOT the default for 99% of standard, end-user file transfers).
Even in the case of using a transfer method that actually verifies the files, it can be a moot point. If the files are still in cache, or the file-system structures are cached and those caches arent flushed and then the system or protocol/FS crashes, I'll lose data... but in the meantime, if the sending system requests "verification" of each file, the receiving system, via reading what is cached, will report that the writes were successful.
I fail to see how he - or anyone else - speculates this is a Leopard bug without more information. Yeah, it might be... but it more likely isnt.
Mod Parent "+1 Intelligent" (and then ban him from SlashDot!!!) ;-)