You lose significant quality in the second round of encoding.
Are there any studies that show what kind of a decrease in quality is realized by re-encoding, either with the same encoder/settings or with a different encoder? Frankly, I can't hear a damn bit of difference between a burnt & re-riped track and it's original, but my ears are admittedly scarred by that demon rock and roll... Still, I don't believe this quality drop is very significant. I'd be a bit surprised to find a well run study that shows that it is.
In any case, you're free to not re-encode your files after burning them, or to use a lossless encoder. Apple even offers one that works on their iPods if you want to use it.
Yep. This pretty much guarantees that I won't be buying an iPhone. During the keynote I was all "gimme, gimme, gimme!!!" But as rumors came out that it wouldn't be open to third-party developers iI became less and less interested. Now that those rumors are confirmed I'm frankly not that interested. I know Apple won't come out with as many useful apps as a full suite of independent developers would. And while one can still use whatever web-based apps will be out there, it's only a partial solution (and one that is useless if you're in a zone of poor to no coverage).
Sorry Apple. I might consider it at $200-250 or so, but not for 600.
If this is what I think it is, the tech behind TouchStream keyboards (they sold their IP to an unnamed company a couple of years back, and the scuttlebutt then was that Apple bought it for use with their iPods), then it should work very well. I love my TouchStream keyboards -- they're very accurate and responsive.
I don't know how well I will be able to type on it. I use my mobile device constantly for e-mail, IM, taking notes, and browsing. Tactile is something I have grown used to (touch typing). How will I handle no buttons?
Well, a couple of years back, when TouchStream got bought out, everyone suspected it was Apple that bought them with plans to incorporate the tech with the iPod controls -- it looks like this was likely the case. Now then, as for the how well it works for you, it will obviously vary from person to person, but pretty much everyone that uses a TouchStream keyboard loves them. You get used to the feel fairly quickly, and the gestures are the greatest thing in the world. I can't wait to get my hands on one and play with it.
For instance there was no way to intuitively of setting a printer into draft mode for quick printing. Come on!
Go to print anything. When the sheet drops down, use the third selection list to set the options the way you want them for draft printing. Once you have what you think is a good combination for drafts, use the second selection list (Presets) and select "Save as..." Choose an appropriate name, like "Draft". Now, whenever you want to print something in draft mode, just select "Draft" from the list of presets (if it wasn't already set as the current mode). And if you want to set up a 2-up draft mode with a hairline border around the subpages, that defaults to 3 collated copies and a cover page, set one of those up as well.
Now then, I suppose I could ask you why it's easier to install gvim on OS X than it is on Ubuntu...
Well, if you want a number of resellers will physically disable the camera for you. We needed to have that done where I work if we ever wanted to bring them in from the parking lot... Or you could, you know, stick an index card or a Band-Aid or something over the lens...
The Mac is supposed to be brain-dead simple. At least thats how it gets marketed...
No. It's marketed as brain-dead simple for simple things (read: things your ordinary average user will be doing), but with a core that can be much more complex if you really want to be noodling about. The basic user won't really give a damn about what's in the/usr or/etc directories. They won't care about manually setting hidden preferences. They won't be looking for the Developer apps like Shark. They won't be wondering where to put this spiffy new preference pane that they downloaded and so on.
If you plan on developing for the machine, then yeah... you're going to have to do some work on your own to learn about the rest of the system... boo farking hoo. That's been the same for every OS since Basic ROMs went the way of the dinosaurs.
This appears to be yet another case of, "You can write Fortran in any language" where the author ignores that some technologies make it much easier to write Fortran than others. Obviously with a number of things you can avoid the bad stuff by avoiding the bad stuff -- but when bad stuff is the default mode of operation, rather than the odd, explicit corner case then yes... there's an issue.
Put another way, it's a lot easier to not write Fortran in Haskell than it is in C.
What you say is entirely true, but it also applies to printed works and academic papers.
It does, but with printed material there tends to be that chain of trust in existence. Most people are willing to put some trust in Addison-Wesley or O'Reilly publishing to not put out junk (unfortunately this isn't the case everywhere -- see Apress' recent Practical OCaml for an example... whoof!). And a lot of the journals and conference proceedings have a higher sense of trust as they tend to be peer-reviewed and evaluated by others in the profession.
But still, you have your junk that sneaks in, or some journal that some guy publishes in his basement, and you do have to be careful there, as they benefit from that trust when they shouldn't.
Actually, I'm wondering how they measure judging the authoritativeness of a web site.
There are a number of things I could write about and slap them up on the internet for people to read, and while they would be quite factual and well written, someone not familiar with the subject would have a hard time telling if that were the case. After all, there's no reason to trust me -- most people haven't a clue who I am. And even if I were to add references, I could either make them to general works, or to obscure works that most people wouldn't bother to track down for verification.
The problem is even worse when you're dealing with sites like wikipedia. Some of the articles are indeed authoritative, some are utter crap, and some are in between. And of course there's the problem of authoritative articles that have been made subtly inaccurate.
It doesn't seem like the easiest thing to judge authoritativeness without some pre-existing knowledge or at least a chain of trust.
I love it when people say thing like "worthless idea" when they have no idea what they are talking about. Just because you can't think of a way to do it doesn't mean it can't be done.
Several electronic voting systems have been proposed that allow for verification while maintaining both ballot secrecy and receipt-freeness (see work by Chaum, Neff, and Naor & Moran for some examples). There has also been good work done on ensuring the hardware is free or side-channel attacks that might be used to do things like compromise the secrecy of the ballot. There are smart people working on these problems who know quite a bit more about crypto and the associated areas of secrecy, anonymity, verifiability, and adversarial behavior than you do. Try not to tell everyone they're wrong if you have no clue what it is that they're doing.
I'm guessing that those states where it was ruled unconstitutional, the photo ID had to be paid for by the voter (e.g. a drivers license or state ID). This is very much a poll tax, and thus unconstitutional. Depending on what other bits are in the various laws, I believe that requiring photo IDs that cost the voter nothing and are easy to obtain would be considered constitutional.
I'm sure there's various public/private key, hash algorithms, etc. that could allow for post-vote verifiability, but doesn't that go against the whole anonymous voting principle?
No, they don't.
Well, it's correct to say that there is tension between the two, and that one condition is satisfied much more easily if the other can be ignored (and there are many, often subtle, conditions in play with voting systems). However, there is room in the middle to play around and come up with solutions that satisfy those conditions. There are systems where the voter can get a valid, sound, non-transferrable proof that their vote was properly registered and counted without revealing the actual contents of their votes. For example, here is a very interesting proposal from Moni Naor and Tal Moran that offers some very strong properties (at the expense of efficiency, in this case), and there are others that offer similar results (again, look at the work of Chaum and Neff -- very good stuff).
The only way to really screw up a system like that is in the optical recognition software, which I'd hope is tested by poll workers before the polls actually open. And even then, with the paper ballots being retained inside, it's easy enough to do a manual recount.
Many counters have counting registers that can be set to start at any offset you like. Start one candidate at +X votes and the other at -Y and so long as X and Y are in the statistical noise you've done your part to help rig an election without giving anyone reason to call for a recount.
Now, given a properly designed electronic system with voter verifiability, any joe can head out to someone he trusts (his computer, the Library, the League of Women Voters, the local Republicrat party office, all of the above) and have them verify that his vote was registered correctly and added into the final count correctly, and you can catch cheating at a very fine level (of course we'd still need to define policy for how to launch an investigation, but evidence gathering can be done by anyone). You can't get that with paper.
1: So I vote and go home. The next day I want to check that my paper ballot vote was properly included in the final tally. I do this how? 2: If plexiglass were such a deterrent to observers, guys like David Copperfield would be out of a job.
Paper is more secure and flexible than an electronic machine in which there is no way to verify if your vote was recorded or recorded correctly.
Right. Which is why you would use a technique that allows verification by the voter and interested third parties, along with the other desirable properties such as privacy, receipt freeness, and proper mixing. Again, ignore the crap that Diebold is putting out that was known to be horribly broken years ago. Look instead at some of the recent work by guys like Chaum, Wagner, Neff, Moran and Naor. There's been a lot of goot thought put into voting. Not just as an act or an algorithm, but as an entire system.
1: Voter verifiability. With the paper ballots you don't really have an easy, effective way to verify that your vote was not only recorded properly, but that it was counted properly in the final tally. 2: Forgeability. It's still plenty easy to forge a stack of paper ballots. And such forgery is pretty undetectable if done properly.
Aw hell, one more. With paper ballots you still have the option of hacking the counting machine (starting one candidate at +X votes and the other guy at -Y votes, and you'll probably get away with it if X and Y are in the statistical noise. See point 1 above for why).
Now, you'll not hear me argue against the current set of machines that might not even be safe from my sister who's been known to get confused by the toaster, but I will argue that paper is not more secure, efficient, or flexible as a properly designed electronic system that had crypto and security experts involved from minute 1.
I love it when people talk loudly about things they don't understand. There are a number of information-theoretic secure constructs in cryptography that are unbreakable no matter how much computational might you bring to bear on the problem. One simple example is Shamir secret sharing (and the many variants) where you essentially have a system of equations with fewer equations than unknowns, thus like one time pads, every assignment is equally likely to be the correct solution to the problem.
Fewer companies will be willing to get sued like this once a few people start. And it'll stop.
You really think so? Chances are their damages in any case will be small (assuming they actually lose), so it could take a lot of these suits before they notice the effect. But to have lot s of suits, you have to have a lot of people who feel that a half a day spent in court (plus time for preparation) is worth more to them than the two seconds it takes to hang up the phone because it's being done for some "higher purpose". I sure as hell ain't one of those people -- I'm a bit more pragmatic than that.
I have a feeling that I'm going to be modded troll, but if you know how to program properly you can teach yourself any language without much difficulty
Not troll, though slightly naive (or at least overly optimistic) seems appropriate. While there is a common core that sort of transcends languages, there is a big enough gulf between certain languages that crossing over will likely take some difficulty. For example, I don't see much in C/C++ that will really help you easily pick up monads and arrows in Haskell, or the logic programming of Prolog, or the subtleties of functors, polymorphic variants, and private row types in OCaml's type system. And then you've got the concatenative languages like Joy and Forth which offer yet another disconnect. And of course there are languages like Erlang, Occam, and Pict to play around with too...
Of course the more you know, the more likely you may be to draw parallels and infer relationships, but some things might still require a good amount of work.
Slashdot Mirror
You lose significant quality in the second round of encoding.
Are there any studies that show what kind of a decrease in quality is realized by re-encoding, either with the same encoder/settings or with a different encoder?
Frankly, I can't hear a damn bit of difference between a burnt & re-riped track and it's original, but my ears are admittedly scarred by that demon rock and roll... Still, I don't believe this quality drop is very significant. I'd be a bit surprised to find a well run study that shows that it is.
In any case, you're free to not re-encode your files after burning them, or to use a lossless encoder. Apple even offers one that works on their iPods if you want to use it.
Yep. This pretty much guarantees that I won't be buying an iPhone.
During the keynote I was all "gimme, gimme, gimme!!!" But as rumors came out that it wouldn't be open to third-party developers iI became less and less interested. Now that those rumors are confirmed I'm frankly not that interested. I know Apple won't come out with as many useful apps as a full suite of independent developers would. And while one can still use whatever web-based apps will be out there, it's only a partial solution (and one that is useless if you're in a zone of poor to no coverage).
Sorry Apple. I might consider it at $200-250 or so, but not for 600.
If this is what I think it is, the tech behind TouchStream keyboards (they sold their IP to an unnamed company a couple of years back, and the scuttlebutt then was that Apple bought it for use with their iPods), then it should work very well. I love my TouchStream keyboards -- they're very accurate and responsive.
Yeah... I want to be waving around my 600$ phone with sweaty hands.
I don't know how well I will be able to type on it. I use my mobile device constantly for e-mail, IM, taking notes, and browsing. Tactile is something I have grown used to (touch typing). How will I handle no buttons?
Well, a couple of years back, when TouchStream got bought out, everyone suspected it was Apple that bought them with plans to incorporate the tech with the iPod controls -- it looks like this was likely the case. Now then, as for the how well it works for you, it will obviously vary from person to person, but pretty much everyone that uses a TouchStream keyboard loves them. You get used to the feel fairly quickly, and the gestures are the greatest thing in the world. I can't wait to get my hands on one and play with it.
Come on June!
For instance there was no way to intuitively of setting a printer into draft mode for quick printing. Come on!
Go to print anything. When the sheet drops down, use the third selection list to set the options the way you want them for draft printing. Once you have what you think is a good combination for drafts, use the second selection list (Presets) and select "Save as..." Choose an appropriate name, like "Draft". Now, whenever you want to print something in draft mode, just select "Draft" from the list of presets (if it wasn't already set as the current mode). And if you want to set up a 2-up draft mode with a hairline border around the subpages, that defaults to 3 collated copies and a cover page, set one of those up as well.
Now then, I suppose I could ask you why it's easier to install gvim on OS X than it is on Ubuntu...
Well, if you want a number of resellers will physically disable the camera for you. We needed to have that done where I work if we ever wanted to bring them in from the parking lot...
Or you could, you know, stick an index card or a Band-Aid or something over the lens...
Scheme is not Lisp, Scheme is Scheme.
Yes, it has it's roots in Lisp, and it looks a lot like Lisp, bit Scheme is no more Lisp than C# is C.
The Mac is supposed to be brain-dead simple. At least thats how it gets marketed...
/usr or /etc directories. They won't care about manually setting hidden preferences. They won't be looking for the Developer apps like Shark. They won't be wondering where to put this spiffy new preference pane that they downloaded and so on.
No. It's marketed as brain-dead simple for simple things (read: things your ordinary average user will be doing), but with a core that can be much more complex if you really want to be noodling about. The basic user won't really give a damn about what's in the
If you plan on developing for the machine, then yeah... you're going to have to do some work on your own to learn about the rest of the system... boo farking hoo. That's been the same for every OS since Basic ROMs went the way of the dinosaurs.
And, to be a bit less extreme, it's not even going to help you much if you move over to something like Prolog or Joy.
This appears to be yet another case of, "You can write Fortran in any language" where the author ignores that some technologies make it much easier to write Fortran than others. Obviously with a number of things you can avoid the bad stuff by avoiding the bad stuff -- but when bad stuff is the default mode of operation, rather than the odd, explicit corner case then yes... there's an issue.
Put another way, it's a lot easier to not write Fortran in Haskell than it is in C.
Its' doesn't exist.
Sure it does.
The book belongs to Samuel Its. It's Its' book; his name is written inside its cover.
What you say is entirely true, but it also applies to printed works and academic papers.
It does, but with printed material there tends to be that chain of trust in existence. Most people are willing to put some trust in Addison-Wesley or O'Reilly publishing to not put out junk (unfortunately this isn't the case everywhere -- see Apress' recent Practical OCaml for an example... whoof!). And a lot of the journals and conference proceedings have a higher sense of trust as they tend to be peer-reviewed and evaluated by others in the profession.
But still, you have your junk that sneaks in, or some journal that some guy publishes in his basement, and you do have to be careful there, as they benefit from that trust when they shouldn't.
Actually, I'm wondering how they measure judging the authoritativeness of a web site.
There are a number of things I could write about and slap them up on the internet for people to read, and while they would be quite factual and well written, someone not familiar with the subject would have a hard time telling if that were the case. After all, there's no reason to trust me -- most people haven't a clue who I am. And even if I were to add references, I could either make them to general works, or to obscure works that most people wouldn't bother to track down for verification.
The problem is even worse when you're dealing with sites like wikipedia. Some of the articles are indeed authoritative, some are utter crap, and some are in between. And of course there's the problem of authoritative articles that have been made subtly inaccurate.
It doesn't seem like the easiest thing to judge authoritativeness without some pre-existing knowledge or at least a chain of trust.
I love it when people say thing like "worthless idea" when they have no idea what they are talking about. Just because you can't think of a way to do it doesn't mean it can't be done.
Several electronic voting systems have been proposed that allow for verification while maintaining both ballot secrecy and receipt-freeness (see work by Chaum, Neff, and Naor & Moran for some examples). There has also been good work done on ensuring the hardware is free or side-channel attacks that might be used to do things like compromise the secrecy of the ballot. There are smart people working on these problems who know quite a bit more about crypto and the associated areas of secrecy, anonymity, verifiability, and adversarial behavior than you do. Try not to tell everyone they're wrong if you have no clue what it is that they're doing.
I'm guessing that those states where it was ruled unconstitutional, the photo ID had to be paid for by the voter (e.g. a drivers license or state ID). This is very much a poll tax, and thus unconstitutional.
Depending on what other bits are in the various laws, I believe that requiring photo IDs that cost the voter nothing and are easy to obtain would be considered constitutional.
I'm sure there's various public/private key, hash algorithms, etc. that could allow for post-vote verifiability, but doesn't that go against the whole anonymous voting principle?
No, they don't.
Well, it's correct to say that there is tension between the two, and that one condition is satisfied much more easily if the other can be ignored (and there are many, often subtle, conditions in play with voting systems). However, there is room in the middle to play around and come up with solutions that satisfy those conditions. There are systems where the voter can get a valid, sound, non-transferrable proof that their vote was properly registered and counted without revealing the actual contents of their votes. For example, here is a very interesting proposal from Moni Naor and Tal Moran that offers some very strong properties (at the expense of efficiency, in this case), and there are others that offer similar results (again, look at the work of Chaum and Neff -- very good stuff).
The only way to really screw up a system like that is in the optical recognition software, which I'd hope is tested by poll workers before the polls actually open. And even then, with the paper ballots being retained inside, it's easy enough to do a manual recount.
Many counters have counting registers that can be set to start at any offset you like. Start one candidate at +X votes and the other at -Y and so long as X and Y are in the statistical noise you've done your part to help rig an election without giving anyone reason to call for a recount.
Now, given a properly designed electronic system with voter verifiability, any joe can head out to someone he trusts (his computer, the Library, the League of Women Voters, the local Republicrat party office, all of the above) and have them verify that his vote was registered correctly and added into the final count correctly, and you can catch cheating at a very fine level (of course we'd still need to define policy for how to launch an investigation, but evidence gathering can be done by anyone). You can't get that with paper.
1: So I vote and go home. The next day I want to check that my paper ballot vote was properly included in the final tally. I do this how?
2: If plexiglass were such a deterrent to observers, guys like David Copperfield would be out of a job.
Paper is more secure and flexible than an electronic machine in which there is no way to verify if your vote was recorded or recorded correctly.
Right. Which is why you would use a technique that allows verification by the voter and interested third parties, along with the other desirable properties such as privacy, receipt freeness, and proper mixing. Again, ignore the crap that Diebold is putting out that was known to be horribly broken years ago. Look instead at some of the recent work by guys like Chaum, Wagner, Neff, Moran and Naor. There's been a lot of goot thought put into voting. Not just as an act or an algorithm, but as an entire system.
What is wrong with paper ballots?!!!??!?
Two things (off the top of my head)
1: Voter verifiability. With the paper ballots you don't really have an easy, effective way to verify that your vote was not only recorded properly, but that it was counted properly in the final tally.
2: Forgeability. It's still plenty easy to forge a stack of paper ballots. And such forgery is pretty undetectable if done properly.
Aw hell, one more. With paper ballots you still have the option of hacking the counting machine (starting one candidate at +X votes and the other guy at -Y votes, and you'll probably get away with it if X and Y are in the statistical noise. See point 1 above for why).
Now, you'll not hear me argue against the current set of machines that might not even be safe from my sister who's been known to get confused by the toaster, but I will argue that paper is not more secure, efficient, or flexible as a properly designed electronic system that had crypto and security experts involved from minute 1.
I love it when people talk loudly about things they don't understand. There are a number of information-theoretic secure constructs in cryptography that are unbreakable no matter how much computational might you bring to bear on the problem. One simple example is Shamir secret sharing (and the many variants) where you essentially have a system of equations with fewer equations than unknowns, thus like one time pads, every assignment is equally likely to be the correct solution to the problem.
Fewer companies will be willing to get sued like this once a few people start. And it'll stop.
You really think so? Chances are their damages in any case will be small (assuming they actually lose), so it could take a lot of these suits before they notice the effect. But to have lot s of suits, you have to have a lot of people who feel that a half a day spent in court (plus time for preparation) is worth more to them than the two seconds it takes to hang up the phone because it's being done for some "higher purpose". I sure as hell ain't one of those people -- I'm a bit more pragmatic than that.
Does this mean Safari will finally stop eating memory like a Langolier?
I have a feeling that I'm going to be modded troll, but if you know how to program properly you can teach yourself any language without much difficulty
Not troll, though slightly naive (or at least overly optimistic) seems appropriate. While there is a common core that sort of transcends languages, there is a big enough gulf between certain languages that crossing over will likely take some difficulty. For example, I don't see much in C/C++ that will really help you easily pick up monads and arrows in Haskell, or the logic programming of Prolog, or the subtleties of functors, polymorphic variants, and private row types in OCaml's type system. And then you've got the concatenative languages like Joy and Forth which offer yet another disconnect. And of course there are languages like Erlang, Occam, and Pict to play around with too...
Of course the more you know, the more likely you may be to draw parallels and infer relationships, but some things might still require a good amount of work.