One has to ask what the market sector is here since it is inconvenient for both developers and users. And it seems to me it is, perhaps obviously, only going to be people who have to have contracts with companies that don't use iphones.
That is to say, as a user there is the problem that I can't update my iphone easily. Each time I try there's a high likelihood my jailbreak will bust. And it's also possible my non-apple approved applications will also break. So there's no assured path forward when there is a pressing need to update the phone comes along. even trivial issues could become strong motivations to update: for example perhaps I need a new verison of quiktime to view some new content I want to see.
And for developers. Well why bother when there is the android market beckoning. Surely that market is going to swamp the jailbroken iphone market shortly.
So my feeling is that this ecosystem is going to shrink not grow with time as android takes over and apple issues enough annoying needful updates.
* OS X has a pretty big hole: any admin user account can write to the Applications directory willy-nilly. Just like with Windows, people tend to use admin accounts for day-to-day work. From a high-level perspective, Vista does more things right than OS X does
It's true admin users can write to the app folder and even some worse stuff. Which is why people should not run as admin users all the time.
The difference in my experience is that running as a non-admin user on a mac is pleasant. If you have both an admin and non-admin account then life is good when you run as non-admin. anytime you need privledges it asks you for the admin user id and password. it's not disruptive.
I have not tried win 7 so I don't know if things have gotten better but it used to be that On windows doing simple things (like changing the clock time) often required admin access. Worse, many install applications would simply go belly up and die unless you were running as admin.
in otherwords being non-admin was the excpetion to the rule on windows to the point where it was painful to even try.
Now *nix folks have a bit of this problem as well. I've had many an makefile that would not run correctly unless you were root. (and many of those fail on NFS because of rootsquashing!).
On macs people tend to frequently run as admins by default not because they need to but because that's how an out of the box mac sets up the first account. The nice thing is that it's well worked out for the non-admin user.
OSX has both the unix permissions and something like the UAC.
I find the UAC so mind boggling I don't use it. Some applications seem to respect it and some don't. e.g. if you can't do something in a Finder window, sometimes you can do it in a terminal window. I have not figured out what the pattern is or if the UAC are there to allow actual secure protection or just guard railings to keep the riff raff from doing stupid things.
I suspect the Windows folks would say the UAC is just guard railings not actual security.
And don't get me wrong. Bash has it's uses. Space efficiency is important as you point out. And in my original post I said I was talking about scripting not interactivity. Bash is more convenient for interactivity as well.
My point was I don't see why bash persists in scripts.
shell script is preferable to perl because it's easier to read, easier to write reasonably, and has a low overhead cost. your "1000 times slower" number is a figment of your imagination.
Write a loop that iterates over 100000 short files. for each file run an awk script, a sed script on the result and a grep.
See you tommorrow.
or you could use perl and have it done in ten minutes.
Okay now suppose you wanted to perhaps have an exception test for the killall or the askmara. Or suppose you wanted to have a time-out if they never returned. Finally assume you wanted to log the result of the action. Maybe you want to use a command line variable to supply say a password and the number of retries.
Yes you could do all that in shell script. it simply is easier in perl.
your assurance that your perlscripts will run is that the first line of the perl program specifies which perl interpreter to use. if it requires 5.6 you tell it to use 5.6
The original point of perl is to address your concerns. You want to be close the machine (in the unix not the C sense) but you want enough high level functionality. And you want to chain stuff.
Perl is the ultimate glue language. it's not so lovely as python or ruby but it's much more adapted for glueing and staying as close to shell scripting as possible. At the same time it has nice libraries that mean it can do so much more if you need to go there.
Your forkbomb script is rather a pointless action as I'm sure you are aware.
if you are parsing text or doing any sort of complicated extractions you have to repeatedly use grep awk and sed in bash to accomplish the job. repeatedly launching these in aprogram can produce something that is easily 100-1000 times slower than the equivalent perl would be.
thus the window of usefulness for a scripting language is extended three orders of magnitude.
for example, let's say the ease of use of scripting means that until a program runs longer than, say, ten minutes to do a job you will prefer script over compiled lnaguages. the equivalent bash program if it does any serious parsing might take 3 hours. This is why one might still use a script language even when "speed" is an issue.
moreover, for any complex set of operations, expressing the logic is always simpler in perl. Yet the syntax is almost the same.
hence I wondered why shell script is used given perl seems to be always preferebale for any use.
I've never fully understood why bash is used anymore when perl is around.
No I'm not trolling. in most applications that take a significant amount of time to run, perl is orders of magnitude faster than equivalent and akward bash script.
the syntax of perl is sufficiently close to bash that anyone fluent is bash ought to have little trouble with moving to perl.
So in total seriousness, what is the point of using bash for scripting?
So that's about as many man hours as it would take to build every skyscraper in the world.
One is tempeted to snark something like "what a waste of manpower" but chances are those folks would not be puting that lost time to productive use but instead idle hands would find the devils work. So perhaps another way to say this is that something like a billion petty crimes were prevented.
The real reason for this change is that there are tools that rip the old Windows Media stream and let you save the instant movies on your computer. So far I haven't seen a similar tool for the Silverlight streams.
I suspect they were not really worried about that. If you want to rip a movie you rip the DVD. Ripping a netflix stream would just produce a bad resolution movie, no dolby 5.1, and glitches.
The real reason I think is, ironicaly customer service and a path forward on DRM.
with silver light they can service both mac and pc and eventually linux users with one application instead of 3.
Microsoft is pouring money into silver light, and one assumes they are responsive to the needs of earlier adopters. Netflix could probably get more of the changes they need from microsoft silverlight than an entrenched microsoft product. likewise for flash. Better to be the big fish in the small pond than a small fish in a big pond if you are seeking impact.
I've used both the services for a mac, as well as a PC (running in virtualbox) the original PC version, early mac beta and the silver light versions on PC and mac.
The silver light version normalize the experience on the mac and pc. unfortunately it's equally sucky now.
with the old version there were a bunch of hidden diagnostics you could pull up. You could even overide the automatic data rate selection, which was helpful if you wanted to force downgrade it when your connection was having intermittencies.
with the diagnostics you could determine which times it sucked because Netflix was not delivering and which times it sucked because comcast was sending it on a DNS wild goosechase through slow pipes.
with the new one you never know who to blame when it sucks. Which is to me more frustrating even if then net outcome-- gaps in my movie and bad resolution-- is the same.
Multi-core and multi-cpu programming is the future. I include GPUs in this. And programming these using existing tools is sub optimal.
But it's a catch 22. Few people are going to get their fingers wet in GPU programming without bridge tools like CUDA and fortran wrappers that make it less painful to change over hardcore math libraries. Yet at the same time the resulting code is sub optimal. for example the zeroth order in tools in CUDA sweep the matrix multiply back from the GPU to the CPU memory-- which is not what you want if you are dooing two consecutive matrix multiples. But it gets you started. (I note that more advanced, less library bound, cuda programming get's around this, but only a fool would invest the time learn it before trying the simple way).
Cell programming is another knotch up in difficulty. So sub-optimal convestion approaches may not work well. You really need to program for the CELL. No one really is perfectly sure what the best way to exploit these things is.
I suspect SONY wants people to commit to figuring the CELL out rather than giving them tools to simply do ports. This is what he meant I think by "increasing quality".
I also suspect this means that games produced form the CELL wont back port easily since it will be so architecture specific. Which is also good for sony.
In the meantime if they sell half as many units as xbox 360, yet 100% of the game profits rather than say 10% of the came profits go to sony and committed exclusive cell programmers, SONY is coming out ahead.
Uh did you actually look at the well-sourced article pointing out how bad these sources are. One of them published a piece saying "58% of ipod owners may choose zune".
Of course they're going to pass the fees on to customers. What else are they going to do, hold a bake sale?
Right.
I think it's a fine idea. the spectrum is public land. You rent it you don't give it away. This is a point that both conservatives and socialists totally agree upon. It's the bought off congressmen who were out to sell it.
There have been exceptions to this of course. When you want a resource exploited you do sell it. For example, getting railroads built wiht land grants. Or the 1872 mining law.
But now a century later the 1872 mining law seems like a huge mistake to continue. And yet that's pretty much exactly what the "drill now" folks want to do.
The secret is to lease it and price it right. It's not that hard to do.
A copyright allows the denial of a particular use of the material. Example, GNU denies the right to redistribute GNU lic software unless you meet certain conditions, like opening your own source.
What is the difference between you reading your book aloud, and a machine reading it aloud? And why is one subject to an additional license on top of having purchased the book when the other isn't?
Simple. because one is being sold and the other isn't. You might as well ask, why can't I do the following.
1) buy one copy of the print version. 2) record an actor reading it 3) sell as many copies of the recording as I please and not pay the author a dime.
furthermore to tighten the analogy, instead do this.
4) for every audio-version I sell, I buy one copy of the paper or e-book edition.
that way the author is getting the e-book roylaty rate and I'm pocketing the audio book rate.
Clearly this is unacceptable.
Now if you read the article you know this is not about stopping you from readin out loud or even reading out loud to another person. Or even a librarian reading to a class. it's about sales of audio books while paying e-book royalty rates.
One could say that audio books contain more labor and this is part of why they cost more. Once a technology comes along that removes that labor they should cost less.
That is true, but it misses the point.
Thus the real statement of the quesiton is this: if the manufacturing cost of books and audio books goes down then clearly the price of these should fall. But since audo books and e-books have different roylaty rates, if you change their ratio then you chance the total earnings to the authors. thus you need to re-adjust the roylaty rates so that the authors get the same total earnings.
Why should you want to assure authors get the same as before: when you sum up the total earnings (revenue minus cost of production) for books this get's divided amongst the publishers and authors. There is some dynamic equilibrium of what is neccessary to pay authors to entice a sufficient number of them to produce the books you want. e.g. if authors got no money, there would be fewer books written (not zero of course, but there could be no professional authors at all!)
If you want to argue that authors are paid to much then you have to prove that their is artificial scarcity of authors. good luck!
So in the end there has to be some fixed amount of money flowing to authors to maintain this status quo.
Blout is saying that if you canablaize a high profit audio book sale with a low-profit e-book sale then you simply need to charge more for e-books to make the total for the authors come out the same as before.
it's okay if the overall price declines. indeed this is great since it may increase sales. But in the end you can't simply lower the price by lowering the author's roylaties.
Decent TTS in a widely-used device will basically kill the audiobook market, and authors should be compensated in some way...
This is only true if you assume that there are people out there who would buy both the eBook AND the audio book if there was no TTS. Otherwise eBook sales aren't causing a loss of sales in the audio book market, they are merely replacing those sales.
I own a few books as audio books (usually bought before a long drive somewhere), and even in the cases of the really good ones, I've never felt a burning desire to buy the book again in print.
E-books sell for less than half to a quarter of audio book CD prices and fewer copies are sold. the ratio is enormous-- the Audio book market is 1000 times larger than the e-book market.
hence replacing 1-for-1 an audiobook with an e-book would cut the income by 1/2 or 1/4. Moreover if the author reads his own book, then his roylaties are even higher so the loss is maginified further.
you might wonder why then a publisher would be willing to sell if it represents a loss of revenue. The answer is that the e-book publisher and the audio book publisher are not the same person. the audio book publisher might be horrified that his sales are canialized by cheap e-baook sales, but from the e-book publisher's point of view it's a chance to expand their market 100 fold.
Slashdot Mirror
One has to ask what the market sector is here since it is inconvenient for both developers and users. And it seems to me it is, perhaps obviously, only going to be people who have to have contracts with companies that don't use iphones.
That is to say, as a user there is the problem that I can't update my iphone easily. Each time I try there's a high likelihood my jailbreak will bust. And it's also possible my non-apple approved applications will also break. So there's no assured path forward when there is a pressing need to update the phone comes along. even trivial issues could become strong motivations to update: for example perhaps I need a new verison of quiktime to view some new content I want to see.
And for developers. Well why bother when there is the android market beckoning. Surely that market is going to swamp the jailbroken iphone market shortly.
So my feeling is that this ecosystem is going to shrink not grow with time as android takes over and apple issues enough annoying needful updates.
is the answer to this question "no"?
If you want to answer a question without understanding the question then how do you know when the question can be answered?
I just applied to get my iphone sdk. I clicked the box to be an iphone developer, and got the confrim e-mail in 1 minute.
am I missing something?
Examples
# ls -le
-rw-r--r--+ 1 juser wheel 0 Apr 28 14:06 file1
owner: juser
1: guest deny read
2: admin allow write,delete
3: juser inherited deny delete
4: admin inherited allow delete
5: backup inherited deny read
6: admin inherited allow write-security
# chmod +ai "others allow read" file1
# ls -le
-rw-r--r--+ 1 juser wheel 0 Apr 28 14:06 file1
owner: juser
1: guest deny read
2: admin allow write,delete
3: juser inherited deny delete
4: others inherited allow read
5: admin inherited allow delete
6: backup inherited deny read
7: admin inherited allow write-security
I suspect digital broadcast TV is going to swing the pendulum back a bit.
* OS X has a pretty big hole: any admin user account can write to the Applications directory willy-nilly. Just like with Windows, people tend to use admin accounts for day-to-day work. From a high-level perspective, Vista does more things right than OS X does
It's true admin users can write to the app folder and even some worse stuff. Which is why people should not run as admin users all the time.
The difference in my experience is that running as a non-admin user on a mac is pleasant. If you have both an admin and non-admin account then life is good when you run as non-admin. anytime you need privledges it asks you for the admin user id and password. it's not disruptive.
I have not tried win 7 so I don't know if things have gotten better but it used to be that On windows doing simple things (like changing the clock time) often required admin access. Worse, many install applications would simply go belly up and die unless you were running as admin.
in otherwords being non-admin was the excpetion to the rule on windows to the point where it was painful to even try.
Now *nix folks have a bit of this problem as well. I've had many an makefile that would not run correctly unless you were root. (and many of those fail on NFS because of rootsquashing!).
On macs people tend to frequently run as admins by default not because they need to but because that's how an out of the box mac sets up the first account. The nice thing is that it's well worked out for the non-admin user.
OSX has both the unix permissions and something like the UAC.
I find the UAC so mind boggling I don't use it. Some applications seem to respect it and some don't. e.g. if you can't do something in a Finder window, sometimes you can do it in a terminal window. I have not figured out what the pattern is or if the UAC are there to allow actual secure protection or just guard railings to keep the riff raff from doing stupid things.
I suspect the Windows folks would say the UAC is just guard railings not actual security.
And don't get me wrong. Bash has it's uses. Space efficiency is important as you point out. And in my original post I said I was talking about scripting not interactivity. Bash is more convenient for interactivity as well.
My point was I don't see why bash persists in scripts.
Despite your discourtesy here is a response.
shell script is preferable to perl because it's easier to read, easier to write reasonably, and has a low overhead cost. your "1000 times slower" number is a figment of your imagination.
Write a loop that iterates over 100000 short files. for each file run an awk script, a sed script on the result and a grep.
See you tommorrow.
or you could use perl and have it done in ten minutes.
Okay now suppose you wanted to perhaps have an exception test for the killall or the askmara. Or suppose you wanted to have a time-out if they never returned. Finally assume you wanted to log the result of the action. Maybe you want to use a command line variable to supply say a password and the number of retries.
Yes you could do all that in shell script. it simply is easier in perl.
your assurance that your perlscripts will run is that the first line of the perl program specifies which perl interpreter to use. if it requires 5.6 you tell it to use 5.6
The original point of perl is to address your concerns. You want to be close the machine (in the unix not the C sense) but you want enough high level functionality. And you want to chain stuff.
Perl is the ultimate glue language. it's not so lovely as python or ruby but it's much more adapted for glueing and staying as close to shell scripting as possible. At the same time it has nice libraries that mean it can do so much more if you need to go there.
If all you're doing is moving files around or creating tarballs etc. then all those backticks in perl can become a PITA
it's easy to wrap shell into perl when one feels the backtick are getting in the way. To be pendantic:
<perl commands go here >
system <<EOC; # the bash script follows /tmp /tmp
echo "embedded bash script begins"
ls
tar -xc fooberries.tar
mv tweedlee.txt tweedeldum.txt
echo "bash script done, now resuming perl interpreter"
EOC
<further perl commands here.>
Your forkbomb script is rather a pointless action as I'm sure you are aware.
if you are parsing text or doing any sort of complicated extractions you have to repeatedly use grep awk and sed in bash to accomplish the job. repeatedly launching these in aprogram can produce something that is easily 100-1000 times slower than the equivalent perl would be.
thus the window of usefulness for a scripting language is extended three orders of magnitude.
for example, let's say the ease of use of scripting means that until a program runs longer than, say, ten minutes to do a job you will prefer script over compiled lnaguages. the equivalent bash program if it does any serious parsing might take 3 hours. This is why one might still use a script language even when "speed" is an issue.
moreover, for any complex set of operations, expressing the logic is always simpler in perl. Yet the syntax is almost the same.
hence I wondered why shell script is used given perl seems to be always preferebale for any use.
I've never fully understood why bash is used anymore when perl is around.
No I'm not trolling. in most applications that take a significant amount of time to run, perl is orders of magnitude faster than equivalent and akward bash script.
the syntax of perl is sufficiently close to bash that anyone fluent is bash ought to have little trouble with moving to perl.
So in total seriousness, what is the point of using bash for scripting?
So that's about as many man hours as it would take to build every skyscraper in the world.
One is tempeted to snark something like "what a waste of manpower" but chances are those folks would not be puting that lost time to productive use but instead idle hands would find the devils work. So perhaps another way to say this is that something like a billion petty crimes were prevented.
Gravity Shifting. There's a gravity manipulation nodule in the screen that changes the direction of gravity. /no really
Yes but it only works in python
import gravity
so you have to hold the machine upright until it boot. And if you put it to sleep it falls over.
What is in the keyboard? extra port connectors? a dvd players? Obviously it's not the batteries or anything actually required to run.
but it has to be heavy enough not to tip over. Since the batteries are in the screen, the base must be filled with lead?
The real reason for this change is that there are tools that rip the old Windows Media stream and let you save the instant movies on your computer. So far I haven't seen a similar tool for the Silverlight streams.
I suspect they were not really worried about that. If you want to rip a movie you rip the DVD. Ripping a netflix stream would just produce a bad resolution movie, no dolby 5.1, and glitches.
The real reason I think is, ironicaly customer service and a path forward on DRM.
with silver light they can service both mac and pc and eventually linux users with one application instead of 3.
Microsoft is pouring money into silver light, and one assumes they are responsive to the needs of earlier adopters. Netflix could probably get more of the changes they need from microsoft silverlight than an entrenched microsoft product. likewise for flash. Better to be the big fish in the small pond than a small fish in a big pond if you are seeking impact.
I've used both the services for a mac, as well as a PC (running in virtualbox) the original PC version, early mac beta and the silver light versions on PC and mac.
The silver light version normalize the experience on the mac and pc. unfortunately it's equally sucky now.
with the old version there were a bunch of hidden diagnostics you could pull up. You could even overide the automatic data rate selection, which was helpful if you wanted to force downgrade it when your connection was having intermittencies.
with the diagnostics you could determine which times it sucked because Netflix was not delivering and which times it sucked because comcast was sending it on a DNS wild goosechase through slow pipes.
with the new one you never know who to blame when it sucks. Which is to me more frustrating even if then net outcome-- gaps in my movie and bad resolution-- is the same.
Multi-core and multi-cpu programming is the future. I include GPUs in this. And programming these using existing tools is sub optimal.
But it's a catch 22. Few people are going to get their fingers wet in GPU programming without bridge tools like CUDA and fortran wrappers that make it less painful to change over hardcore math libraries. Yet at the same time the resulting code is sub optimal. for example the zeroth order in tools in CUDA sweep the matrix multiply back from the GPU to the CPU memory-- which is not what you want if you are dooing two consecutive matrix multiples. But it gets you started. (I note that more advanced, less library bound, cuda programming get's around this, but only a fool would invest the time learn it before trying the simple way).
Cell programming is another knotch up in difficulty. So sub-optimal convestion approaches may not work well. You really need to program for the CELL. No one really is perfectly sure what the best way to exploit these things is.
I suspect SONY wants people to commit to figuring the CELL out rather than giving them tools to simply do ports. This is what he meant I think by "increasing quality".
I also suspect this means that games produced form the CELL wont back port easily since it will be so architecture specific. Which is also good for sony.
In the meantime if they sell half as many units as xbox 360, yet 100% of the game profits rather than say 10% of the came profits go to sony and committed exclusive cell programmers, SONY is coming out ahead.
Uh did you actually look at the well-sourced article pointing out how bad these sources are. One of them published a piece saying "58% of ipod owners may choose zune".
Of course they're going to pass the fees on to customers. What else are they going to do, hold a bake sale?
Right.
I think it's a fine idea. the spectrum is public land. You rent it you don't give it away. This is a point that both conservatives and socialists totally agree upon. It's the bought off congressmen who were out to sell it.
There have been exceptions to this of course. When you want a resource exploited you do sell it. For example, getting railroads built wiht land grants. Or the 1872 mining law.
But now a century later the 1872 mining law seems like a huge mistake to continue. And yet that's pretty much exactly what the "drill now" folks want to do.
The secret is to lease it and price it right. It's not that hard to do.
A copyright allows the denial of a particular use of the material. Example, GNU denies the right to redistribute GNU lic software unless you meet certain conditions, like opening your own source.
What is the difference between you reading your book aloud, and a machine reading it aloud? And why is one subject to an additional license on top of having purchased the book when the other isn't?
Simple. because one is being sold and the other isn't. You might as well ask, why can't I do the following.
1) buy one copy of the print version.
2) record an actor reading it
3) sell as many copies of the recording as I please and not pay the author a dime.
furthermore to tighten the analogy, instead do this.
4) for every audio-version I sell, I buy one copy of the paper or e-book edition.
that way the author is getting the e-book roylaty rate and I'm pocketing the audio book rate.
Clearly this is unacceptable.
Now if you read the article you know this is not about stopping you from readin out loud or even reading out loud to another person. Or even a librarian reading to a class. it's about sales of audio books while paying e-book royalty rates.
There is another way to look at this.
One could say that audio books contain more labor and this is part of why they cost more. Once a technology comes along that removes that labor they should cost less.
That is true, but it misses the point.
Thus the real statement of the quesiton is this: if the manufacturing cost of books and audio books goes down then clearly the price of these should fall. But since audo books and e-books have different roylaty rates, if you change their ratio then you chance the total earnings to the authors. thus you need to re-adjust the roylaty rates so that the authors get the same total earnings.
Why should you want to assure authors get the same as before: when you sum up the total earnings (revenue minus cost of production) for books this get's divided amongst the publishers and authors. There is some dynamic equilibrium of what is neccessary to pay authors to entice a sufficient number of them to produce the books you want. e.g. if authors got no money, there would be fewer books written (not zero of course, but there could be no professional authors at all!)
If you want to argue that authors are paid to much then you have to prove that their is artificial scarcity of authors. good luck!
So in the end there has to be some fixed amount of money flowing to authors to maintain this status quo.
Blout is saying that if you canablaize a high profit audio book sale with a low-profit e-book sale then you simply need to charge more for e-books to make the total for the authors come out the same as before.
it's okay if the overall price declines. indeed this is great since it may increase sales. But in the end you can't simply lower the price by lowering the author's roylaties.
Decent TTS in a widely-used device will basically kill the audiobook market, and authors should be compensated in some way...
This is only true if you assume that there are people out there who would buy both the eBook AND the audio book if there was no TTS. Otherwise eBook sales aren't causing a loss of sales in the audio book market, they are merely replacing those sales.
I own a few books as audio books (usually bought before a long drive somewhere), and even in the cases of the really good ones, I've never felt a burning desire to buy the book again in print.
E-books sell for less than half to a quarter of audio book CD prices and fewer copies are sold. the ratio is enormous-- the Audio book market is 1000 times larger than the e-book market.
hence replacing 1-for-1 an audiobook with an e-book would cut the income by 1/2 or 1/4. Moreover if the author reads his own book, then his roylaties are even higher so the loss is maginified further.
you might wonder why then a publisher would be willing to sell if it represents a loss of revenue. The answer is that the e-book publisher and the audio book publisher are not the same person. the audio book publisher might be horrified that his sales are canialized by cheap e-baook sales, but from the e-book publisher's point of view it's a chance to expand their market 100 fold.