I've known about this hole for about a year (yes I reported it to apple). The solution, which I use myself, is very simple. Do not run as sudo. I have two accouint. my everyday account and my sudo-user account. If you always run the installer as normal users then it will be forced to ask for a sudo-account name and password any time it needs to escalate privledges. There that's the fix.
If you always run as a sudo user then you are exposed to this hole. It's not techincally a hole, but most people would consider it an unexpected behaviour. Most people figure that if they don't give the installer their password then it can't be installing anything priveldged. Wrong, it is possible. But you were installing so....you sort of got what you asked for, but obviously it's ripe for a trojan.
The fix I give above simply forces the expected behaviour. If something wants to modify privledged files then it has to ask.
Now here's the nice thing. Unlike linux and windows, it is a perfectly pleasant experience for a poweruser to run as anormal user on a mac. I'd die if I had to have this dual account system on linux, since not having super user privs is a pain. KDE and GNOME try to help you with some operation, but it's so inconsisten you cant make it work well.
But on mac's it's nearly seemless. Anytime you need to authorize it pops up a window asking for a sudo account name. It's ubiquitous and there's virtually no time you need to be logged in as sudo-user. For extensive scrirpted or CLI coperations the terminal suffices to su to the sudo user. Now about once or twice a year, I find some situation where it is simpler to be in a GUI desktop as the sudo user. (one of those is fink-commander) For that there's fast user switching which lets me flip over to a logged in sudo GUI account instantly.
conway's Object oriented perl is a wonderful book. short but complete.
But only as long as you know perl well already and have toyed with the man pages first.
perl -we 'print "Big Tits" until 1==0' Is the epitomy of every first program.
Perl seems to fit the bill, since it can be as simple as you want and doesn't even have the type issues Basic has. Perl is happy to be procedural. When you are ready to step up to objectsperl is ready.
Object oriented perl is a wonderful way to learn objects. Wait don't scream. I said "learn". I'd been object oriented programming for years in Java and other languages. But I truly did not understand how all the pieces worked till I wrote perl objects. In perl it's like one of those "visible man" models. You learn how inheritance works. You learn how binding of an instance to a class works. You understand closures for the first time. You understand how the namespaces are kept separate and how instance memory is allocated. It's not just some voodoo that simply works, like in JAVA. Moreover all of the voodoo is not out of reach but right there for you to mess with. An instance can change it's own inheritance if you want it to. An instance can create a new method and write it into it's own namespace if it wants to. An instance can trap calls to it's own methods and redirect them or intercept calls to methods that don't exist and respond to them.
Those features are not unique to perl (for example pyhton implements objects identically to perl). The difference is that All of that object management occurs in perl itself and is not hidden behind syntactic sugar (like python and java). You quickly appreciate what dereferencing costs, etc...
The other thing that is nice about perl for learning is all of those prefixes like $ @, and so forth. They may make perl look like cursing but they force you to think about what a variable is. When I index out an array, I get what? an array? no I get a scalar, so $X[2] is how I index @X. You can look at someones perl program and if it's written well tell what every word is. You cannot look at a bare name in python or java and tell if it's a method, an array, a hash, a scalar or reference. Perl you can. (Oh and by the way let me explode a perl/pyhton myth. python has more special markup characters in use than perl, the main difference is that in python they are suffixes instead of prefixes and are overloaded with multiple meanings--try counting how many modifiers there are some time (e.g. () , [] ** and so on))
Now once you learn perl objects. Well it's time to put down the perl and back away slowly. Python, java are much better languages for writing re-usable, easily read, complex object oriented programs. Perl is still a much more powerful language than either. But it's powerful for efficiently creating compact or single use programs quickly. Not for well designed complex systems.
Perl is good language to start in, plus it's useful enough to work throughout your career. Basic is not.
Hey let's try another analogy.
I have a book under CC, translated into chinese. I could give you a xerox of the book, but since you don't have a chinese reader installed in your brain, it's as good as DRMd to you.
Did converting the book to chinese break the CC. No because the book is available in English or whatever elsewhere. Just because I have the chinese copy does not mean I have to supply you with the english copy on demand. Go find it yourself.
They are not preventing you from obtaining the creative commons file by other means. They are just not allowing you to transfer it over zune wireless.
Let's look at some analogies. I have the file on our shared disk in my home directory. You can see that it's there. but the protection on it is 660 and you are not in my group. So tough beans you can't play it. everyone in my group can. You just can't access it by my file server mechainsism because you don't have the password to unlock my files. Did I just DRM the file? No.
A bunch of people give my company some things for safe keeping. Some of them look like they might be unpublished manuscripts or confidential internal company documents. But I don't honestly know what they are. I'm allowed to look at them, and so are my employees. But I can't just share this with anyone. Maybe I can. But I don't know and better safe than sorry. So I lock them up.
Anyhow analogies suck, I know. The point is, that disallowed a file transfer is by some method does not break the creative commons as long as the file is available another way.
There's always a tension between, "should be let our benevolent governement set policy" and "should bee let industry trade groups find their own compromises". IN general usually the scheme is for the govt to threaten to take action is the trade groups dont stop acting like assholes. Then the tradegroups set up a workable policy. This happens almost daily and works very well for the most part. In some case it becomes an object of public ridicule but even then it's usually better than govt intervention. (for example, the voluntary rating systems on movies, and music are both laughable and yet fairly workable and certainly better than govt action).
So here's a case where it is not all happening in the confines of the US so the US is trying to advocate that less govt intervention is good as long as the industry seems to be making it work well.
What matters here is how hard the public complains. If they don't complain then the US has every right to believe that what apple is doing is a good compomise. If they do complain then they will push for some regulation.
That's of course the answer devoid of the cynical belief that corrupt politicians are pushing this for their coroporate masters. If you believe that then, sure, be skeptical. If you give them the benefit of the doubt then I'd say its not a bad thing to push for.
In the end what the US says is not law. They are advocating for restraint. Others can judge if it's warrnated inthe context of their nations.
Perl seems to fit the bill, since it can be as simple as you want and doesn't even have the type issues Basic has.
Object oriented perl is a wonderful was to learn objects. Wait don't scream. I said "learn". I'd been object oriented programming for years in Java and other languages. But I truly did not understand how all the pieces worked till I wrote perl objects. In perl it's like one of those "visible man" models. You learn how inheritance works. You learn how binding of an instance to a class works. You understand closures for the first time. You understand how the namespaces are kept separate and how instance memory is allocated. It's not just some voodoo that simply works, like in JAVA. Moreover all of the voodoo is not out of reach but right there for you to mess with. An instance can change it's own inheritance if you want it to. An instance can create a new method and write it into it's own namespace if it wants to. An instance can trap calls to it's own methods and redirect them or intercept calls to methods that don't exist and respond to them.
Those features are not unique to perl (for example pyhton implements objects identically to perl). The difference is that All of that object management occurs in perl itself and is not hidden behind syntactic sugar (like python and java). You quickly appreciate what dereferencing costs, etc...
The other thing that is nice about perl for learning is all of those prefixes like $ @, and so forth. They may make perl look like cursing but they force you to think about what a variable is. When I index out an array, I get what? an array? no I get a scalar, so $X[2] is how I index @X. You can look at someones perl program and if it's written well tell what every word is. You cannot look at a bare name in python or java and tell if it's a method, an array, a hash, a scalar or reference. Perl you can. (Oh and by the way let me explode a perl/pyhton myth. python has more special markup characters in use than perl, the main difference is that in python they are suffixes instead of prefixes and are overloaded with multiple meanings--try counting how many modifiers there are some time (e.g. () , [] ** and so on))
Now once you learn perl objects. Well it's time to put down the perl and back away slowly. Python, java are much better languages for writing re-usable, easily read, complex object oriented programs. Perl is still a much more powerful language than either. But it's powerful for efficiently creating compact or single use programs quickly. Not for well designed complex systems.
DSL linux boots screaminly fast on old hardware. While it loses some of it's advantage on faster hardware, it really can extend the useful life of older hardware. I put it on my wife's old P2 233mhz 196MB laptop and it boots faster than my new Xeon on Fedora running off the disk. (DSL boot time is 90 seconds). And the lightweight tools like the browser Dillo launch literally in a second, again much faster than firefox on my Xeon. (It does run firefox too )
I've tried a lot of Live CDs and I really like the simplicity of the way DSL can be customized and then the customizations stored on a USB or even on a web server. They make it so easy to do--almost no linux skills needed. So when you take your CD and boot any computer anywhere your personal configuration is loaded from remote server or USB stick.
One thing that will be really nice for your day is the nifty way the primary interface is simply icons on the desktop. No start menus to fuss with. just click to desktop icon. Yes I know other operating systems have desktop aliases. But they take on a greater role in DSL than in other OS. And setting up your dad with the few applications he needs is a snap. Even the package manager is the simplest I've used--no questions, just a few clicks.
DSL also is very parsimonious with screen real estate consumed by the desktop so that it can work well on small laptop screens.
The only thing about DSL that makes is hard to use for some people is that it it's folder navigation in the open and save dialogs is pretty dated. Much like windows 95. So you have to remember how to walk up and down directories in that old style. (I'd forgotten how awful that interface was by modern standards).
If that bothers you, you might want to step up to DSL's big brother "DSL-Not" which has a newer kernel and the apps use a more modern gnome style file browser. The downside is that on older hardware it boots slower.
well that's the question isn't it. Is the DRM in the player, in which case it could be made to work on Wine as long as all the OS hooks were present. Or is the DRM rooted in the OS. In which case it's unlikley Wine or Crossover would implement it. Which is it?
please correct me if I'm wrong but other then the intial authrorization, I think the only phone home that itunes does is to plug things for the mini-store advertisments at the bottom of the page. ANd you can turn that off. I don't think it runs services that phone hope besides the application itself. Perhaps on windows it's different than on macs?
These movies are locked to the latest DRM for WMV and WMA. The WMV and WMA players that Microsoft makes for Macintosh don't support the DRM component so you can't play them on anything but a windows machine.
What I wonder is whether this DRM is in the OS or in the player itself. If it is in the Player will Wine or Crossover office be able to play the movies on Linux and Mac without having a copy of the operating system?
One suspects that the long term trend, espeically with HDTV, is going to be DRM that flows all the way through the device driver, out the cable and to the screen. IN that case the DRM is going to have to reside in the OS and not the player application. So I suspect that Wine is not the answer.
But will it work for now to use the Video's without having to boot to Windows?
0) you can put it on an unlimited number of ipods that are synched to your computer. 1) Every itunes account can be shared by up to 5 computers. 2) an itunes account can be migrated from one computer to another (so if your computer dies your music does not) 3) you can burn an itunes song to a CD which will work on any computer (not sure about the video) 4) you can convert any song with AAC DRM to DRM free using iMovie on a macintosh. 5) you can convert any AAC DRM song to DRM free using Jhymm.
Reading-back the barcode presumably only gives me the number. 5124512451245124512451245124512451245124 But the vote I cast was not for a number, it was for a person. How am I (Joe Average Voter) supposed to make the translation between the selection of candidates I voted for and the encoded representation in the number.
Because the stand alone and third party scanners will translate it for you. And because if you can find just one ballot with one mistake then you know the bar codes cannot be trusted and have indisputable proof. Consequently the ballots will be recounted by the text.
Most of the time it's better to use the bar codes for data entry becuase the error rate will be lower and the speed faster than text scanning either by machine or by hand. As I said previously there are four points where the agreement between the bar code and text get's sampled so the likelihood of an error/fraud is small.
Even if you don't think it is small enough, then it certainly is still smaller than the competing DRE and optical scan discrepancies, which are less thoughly checked.
There are not multiple authoritative records in use. Just one, the text. And there is a defined hierarchy of dispute resolution. The existence of records to check against means that no one can rig any one part of the system. ANd since the ballots can even be scanned by thrid parties, or photgraphed, there's lots of checks on the system accuracy.
I can't find one of your objections that has not been highly considered in the design of the OVC system.
Actually the whole point of the OVC system, including the bar code is that it allows transparent operation my mininally trained people and general understanding by the public. There's multiple checks and balances.
For example, the bar code to human text is validated in four ways. first it's validated in the creation process. Second, any voter can swipe the bar code on an independent stand-alone machine for playback before casting the vote. Third, Since the voter does not have to cast the ballot they can leave the poll with the completed but not cast ballot. Any third party outside the poll can swipe the barcode and vaidate it for the voter. Fourth, at the end of the day the every single bar code is swiped by a human. The humans can also see the plain text of the ballot they are swiping. Thus they can validate as many ballots as they choose to.
Thus this is very transparent to voters and poll workers and allows third party validation. it avoids the complexity of OCR which is not only error prone but too slow for bulk ballot reading. And it allows the possibility of embedding security features if one desires.
The OVC system does not rely on software openeness for secure operation. The voter still has a paper ballot they can verify. The votes are recored twice. Once by the ballot creation machine, which does not record the totals just the existence of the ballot and it's contents. (it might not get cast). The paper ballot is then in the hands of the voter before being cast. The cast ballots are counted on a separate machine. Every cast ballot must match a created ballot so ballot box stuffing is very difficult.
Then of course there's the fact the source code is open. That is a lot of reassurance to the candidates and to the voters. But it's main value is to the government not to the voter. The open source allows the governement to have third party maintainers and avoid lock-in, or slow service. It also allows multiple organizations to build and maintain compatible equipment by using the OVC software standard.
It's a wiki for creation collborators with access not for the public. editing actual html imposes a structure on the document that has to be follwoed whereas a wiki adapts. And the wiki is easily maintain and portable since it self contained, not a collection of linked html files with specific directory structure.
Interesting that you react so viscerally to it. Anyhow I think the point of the tiddly wiki was
1) it's a wiki, even if the current presentation is linear, others can add comment and side articles.
2) it's a client side wiki you can download and edit yourself and redistribute. Yes, you get the whole wiki engine--no server needed.
3) there's no server side CGI. thus for poor organizations like verified voting new mexico which can't maintaintheir own server or sys admins, the tiddly wiki lets them have a wiki that runs on the client.
4) development of nice looking yet flexible pages is fast an easy in tiddly wiki.
So yeah for a industrial web site maybe an CGI wiki is nice. But if you want people to steal your content and redistribute it and you want rapid deveolpment with wiki flexibility to add non-minear content then it's heard to beat web 2.0 tricks.
The issue here is that previously a software hack on the memory card was shown last year. The hrutsi attack was successful done on a live voting machine that altered the votes and no election official test could show it was rigged. Diebold called the attack purely hypothetical and said it could neve be done in reality since access to the memory card is impossible due to seals and oversight. Well high speed, non-techincal attack, espeically in light of the sleep-over system sort of makes a mockery of that. That is why it is news.
Slashdot Mirror
I've known about this hole for about a year (yes I reported it to apple). The solution, which I use myself, is very simple. Do not run as sudo. I have two accouint. my everyday account and my sudo-user account. If you always run the installer as normal users then it will be forced to ask for a sudo-account name and password any time it needs to escalate privledges. There that's the fix.
If you always run as a sudo user then you are exposed to this hole. It's not techincally a hole, but most people would consider it an unexpected behaviour. Most people figure that if they don't give the installer their password then it can't be installing anything priveldged. Wrong, it is possible. But you were installing so....you sort of got what you asked for, but obviously it's ripe for a trojan.
The fix I give above simply forces the expected behaviour. If something wants to modify privledged files then it has to ask.
Now here's the nice thing. Unlike linux and windows, it is a perfectly pleasant experience for a poweruser to run as anormal user on a mac. I'd die if I had to have this dual account system on linux, since not having super user privs is a pain. KDE and GNOME try to help you with some operation, but it's so inconsisten you cant make it work well.
But on mac's it's nearly seemless. Anytime you need to authorize it pops up a window asking for a sudo account name. It's ubiquitous and there's virtually no time you need to be logged in as sudo-user. For extensive scrirpted or CLI coperations the terminal suffices to su to the sudo user. Now about once or twice a year, I find some situation where it is simpler to be in a GUI desktop as the sudo user. (one of those is fink-commander) For that there's fast user switching which lets me flip over to a logged in sudo GUI account instantly.
It's painless.
suppose you were to post the encrypted file on the web? anyone can download it. Only the chosen can play it. now what's the difference?
conway's Object oriented perl is a wonderful book. short but complete. But only as long as you know perl well already and have toyed with the man pages first.
Anyone can zip and password protect a CC file. Does this mean Zip is a problem or the Zipper?
Is Zune the problem, or the guy who put the CC file on his Zune player?
So who broke the law, the guy who translated it, the guy who paid for the translation, or the guy who bought the translation.
perl -we 'print "Big Tits" until 1==0' Is the epitomy of every first program.
Perl seems to fit the bill, since it can be as simple as you want and doesn't even have the type issues Basic has. Perl is happy to be procedural. When you are ready to step up to objectsperl is ready.
Object oriented perl is a wonderful way to learn objects. Wait don't scream. I said "learn". I'd been object oriented programming for years in Java and other languages. But I truly did not understand how all the pieces worked till I wrote perl objects. In perl it's like one of those "visible man" models. You learn how inheritance works. You learn how binding of an instance to a class works. You understand closures for the first time. You understand how the namespaces are kept separate and how instance memory is allocated. It's not just some voodoo that simply works, like in JAVA. Moreover all of the voodoo is not out of reach but right there for you to mess with. An instance can change it's own inheritance if you want it to. An instance can create a new method and write it into it's own namespace if it wants to. An instance can trap calls to it's own methods and redirect them or intercept calls to methods that don't exist and respond to them.
Those features are not unique to perl (for example pyhton implements objects identically to perl). The difference is that All of that object management occurs in perl itself and is not hidden behind syntactic sugar (like python and java). You quickly appreciate what dereferencing costs, etc...
The other thing that is nice about perl for learning is all of those prefixes like $ @, and so forth. They may make perl look like cursing but they force you to think about what a variable is. When I index out an array, I get what? an array? no I get a scalar, so $X[2] is how I index @X. You can look at someones perl program and if it's written well tell what every word is. You cannot look at a bare name in python or java and tell if it's a method, an array, a hash, a scalar or reference. Perl you can. (Oh and by the way let me explode a perl/pyhton myth. python has more special markup characters in use than perl, the main difference is that in python they are suffixes instead of prefixes and are overloaded with multiple meanings--try counting how many modifiers there are some time (e.g. () , [] ** and so on))
Now once you learn perl objects. Well it's time to put down the perl and back away slowly. Python, java are much better languages for writing re-usable, easily read, complex object oriented programs. Perl is still a much more powerful language than either. But it's powerful for efficiently creating compact or single use programs quickly. Not for well designed complex systems.
Perl is good language to start in, plus it's useful enough to work throughout your career. Basic is not.
Hey let's try another analogy. I have a book under CC, translated into chinese. I could give you a xerox of the book, but since you don't have a chinese reader installed in your brain, it's as good as DRMd to you. Did converting the book to chinese break the CC. No because the book is available in English or whatever elsewhere. Just because I have the chinese copy does not mean I have to supply you with the english copy on demand. Go find it yourself.
They are not preventing you from obtaining the creative commons file by other means. They are just not allowing you to transfer it over zune wireless.
Let's look at some analogies.
I have the file on our shared disk in my home directory. You can see that it's there. but the protection on it is 660 and you are not in my group. So tough beans you can't play it. everyone in my group can. You just can't access it by my file server mechainsism because you don't have the password to unlock my files. Did I just DRM the file? No.
A bunch of people give my company some things for safe keeping. Some of them look like they might be unpublished manuscripts or confidential internal company documents. But I don't honestly know what they are. I'm allowed to look at them, and so are my employees. But I can't just share this with anyone. Maybe I can. But I don't know and better safe than sorry. So I lock them up.
Anyhow analogies suck, I know. The point is, that disallowed a file transfer is by some method does not break the creative commons as long as the file is available another way.
There's always a tension between, "should be let our benevolent governement set policy" and "should bee let industry trade groups find their own compromises". IN general usually the scheme is for the govt to threaten to take action is the trade groups dont stop acting like assholes. Then the tradegroups set up a workable policy. This happens almost daily and works very well for the most part. In some case it becomes an object of public ridicule but even then it's usually better than govt intervention. (for example, the voluntary rating systems on movies, and music are both laughable and yet fairly workable and certainly better than govt action).
So here's a case where it is not all happening in the confines of the US so the US is trying to advocate that less govt intervention is good as long as the industry seems to be making it work well.
What matters here is how hard the public complains. If they don't complain then the US has every right to believe that what apple is doing is a good compomise. If they do complain then they will push for some regulation.
That's of course the answer devoid of the cynical belief that corrupt politicians are pushing this for their coroporate masters. If you believe that then, sure, be skeptical. If you give them the benefit of the doubt then I'd say its not a bad thing to push for.
In the end what the US says is not law. They are advocating for restraint. Others can judge if it's warrnated inthe context of their nations.
perl -we 'print "Big Tits" until 1==0'
Perl seems to fit the bill, since it can be as simple as you want and doesn't even have the type issues Basic has.
Object oriented perl is a wonderful was to learn objects. Wait don't scream. I said "learn". I'd been object oriented programming for years in Java and other languages. But I truly did not understand how all the pieces worked till I wrote perl objects. In perl it's like one of those "visible man" models. You learn how inheritance works. You learn how binding of an instance to a class works. You understand closures for the first time. You understand how the namespaces are kept separate and how instance memory is allocated. It's not just some voodoo that simply works, like in JAVA. Moreover all of the voodoo is not out of reach but right there for you to mess with. An instance can change it's own inheritance if you want it to. An instance can create a new method and write it into it's own namespace if it wants to. An instance can trap calls to it's own methods and redirect them or intercept calls to methods that don't exist and respond to them.
Those features are not unique to perl (for example pyhton implements objects identically to perl). The difference is that All of that object management occurs in perl itself and is not hidden behind syntactic sugar (like python and java). You quickly appreciate what dereferencing costs, etc...
The other thing that is nice about perl for learning is all of those prefixes like $ @, and so forth. They may make perl look like cursing but they force you to think about what a variable is. When I index out an array, I get what? an array? no I get a scalar, so $X[2] is how I index @X. You can look at someones perl program and if it's written well tell what every word is. You cannot look at a bare name in python or java and tell if it's a method, an array, a hash, a scalar or reference. Perl you can. (Oh and by the way let me explode a perl/pyhton myth. python has more special markup characters in use than perl, the main difference is that in python they are suffixes instead of prefixes and are overloaded with multiple meanings--try counting how many modifiers there are some time (e.g. () , [] ** and so on))
Now once you learn perl objects. Well it's time to put down the perl and back away slowly. Python, java are much better languages for writing re-usable, easily read, complex object oriented programs. Perl is still a much more powerful language than either. But it's powerful for efficiently creating compact or single use programs quickly. Not for well designed complex systems.
perhaps but I suspect it's a fork Quota per parent. And it exits almost immediately.
Yes, and web statistics show most people use Internet Explorer so that must be the best Browser.
Trying this on macosx, the bomb dies when the number of forks exceeds a certain depth. So it's harmless. :(){ :|:& };:
$ bash: fork: Resource temporarily unavailable
bash fork Resource temporarily unavailable
bash fork Resource temporarily unavailable
bash fork Resource temporarily unavailable
bash fork Resource temporarily unavailable
bash fork Resource temporarily unavailable
bash fork Resource temporarily unavailable
bash fork Resource temporarily unavailable
Done
DSL linux boots screaminly fast on old hardware. While it loses some of it's advantage on faster hardware, it really can extend the useful life of older hardware. I put it on my wife's old P2 233mhz 196MB laptop and it boots faster than my new Xeon on Fedora running off the disk. (DSL boot time is 90 seconds). And the lightweight tools like the browser Dillo launch literally in a second, again much faster than firefox on my Xeon. (It does run firefox too )
I've tried a lot of Live CDs and I really like the simplicity of the way DSL can be customized and then the customizations stored on a USB or even on a web server. They make it so easy to do--almost no linux skills needed. So when you take your CD and boot any computer anywhere your personal configuration is loaded from remote server or USB stick.
One thing that will be really nice for your day is the nifty way the primary interface is simply icons on the desktop. No start menus to fuss with. just click to desktop icon. Yes I know other operating systems have desktop aliases. But they take on a greater role in DSL than in other OS. And setting up your dad with the few applications he needs is a snap. Even the package manager is the simplest I've used--no questions, just a few clicks.
DSL also is very parsimonious with screen real estate consumed by the desktop so that it can work well on small laptop screens.
The only thing about DSL that makes is hard to use for some people is that it it's folder navigation in the open and save dialogs is pretty dated. Much like windows 95. So you have to remember how to walk up and down directories in that old style. (I'd forgotten how awful that interface was by modern standards).
If that bothers you, you might want to step up to DSL's big brother "DSL-Not" which has a newer kernel and the apps use a more modern gnome style file browser. The downside is that on older hardware it boots slower.
well that's the question isn't it. Is the DRM in the player, in which case it could be made to work on Wine as long as all the OS hooks were present. Or is the DRM rooted in the OS. In which case it's unlikley Wine or Crossover would implement it. Which is it?
please correct me if I'm wrong but other then the intial authrorization, I think the only phone home that itunes does is to plug things for the mini-store advertisments at the bottom of the page. ANd you can turn that off. I don't think it runs services that phone hope besides the application itself. Perhaps on windows it's different than on macs?
These movies are locked to the latest DRM for WMV and WMA. The WMV and WMA players that Microsoft makes for Macintosh don't support the DRM component so you can't play them on anything but a windows machine.
What I wonder is whether this DRM is in the OS or in the player itself. If it is in the Player will Wine or Crossover office be able to play the movies on Linux and Mac without having a copy of the operating system?
One suspects that the long term trend, espeically with HDTV, is going to be DRM that flows all the way through the device driver, out the cable and to the screen. IN that case the DRM is going to have to reside in the OS and not the player application. So I suspect that Wine is not the answer.
But will it work for now to use the Video's without having to boot to Windows?
0) you can put it on an unlimited number of ipods that are synched to your computer.
1) Every itunes account can be shared by up to 5 computers.
2) an itunes account can be migrated from one computer to another (so if your computer dies your music does not)
3) you can burn an itunes song to a CD which will work on any computer (not sure about the video)
4) you can convert any song with AAC DRM to DRM free using iMovie on a macintosh.
5) you can convert any AAC DRM song to DRM free using Jhymm.
Does that answer your question?
Reading-back the barcode presumably only gives me the number. 5124512451245124512451245124512451245124 But the vote I cast was not for a number, it was for a person. How am I (Joe Average Voter) supposed to make the translation between the selection of candidates I voted for and the encoded representation in the number.
Because the stand alone and third party scanners will translate it for you. And because if you can find just one ballot with one mistake then you know the bar codes cannot be trusted and have indisputable proof. Consequently the ballots will be recounted by the text.
Most of the time it's better to use the bar codes for data entry becuase the error rate will be lower and the speed faster than text scanning either by machine or by hand. As I said previously there are four points where the agreement between the bar code and text get's sampled so the likelihood of an error/fraud is small.
Even if you don't think it is small enough, then it certainly is still smaller than the competing DRE and optical scan discrepancies, which are less thoughly checked.
There are not multiple authoritative records in use. Just one, the text. And there is a defined hierarchy of dispute resolution. The existence of records to check against means that no one can rig any one part of the system. ANd since the ballots can even be scanned by thrid parties, or photgraphed, there's lots of checks on the system accuracy.
I can't find one of your objections that has not been highly considered in the design of the OVC system.
May I steal that idea? Seriously, I give talks on this form time to time and that's a beautiful visual example.
Actually the whole point of the OVC system, including the bar code is that it allows transparent operation my mininally trained people and general understanding by the public. There's multiple checks and balances.
For example, the bar code to human text is validated in four ways. first it's validated in the creation process. Second, any voter can swipe the bar code on an independent stand-alone machine for playback before casting the vote. Third, Since the voter does not have to cast the ballot they can leave the poll with the completed but not cast ballot. Any third party outside the poll can swipe the barcode and vaidate it for the voter. Fourth, at the end of the day the every single bar code is swiped by a human. The humans can also see the plain text of the ballot they are swiping. Thus they can validate as many ballots as they choose to.
Thus this is very transparent to voters and poll workers and allows third party validation. it avoids the complexity of OCR which is not only error prone but too slow for bulk ballot reading. And it allows the possibility of embedding security features if one desires.
The OVC system does not rely on software openeness for secure operation. The voter still has a paper ballot they can verify. The votes are recored twice. Once by the ballot creation machine, which does not record the totals just the existence of the ballot and it's contents. (it might not get cast). The paper ballot is then in the hands of the voter before being cast. The cast ballots are counted on a separate machine. Every cast ballot must match a created ballot so ballot box stuffing is very difficult.
Then of course there's the fact the source code is open. That is a lot of reassurance to the candidates and to the voters. But it's main value is to the government not to the voter. The open source allows the governement to have third party maintainers and avoid lock-in, or slow service. It also allows multiple organizations to build and maintain compatible equipment by using the OVC software standard.
good point. thanks.
It's a wiki for creation collborators with access not for the public. editing actual html imposes a structure on the document that has to be follwoed whereas a wiki adapts. And the wiki is easily maintain and portable since it self contained, not a collection of linked html files with specific directory structure.
Interesting that you react so viscerally to it. Anyhow I think the point of the tiddly wiki was 1) it's a wiki, even if the current presentation is linear, others can add comment and side articles. 2) it's a client side wiki you can download and edit yourself and redistribute. Yes, you get the whole wiki engine--no server needed. 3) there's no server side CGI. thus for poor organizations like verified voting new mexico which can't maintaintheir own server or sys admins, the tiddly wiki lets them have a wiki that runs on the client. 4) development of nice looking yet flexible pages is fast an easy in tiddly wiki. So yeah for a industrial web site maybe an CGI wiki is nice. But if you want people to steal your content and redistribute it and you want rapid deveolpment with wiki flexibility to add non-minear content then it's heard to beat web 2.0 tricks.
No one can tell the difference between a rigged election, an error, and an unexpected outcome. All of those are known to have happened.
The issue here is that previously a software hack on the memory card was shown last year. The hrutsi attack was successful done on a live voting machine that altered the votes and no election official test could show it was rigged. Diebold called the attack purely hypothetical and said it could neve be done in reality since access to the memory card is impossible due to seals and oversight. Well high speed, non-techincal attack, espeically in light of the sleep-over system sort of makes a mockery of that. That is why it is news.