Actually GPS is integrated. The more interesting question is whether it's an open platform or not. Since it's OS X based one can hope. Since it's billed as another iPod it seems unlikely though.
The price will come down. The exclusive carrier agreement was probably the only way that Apple could get any carrier on board on the terms they wanted. Remember the ROKR? It was crippled because short-sighted carriers demanded ridiculous limitations to the device.
So, I work on Pastry. There are two branches of Pastry: MSPastry (developed by Microsoft Research) and FreePastry (developed initially by Rice, open source, now developed primarily at The Max Planck Institute for Software Systems (where I work)). They were started at roughly the same time, while Prof. Peter Druschel (formerly of Rice, now at MPI-SWS) was on sabbatical at MSR.
Microsoft didn't co-opt anything, and in fact allowed and encouraged the open source Java version initially. These days I understand the MSPastry isn't actively developed, but FreePastry lives on. FeedTree uses FreePastry, as does ePOST, and a variety of other projects.
The literature tends to define garbage as any object that cannot affect the results of any future computation. Pointer reachability is simply a useful conservative approximation. There are some proposed GC systems (I don't believe any have been implemented in a real system) that attempt to do better and collect some objects that are still reachable.
So those objects in your program are garbage, and you do have a memory leak.
I bought a mac one month ago. There were a lot of reasons I bought a mac, but iPhoto was one of them. It turns out iPhoto really sucks for me because it's performance is terrible. With only 700 photos it takes like a minute to load on my G4 iBook. I consider this a serious bug, and I don't want to have to pay $50 just to fix broken software. Sure there are other features to the new iLife. But I'm so peeved at having to pay $50 for a bug fix for software I just bought a month ago that I can't look past that to see if iLife '04 is a good value.
So I'll probably be buying it, and I might be glad I got all of those new features, but right now I feel like I'm getting my arm twisted.
In 100 years, JPEG will probably not be the common format. It probably won't be the standard format in 20 years.
I would be very surprised if the equivalent of photoshop can't still read jpeg's in 100 years. The web has guaranteed that there's too much data out there in that format for it to ever die completely.
That's why I'm advocating against CDRs. Store it on your hard drive. It can't be left in the attic then.
I had a huge rant here about digital vs. film and why the computer industry is the way it is.
But basically: hard disk space is cheap and will continue to get cheaper. Keep your digital photos on your hard drive. When you buy a new computer copy all of your stuff off your old hard drive to your new computer.
It's not much of a chore really. It's probably less of a chore to copy occasionally than it is to manage a bunch of CD's or disks. If you do things this way (plus making the occasional backup) you won't have to worry about obsolete formats, old decaying media, etc.
Is it more of a pain than dealing with negatives? maybe. Do you get something for your pain? Yes, in my opinion you get a lot.
To sum up a bit of the rant previous occupying this space, money (and a few smart choices in advance) can always solve the obsolesence problem. The real problem is media decay. Archive quality media can help here but even that's not as good as older information storage formats (like film and paper).
The media has a short lifespan, but the data doesn't. The nice thing about digital is infinite perfect copies (as I mentioned in my original reply).
As long as storage density keeps increasing most people will do what I do. Every time I get a new computer I copy all of my old data off the old one. I do make some backups on CD but all the data I really care about is on my hard drive.
We are going to lose some data to bad digital media, yes.
As an aside I remember reading somewhere about a recently discovered ancient babylonian text (on parchment) decrying the decline in the use of clay for accounting purposes since parchment doesn't archive well enough.
It may actually have been papyrus, not parchment. I don't recall.
Also, digital photography while convenient has archival issues just like traditional silver based photography and one has to wonder if we are going to have the same historical record 50, 60 or 100 years from now that we currently have.
It might not be all bad. Digital photographs have the potential to last in pristine condition forever (as long as you keep copying them to new media). Also since they're so cheap to take and store we might have many more photographs for our historical record. With some advanced image processing image searching and sorting could be great tools to historians as well.
Fermat was a famous liar. It's quite likely that he didn't actually have a proof for his conjecture (it wasn't properly a theorem until proven) but had a gut feeling it was true. Or perhaps he just found one of the many flawed proofs that have come out over the years. There are a few relatively simple 'proofs' of fermat's last theorem that superficially look correct but fail on close inspection.
I'll admit that I don't follow crypto very closely. Nonetheless, everything I said was true, assuming MD5 is a perfect hashing function. Which crypto circles have decided it's not (I think SHA1 is the preferred hash among people who are concerned with these kinds of things).
But how bad is MD5? Should we be concerned about using it for a file checksum? If anybody knows offhand what the (practical or theoretical) weaknesses of MD5 are, I'd love to know.
Presuming there are weaknesses to MD5, I'd presume that the chinese lottery program attempts to exploit them rather than just calculating random hashes and hoping to get lucky.
Umm, the fact that hashsums are only "practically unique" isn't why they're an inadequate method of identifying MP3s (and that's not what Schneier is saying in the article). The reason they're inadequate is that depending on what encoder you use and the settings there will be a bunch of different MD5s of the same song.
The RIAA could get around this by setting up a battery of tools to try to get all of the relevent hashes, but it would be possible to create encoders that perturb the compression process to get different bits in the file while sounding essentially the same. A trivial way to do this would be to watermark your MP3s with random data.
The chance of an MD5 collision if MD5 were an ideal hashing algorithm is astronomically small. To get a 1% chance of a collision you'd have to test on the order of 2^63 samples (for the math behind this google for the birthday paradox; it's of the order of the sqrt of the size of the hash space) to find two that match. Never mind finding an MD5 which matches a chosen hash value.
This is a really big number.
Nobody's really concerned about MD5 hash collisions of reasonable corpii (corpuses?, forgive my pseudo-latin) if MD5 is actually a perfect hash, or somewhat close to it. What people are really concerned about is there being some weakness in MD5 where you can reverse the algorithm and given some MD5 hash (maybe not any hash, maybe just certain ones) and come up with strings which hash to that value.
For example, suppose that 2^127-1 is prime (it may well be but I'm too lazy to check). Then if you start pulling out random strings foo and using the remainder of foo mod 2^127-1 as your hash you'll also have a 1% chance of a random collision with a sample size of the order of roughly 2^63, as above. However there are some trivial collisions you can calculate, like 0*(2^127-1), 1*(2^127-1), 2*(2^127-1) all hash to the same value.
If the data you're feeding your hash algorithm is random (more or less) there's no reason to prefer the modulus algorithm over MD5. But if you're using it for cryptographic things the modulus algorithm is pretty useless, and it may turn out to fall down on many common inputs that MD5 gives good results for.
I may have goofed some of this, and there's lots more to be said about it but I've wasted enough time on this post as it is.
I think you'll find that in practice a UDP-based solution isn't going to make your life any easier than TCP. You may want to use TCP in conjunction with an external timer to fail the connection well before TCP gives up though. If you tend to do multiple RPCs to the same host the overhead of TCP should be minimal, and you get a lot of functionality (retries, backoff, etc.) for free. There's RFCs for transactional TCP which solves some of the overhead problems for small exchanges but I don't think they're widely implemented.
If you do end up writing your own UDP-based protocol, take some time to study TCP as well as other UDP based protocols and make sure you write something network friendly. There are a lot of naive protocols which fail spectacularly in less-than-perfect conditions.
In case you missed it, the Wright plane replica didn't fly. So lighter engines is obviously not the panacea here, but good aerodynamics may well be.
Actually, it did fly. Three times earlier this month. Just not today. It had been raining all morning on the anniversary and the humidity was too high for the finicky engine.
It's probably higher because the population density is higher and in particular the density of internet users is higher, thus lowering the cost per home to wire them up (less km of wire). It's interesting to note that there's more % internet users in the US though, so maybe the density is not the whole story.
South Korea Area (sq km): 98,190 Population: 48,289,037 (July 2003 est.) Internet Users: 25.6 million (2002)
Specifically latex, and more specifically pdflatex for pdf output and tex2page for html. With some hacking you should be able to script tex2page into outputting text as well.
To some extent the texinfo folks have solved this problem as well. The DocBook stuff mentioned elsewhere might be very nice but I have no experience with that.
2) Assuming the program is internal to the company, it will not be distributed - therefore there is no need to share code changes back with you and the community at large.
So it's likely you will have some users, but few contributers.
Legal obligation is only part of the reason to contribute to an open source program. Another huge one is not having to maintain your own set of patches against the main app. Then there's the idea of community - if you share you'll cool features hopefully other people will too. These are sound arguments that businessmen understand. They all lower your local development costs.
I can only speak for ext2/ext3. Linux tries to preallocate large blocks when writing files to prevent fragmentation. If you disk is mostly full (or even was once mostly full) or you have heavy concurrent disk activity going on you can still get fragmentation.
The end goal of the disk subsystem is to get your data to you as soon as you need it. In general that goal would be achieved if the data you want to read next happened to be under the read head. If you're reading sequentially through a single file then this will happen when the file is in a single contiguous region (i.e. unfragmented). For any other access pattern fragmentation doesn't matter as much, since you'll be skipping around the disk regardless of how the files are arranged.
Prefetching heuristics and caching can hide a lot of these problems from the user as well.
Slashdot Mirror
Actually GPS is integrated. The more interesting question is whether it's an open platform or not. Since it's OS X based one can hope. Since it's billed as another iPod it seems unlikely though.
The price will come down. The exclusive carrier agreement was probably the only way that Apple could get any carrier on board on the terms they wanted. Remember the ROKR? It was crippled because short-sighted carriers demanded ridiculous limitations to the device.
If I were king for a day I'd remove the insert key from every keyboard on earth. Nobody needs it and most people can't figure it out.
So, I work on Pastry. There are two branches of Pastry: MSPastry (developed by Microsoft Research) and FreePastry (developed initially by Rice, open source, now developed primarily at The Max Planck Institute for Software Systems (where I work)). They were started at roughly the same time, while Prof. Peter Druschel (formerly of Rice, now at MPI-SWS) was on sabbatical at MSR.
Microsoft didn't co-opt anything, and in fact allowed and encouraged the open source Java version initially. These days I understand the MSPastry isn't actively developed, but FreePastry lives on. FeedTree uses FreePastry, as does ePOST, and a variety of other projects.
The literature tends to define garbage as any object that cannot affect the results of any future computation. Pointer reachability is simply a useful conservative approximation. There are some proposed GC systems (I don't believe any have been implemented in a real system) that attempt to do better and collect some objects that are still reachable.
So those objects in your program are garbage, and you do have a memory leak.
Actually, it's only Starbucks (and maybe Peet's) that tastes like burnt wood. There is good espresso to be had in this world.
I bought a mac one month ago. There were a lot of reasons I bought a mac, but iPhoto was one of them. It turns out iPhoto really sucks for me because it's performance is terrible. With only 700 photos it takes like a minute to load on my G4 iBook. I consider this a serious bug, and I don't want to have to pay $50 just to fix broken software. Sure there are other features to the new iLife. But I'm so peeved at having to pay $50 for a bug fix for software I just bought a month ago that I can't look past that to see if iLife '04 is a good value.
So I'll probably be buying it, and I might be glad I got all of those new features, but right now I feel like I'm getting my arm twisted.
In 100 years, JPEG will probably not be the common format. It probably won't be the standard format in 20 years.
I would be very surprised if the equivalent of photoshop can't still read jpeg's in 100 years. The web has guaranteed that there's too much data out there in that format for it to ever die completely.
That's why I'm advocating against CDRs. Store it on your hard drive. It can't be left in the attic then.
I had a huge rant here about digital vs. film and why the computer industry is the way it is.
But basically: hard disk space is cheap and will continue to get cheaper. Keep your digital photos on your hard drive. When you buy a new computer copy all of your stuff off your old hard drive to your new computer.
It's not much of a chore really. It's probably less of a chore to copy occasionally than it is to manage a bunch of CD's or disks. If you do things this way (plus making the occasional backup) you won't have to worry about obsolete formats, old decaying media, etc.
Is it more of a pain than dealing with negatives? maybe. Do you get something for your pain? Yes, in my opinion you get a lot.
To sum up a bit of the rant previous occupying this space, money (and a few smart choices in advance) can always solve the obsolesence problem. The real problem is media decay. Archive quality media can help here but even that's not as good as older information storage formats (like film and paper).
The media has a short lifespan, but the data doesn't. The nice thing about digital is infinite perfect copies (as I mentioned in my original reply).
As long as storage density keeps increasing most people will do what I do. Every time I get a new computer I copy all of my old data off the old one. I do make some backups on CD but all the data I really care about is on my hard drive.
We are going to lose some data to bad digital media, yes.
As an aside I remember reading somewhere about a recently discovered ancient babylonian text (on parchment) decrying the decline in the use of clay for accounting purposes since parchment doesn't archive well enough.
It may actually have been papyrus, not parchment. I don't recall.
It might not be all bad. Digital photographs have the potential to last in pristine condition forever (as long as you keep copying them to new media). Also since they're so cheap to take and store we might have many more photographs for our historical record. With some advanced image processing image searching and sorting could be great tools to historians as well.
it's probably the docking connector.
Fermat was a famous liar. It's quite likely that he didn't actually have a proof for his conjecture (it wasn't properly a theorem until proven) but had a gut feeling it was true. Or perhaps he just found one of the many flawed proofs that have come out over the years. There are a few relatively simple 'proofs' of fermat's last theorem that superficially look correct but fail on close inspection.
I'll admit that I don't follow crypto very closely. Nonetheless, everything I said was true, assuming MD5 is a perfect hashing function. Which crypto circles have decided it's not (I think SHA1 is the preferred hash among people who are concerned with these kinds of things).
But how bad is MD5? Should we be concerned about using it for a file checksum? If anybody knows offhand what the (practical or theoretical) weaknesses of MD5 are, I'd love to know.
Presuming there are weaknesses to MD5, I'd presume that the chinese lottery program attempts to exploit them rather than just calculating random hashes and hoping to get lucky.
Umm, the fact that hashsums are only "practically unique" isn't why they're an inadequate method of identifying MP3s (and that's not what Schneier is saying in the article). The reason they're inadequate is that depending on what encoder you use and the settings there will be a bunch of different MD5s of the same song.
The RIAA could get around this by setting up a battery of tools to try to get all of the relevent hashes, but it would be possible to create encoders that perturb the compression process to get different bits in the file while sounding essentially the same. A trivial way to do this would be to watermark your MP3s with random data.
The chance of an MD5 collision if MD5 were an ideal hashing algorithm is astronomically small. To get a 1% chance of a collision you'd have to test on the order of 2^63 samples (for the math behind this google for the birthday paradox; it's of the order of the sqrt of the size of the hash space) to find two that match. Never mind finding an MD5 which matches a chosen hash value.
This is a really big number.
Nobody's really concerned about MD5 hash collisions of reasonable corpii (corpuses?, forgive my pseudo-latin) if MD5 is actually a perfect hash, or somewhat close to it. What people are really concerned about is there being some weakness in MD5 where you can reverse the algorithm and given some MD5 hash (maybe not any hash, maybe just certain ones) and come up with strings which hash to that value.
For example, suppose that 2^127-1 is prime (it may well be but I'm too lazy to check). Then if you start pulling out random strings foo and using the remainder of foo mod 2^127-1 as your hash you'll also have a 1% chance of a random collision with a sample size of the order of roughly 2^63, as above. However there are some trivial collisions you can calculate, like 0*(2^127-1), 1*(2^127-1), 2*(2^127-1) all hash to the same value.
If the data you're feeding your hash algorithm is random (more or less) there's no reason to prefer the modulus algorithm over MD5. But if you're using it for cryptographic things the modulus algorithm is pretty useless, and it may turn out to fall down on many common inputs that MD5 gives good results for.
I may have goofed some of this, and there's lots more to be said about it but I've wasted enough time on this post as it is.
I think you'll find that in practice a UDP-based solution isn't going to make your life any easier than TCP. You may want to use TCP in conjunction with an external timer to fail the connection well before TCP gives up though. If you tend to do multiple RPCs to the same host the overhead of TCP should be minimal, and you get a lot of functionality (retries, backoff, etc.) for free. There's RFCs for transactional TCP which solves some of the overhead problems for small exchanges but I don't think they're widely implemented.
If you do end up writing your own UDP-based protocol, take some time to study TCP as well as other UDP based protocols and make sure you write something network friendly. There are a lot of naive protocols which fail spectacularly in less-than-perfect conditions.
Mine doesn't... but it does carbonate.
Umm... that would actually be nitrogenate.
Actually, it did fly. Three times earlier this month. Just not today. It had been raining all morning on the anniversary and the humidity was too high for the finicky engine.
It's probably higher because the population density is higher and in particular the density of internet users is higher, thus lowering the cost per home to wire them up (less km of wire). It's interesting to note that there's more % internet users in the US though, so maybe the density is not the whole story.
South Korea
Area (sq km): 98,190
Population: 48,289,037 (July 2003 est.)
Internet Users: 25.6 million (2002)
[source]
USA
Area (sq km): 9,158,960
Population: 290,342,554 (July 2003 est.)
Internet Users: 165.75 million (2002)
[source]
Some math.
South Korea
% Internet Users: 53.0%
people per sq km: 491.79
Internet users per sq km: 261
USA
% Internet Users: 57.088%
people per sq km: 31.70
Internet users per sq km: 18.097
For those who can't be bothered by the video, a transcript might look something like this:
[Steve Ballmer walks to the podium]
Ballmer: Developer, developers, developers, developers, developers! Developers, developers, developers!
Ballmer: Developers, developers, developers, developers, developers, developers, developers, developers, developers!
Ballmer: Developers!
Ballmer: Developers, developers, developers, developers, developers, developers, developers, developers, developers!
http://www.ntk.net/ballmer/mirrors.html
It's a ballmer original. Larry might have referenced it or parodied it in a State of the Onion.
Specifically latex, and more specifically pdflatex for pdf output and tex2page for html. With some hacking you should be able to script tex2page into outputting text as well.
To some extent the texinfo folks have solved this problem as well. The DocBook stuff mentioned elsewhere might be very nice but I have no experience with that.
Legal obligation is only part of the reason to contribute to an open source program. Another huge one is not having to maintain your own set of patches against the main app. Then there's the idea of community - if you share you'll cool features hopefully other people will too. These are sound arguments that businessmen understand. They all lower your local development costs.
http://www.longnow.com/
I can only speak for ext2/ext3. Linux tries to preallocate large blocks when writing files to prevent fragmentation. If you disk is mostly full (or even was once mostly full) or you have heavy concurrent disk activity going on you can still get fragmentation.
The end goal of the disk subsystem is to get your data to you as soon as you need it. In general that goal would be achieved if the data you want to read next happened to be under the read head. If you're reading sequentially through a single file then this will happen when the file is in a single contiguous region (i.e. unfragmented). For any other access pattern fragmentation doesn't matter as much, since you'll be skipping around the disk regardless of how the files are arranged.
Prefetching heuristics and caching can hide a lot of these problems from the user as well.