eInk (like the Kindle display) is definitely nice to read but a little color and maybe some sound would definitely help.
They would have to get rid of the eink to do that, and reading on backlit LCDs sucks, as anybody who sits in front of a computer all day can tell you.
I can almost guarantee that this device will not compete with any traditional eInk readers. At best it will compete poorly with netbooks, but you seriously don't want to be reading a novel on one. Getting the news might be fine, but seriously, why not just get a netbook for news and youtube and whatever locked-down lame-ass equivalent they'll be putting in their tablet?
Have you actually tried any of the current crop of ebook readers?
Because, as an avid reader, I love my ebook reader, and it isn't even close to one of the current crop.
These "Five Top Publishers" are going to come up with a NEW device to rival the Kindle in such a core area as... what, newspaper subscriptions? That's sort of a "Yeah, you could probably do that too, why not offer it?" addition to the Kindle.
They also obviously have absolutely no idea why E-Ink is so popular over LCD screens (like their device will certainly be based on) - and it is not Kindle's E-ink display, by the way, you would think a newspaper publisher could get that right, but maybe that's indicative of why they are in decline? E-Ink is so popular even though it is incredibly more expensive because it is easy to read. Like the name implies, it is virtually the same as reading a book. You get a few more barely noticeable jaggies than straight print would give you, and none of the harshness or flicker of an LCD.
So what do they plan to do? Why, introduce harshness and flicker! And poor battery life, of course. Idiots. Now if they solved the technical hurdles to creating a color e-ink display that would be eniterly different, and their devices would indeed be beautiful. But I'm pretty sure they haven't done that.
Adding the media content and all that, well they'll just be selling a locked-down internet tablet at that point. Why would someone buy their locked down internet tablet when they could almost certainly get an unlocked tablet (basically a netbook) for less (probably)?
It really sounds to me like they don't have a clue what they are doing, and the only way it will work is if they only sell their content over these devices. If they do that, I give them a 50/50 chance of either going bankrupt or changing the way we view periodicals. Either way I still won't be buying them.
Apparently you don't host a website, because serving files is extremely expensive - 400kb over thousands of downloads works out to quite a bit of money saved.
$8 an hour? Where are you, India? The minimum wage in the US is $7.25/hr, so you're just barely getting minimum wage,
I would assume thats exactly what the GP meant by "close to minimum wage". I'm not sure what additional point you were trying to make, since it seems to be the same one he was.
FWIW, I started out in the help desk at $15 an hour, then desktop support (basically tier two on-site helpdesk) for $20 an hour. Being naive at the time, I had no idea I was getting screwed in my pay until my boss was dumb enough to say so. Now I'm doing Network Admin work at the same pay because of "economic troubles", the bastards. The only upside is that, because of my unique work schedule and the labor laws of my state, I get about 44 hours of overtime every week I'm on the job (about half the month). Plus I'm gaining tons of experience, so I figure it's worth it stick it through the crappy pay. Eventually it will change one way or another though. In any case, both have been worthwhile experiences - the first job was just to put something on my resume, but the second has led to significant network experience and even a good deal of programming experience.
The problem for non-stupid programmers is (or one of them, at any rate) that using only binary floating point prevents simple expression of calculations with simple rounding rules, when those rules are defined in terms of base-10 numbers, which is often the case in important application domains.
But 754r doesn't solve that, it simply mitigates it like anybody who understands the floating point problem already does. It cannot actually solve the problem, because ALL calculations done on a computer are done in binarey - there is no way around it. That the conversion is made in the CPU (FPU more specifically) doesn't change the fact that a conversion must be made and the errors are carried over.
The problem that some people have with doing this is it hides the problem, instead of accentuates it. Now even fewer programmers, especially new programmers, are aware there is a problem. They will simply think "I'm not ever converting out of decimal, so these calculations will always be correct" instead of being aware of the fact that the processor is simply doing some binary>decimal error mitigation for you, and problems can and will still crop up.
It isn't even floating point any more, it's decimal, so they may even have a hard time researching a well documented problem when something does come up.
It's the difference between recognizing a problem as soon as it crops up (because you ran into another FP problem and learned FP's pitfalls) instead of waiting for hours, days, or weeks learning how to correct it.
You know the old saying: Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime. Well, 754r is giving programmers fish instead of teaching them to fish, and it'll bite them in the ass 10 times harder (though 1/10th as often) when you can't figure out the problem because you have no idea there IS one (other than the fact that this one, particular calculation or another is always verifiably wrong).
It's a common problem people run into (often without realising it), and the standard way to mitigate it is to always calculate the problem at at least two decimals greater precision than the figures you are working with. So if you are given 1 + 1 = X, you calculate at 1.00 + 1.00 = X. 0.05 becomes 0.0500, etc. You don't remove the precision until after all your calculations are finished, and this virtually eliminates the binary/decimal rounding errors that occur. I could see in some cases it still being an issue, but 99% of the time that will fix it.
This basically just performs the hurdles for accurate binary/decimal conversions for you so you don't have to worry about it. It's still going to be calculated in binary at the hardware level though, and it's the natural difference between binary and decimal that causes the problems, so it is still something to keep in the back of your mind.
Plus the fact that binary math is completely useless for almost all humans.
It has different oddities that we aren't used to, and as such they seem crazy. Nobody cares that it eliminates other oddities, we are used to those and understand them.
So in order to be useful, ALL computers must convert ALL calculations that a human will see into Decimal. If you can do that sooner rather than later, all the better for matching up with what humans will expect (like the results of 2/3).
The decimal standard came about for this very reasons - binary calculated figures come out slightly different than decimal or fraction calculations, and it's disconcerting when you work out a fraction with a pen and paper and come out with a "correct" answer that is different than what the computer says. Since you verified it separately, obviously the computer is wrong.
Decimal calculations avoid that pitfall for the most part (a good FP programmer would have written his code to avoid it anyway), and the calculations come out to exactly the same as what a guy with a pen and paper will produce.
Why not? There is nothing intrinsicly differen't about the way Javascript is executed on a machine than, say C. They both eventually make it to machine language for execution, and any errors are going to be in the compiler (whether JIT or compiled in advance). Limitations in the language and the fact that it is interpreted means there are a lot of things you can do in C that you cannot do in Javascript, but none of that applies to raw calculations. C is just as susceptible to the floating point problem as Javascript, and the methods to avoid that pitfall are identical in Javascript and C..1 +.2 !=.3 in both, the dangers are the same.
The real question you should be asking is, who in their right mind would let a programmer who does not understand the pitfalls of floating point calculations write code for financial calculations that need to be relied on?
The ideal solution would be to have a content agnostic data pipe, be it fiber, copper, or wireless.
Kinda like cable...
The pipe is always agnostic, it's the signal that isn't. You can send cable TV over fiber if you want, no problem, you just need an optical reciever. You can broadcast over fiber just as easily as copper, there's no difference, it's just the specific equipment needed will be different.
Really, there is no excuse for vendor lockin for cable other than the vendors like vendor lockin. There is pretty much one cable company in my area, and they sell internet (over cable) and phone service (over their competitor's lines) too. However, unlike the phone company - who is forced to sell the cable company the right to use their lines at a rate that allows the cable company to compete with the phone company - the cable company doesn't have to sell the right to use their cable lines to anybody, and they don't. It's a bit lopsided and I can tell you the phone company hates it, but it's mandated by the state.
If cable equipment became universal, I'm sure someone would sue for the right to use the cable lines and we'd get more competition, which is the only tool the market has for driving down price.
But, hey, it was consistent, so it paid the bills, right?
Well, you did get paid, right?
If a manager thinks he knows better than the guys he hired to do the work, you're never going to win. This is true for everything. If it bugs you that much to bzero calloc then find a new company to work for.
For example, cdate, mdate, adate (creation, modification, and access dates)
Not being a C programmer from the dawn of the language, I had no idea what your arbitrary conventions meant until you qualified them. Is cdate an odd date you're using as a constant? Maybe you wrote an ActiveX that you for some strange reason call cdate, how am I to know? Maybe it calls the function to configure the date, I don't know!
Is cdate really better than CreationDate when you can type cre-tab to fill it in? Especially since it is then impossible to mis-type it and create one of those bugs that only rarely surface and take hours of mind-numbing testing to track down? Seems I save a bit of coding time and an assload of clarity by just giving it a sensible name. obuff is particularly bad, is that an output buffer or did you set an object to use the buffalo class? Beats me.
Maybe you only do your coding in plain vanilla C, but for everybody else those variable names are unreadable and difficult to maintain. Why do you demand I revert to the convention spec when there is no good reason for the convention to generate easy to read code?
I dunno, maybe if I had decades of idiotic and completely arbitrary naming conventions behind me these meaningless variable names would be more useful to me.
Derivative works are perfectly fine under Copyright law as long as the new work is sufficiently original and adds enough value to the old (note that these are very subjective qualifications). If they add little or nothing meaningful of their own to the work then it would certainly be in violation of Copyright law.
However, it seems to me that a linked library would have to be significantly more substantial than the app that calls it in order for this to be the case, even if the application were specifically built around using the library. If they designed it such that they could easilly swap out a different library, it's obviously not derivative, and the library is simply used to enhance their own original code. That case tends to fall under fair use, and if fair use applies then the GPL doesn't.
Also, regarding linking and the GPL, Copyright is all about distribution - I can write whatever the hell I want based on whatever the hell I want, and if I never distribute any copyrighted material I am never in violation of copyright. Period. The GPL does not magically turn what I write into what somebody else wrote, and therefore distributing what I myself wrote violates Copyright. If all I am doing is linking libraries (which are copyrighted) and I never distribute those libraries, it is not possible for me to ever be in violation of the copyright on those libraries. It does not matter where I got the inspiration for the code, what calls I make, any of it. The I wrote is my code to do with as I please. If I want to distribute a version of my code that does not include the GPL'd libraries, there is nothing the GPL can do to force me to GPL my code. They did not write it, I am not distributing their code, they cannot dictate what I do with it. It's not a EULA, it's a Copyright license. Copyright deals with, say it with me now, COPYING. If I don't copy their code, I don't require their license.
In fact, if I am simply calling a function within a GPL'd library a few times, and it is not intrinsicly vital to my own code (perhaps it is a better and more convenient implimentation, but I have a function that works if the library is not available), I could probably still distribute the GPL'd code without distributing mine as GPL under fair use. That's a much more subjective case, and a determination of just HOW derivative a work is would be required. At the very least, as anal and intolerant as the FSF is, it would probably ending up costing a ton of money in court fees, and I don't have the money to go up against an organization like the FSF.
Frankly, in my opinion the GNU GPL is coercive and disgusting, and I think it goes far beyond what it should. The idea, of course, is to force everyone to give their code away for free even if they don't want to. I find this attitude offensive (less the free, and more the forcing). I only have a few documentaries on the history of Linux to base this on, but based on those I think Stallman himself is a man with no class. I know his type, they tend to believe everyone should be free, even if they have to force you. Can you see the hippocracy there? Anyway, I'm rambling, turns out this is a hotbutton issue for me - who knew?
Finally, Palm did distribute the source for PDFViewer, as per the GPL requirements - the FSF are just assholes who couldn't be bothered to do more than a cursory check to see if there was something they could sue for.
Slashdot Mirror
eInk (like the Kindle display) is definitely nice to read but a little color and maybe some sound would definitely help.
They would have to get rid of the eink to do that, and reading on backlit LCDs sucks, as anybody who sits in front of a computer all day can tell you.
I can almost guarantee that this device will not compete with any traditional eInk readers. At best it will compete poorly with netbooks, but you seriously don't want to be reading a novel on one. Getting the news might be fine, but seriously, why not just get a netbook for news and youtube and whatever locked-down lame-ass equivalent they'll be putting in their tablet?
Get a Sony, all the gorious E-ink, none of the lock-in.
I know, I said Sony, miracles can happen all right!
Have you actually tried any of the current crop of ebook readers?
Because, as an avid reader, I love my ebook reader, and it isn't even close to one of the current crop.
These "Five Top Publishers" are going to come up with a NEW device to rival the Kindle in such a core area as... what, newspaper subscriptions? That's sort of a "Yeah, you could probably do that too, why not offer it?" addition to the Kindle.
They also obviously have absolutely no idea why E-Ink is so popular over LCD screens (like their device will certainly be based on) - and it is not Kindle's E-ink display, by the way, you would think a newspaper publisher could get that right, but maybe that's indicative of why they are in decline? E-Ink is so popular even though it is incredibly more expensive because it is easy to read. Like the name implies, it is virtually the same as reading a book. You get a few more barely noticeable jaggies than straight print would give you, and none of the harshness or flicker of an LCD.
So what do they plan to do? Why, introduce harshness and flicker! And poor battery life, of course. Idiots. Now if they solved the technical hurdles to creating a color e-ink display that would be eniterly different, and their devices would indeed be beautiful. But I'm pretty sure they haven't done that.
Adding the media content and all that, well they'll just be selling a locked-down internet tablet at that point. Why would someone buy their locked down internet tablet when they could almost certainly get an unlocked tablet (basically a netbook) for less (probably)?
It really sounds to me like they don't have a clue what they are doing, and the only way it will work is if they only sell their content over these devices. If they do that, I give them a 50/50 chance of either going bankrupt or changing the way we view periodicals. Either way I still won't be buying them.
Apparently you don't host a website, because serving files is extremely expensive - 400kb over thousands of downloads works out to quite a bit of money saved.
Used an app that strips out all the crap from the adobe reader, so that it just does what it is supposed to do: read pdfs.
This happens to make it 10x faster in the process, which is nice.
I don't remember the name of the app off the top of my head though. :/
$8 an hour? Where are you, India? The minimum wage in the US is $7.25/hr, so you're just barely getting minimum wage,
I would assume thats exactly what the GP meant by "close to minimum wage". I'm not sure what additional point you were trying to make, since it seems to be the same one he was.
FWIW, I started out in the help desk at $15 an hour, then desktop support (basically tier two on-site helpdesk) for $20 an hour. Being naive at the time, I had no idea I was getting screwed in my pay until my boss was dumb enough to say so. Now I'm doing Network Admin work at the same pay because of "economic troubles", the bastards. The only upside is that, because of my unique work schedule and the labor laws of my state, I get about 44 hours of overtime every week I'm on the job (about half the month). Plus I'm gaining tons of experience, so I figure it's worth it stick it through the crappy pay. Eventually it will change one way or another though. In any case, both have been worthwhile experiences - the first job was just to put something on my resume, but the second has led to significant network experience and even a good deal of programming experience.
How are you going to go back in time and submit your dummy app before the October 1, 2009 cutoff date though?
I think there's a flaw in your plan...
Yeah, and if you hurry now you can submit that dummy application before the 10/1/2009 deadline!
Oh wait...
...you end up with someone that doesn't even know what a cookie is.
Nonsense! Everyone knows what a cookie is!
My favorite is a nice, soft chocolate chip right out of the oven.
Well, if he shaved it he wouldn't get his 70 virgins, now would he? (Shaving the beard is a crime in Islamic countries)
However, Firefox + a half dozen extensions + XP does not run fine, that's the point.
We'll see if Chrome is any better, but Chrome does have the faster JS engine, so I'd think it would be a little better.
I hated that movie so much.
"I want to take his face... off..." ugh, horrible. Such a stupid idea.
Anyways...
The problem for non-stupid programmers is (or one of them, at any rate) that using only binary floating point prevents simple expression of calculations with simple rounding rules, when those rules are defined in terms of base-10 numbers, which is often the case in important application domains.
But 754r doesn't solve that, it simply mitigates it like anybody who understands the floating point problem already does. It cannot actually solve the problem, because ALL calculations done on a computer are done in binarey - there is no way around it. That the conversion is made in the CPU (FPU more specifically) doesn't change the fact that a conversion must be made and the errors are carried over.
The problem that some people have with doing this is it hides the problem, instead of accentuates it. Now even fewer programmers, especially new programmers, are aware there is a problem. They will simply think "I'm not ever converting out of decimal, so these calculations will always be correct" instead of being aware of the fact that the processor is simply doing some binary>decimal error mitigation for you, and problems can and will still crop up.
It isn't even floating point any more, it's decimal, so they may even have a hard time researching a well documented problem when something does come up.
It's the difference between recognizing a problem as soon as it crops up (because you ran into another FP problem and learned FP's pitfalls) instead of waiting for hours, days, or weeks learning how to correct it.
You know the old saying: Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime. Well, 754r is giving programmers fish instead of teaching them to fish, and it'll bite them in the ass 10 times harder (though 1/10th as often) when you can't figure out the problem because you have no idea there IS one (other than the fact that this one, particular calculation or another is always verifiably wrong).
It's a common problem people run into (often without realising it), and the standard way to mitigate it is to always calculate the problem at at least two decimals greater precision than the figures you are working with. So if you are given 1 + 1 = X, you calculate at 1.00 + 1.00 = X. 0.05 becomes 0.0500, etc. You don't remove the precision until after all your calculations are finished, and this virtually eliminates the binary/decimal rounding errors that occur. I could see in some cases it still being an issue, but 99% of the time that will fix it.
This basically just performs the hurdles for accurate binary/decimal conversions for you so you don't have to worry about it. It's still going to be calculated in binary at the hardware level though, and it's the natural difference between binary and decimal that causes the problems, so it is still something to keep in the back of your mind.
Plus the fact that binary math is completely useless for almost all humans.
It has different oddities that we aren't used to, and as such they seem crazy. Nobody cares that it eliminates other oddities, we are used to those and understand them.
So in order to be useful, ALL computers must convert ALL calculations that a human will see into Decimal. If you can do that sooner rather than later, all the better for matching up with what humans will expect (like the results of 2/3).
The decimal standard came about for this very reasons - binary calculated figures come out slightly different than decimal or fraction calculations, and it's disconcerting when you work out a fraction with a pen and paper and come out with a "correct" answer that is different than what the computer says. Since you verified it separately, obviously the computer is wrong.
Decimal calculations avoid that pitfall for the most part (a good FP programmer would have written his code to avoid it anyway), and the calculations come out to exactly the same as what a guy with a pen and paper will produce.
Assume all values are fractions with a denominator of 1000?
Why not? There is nothing intrinsicly differen't about the way Javascript is executed on a machine than, say C. They both eventually make it to machine language for execution, and any errors are going to be in the compiler (whether JIT or compiled in advance). Limitations in the language and the fact that it is interpreted means there are a lot of things you can do in C that you cannot do in Javascript, but none of that applies to raw calculations. C is just as susceptible to the floating point problem as Javascript, and the methods to avoid that pitfall are identical in Javascript and C. .1 + .2 != .3 in both, the dangers are the same.
The real question you should be asking is, who in their right mind would let a programmer who does not understand the pitfalls of floating point calculations write code for financial calculations that need to be relied on?
Commas are required when paired with a conjunction to create a compound sentance. It's always ,and.
Otherwise commas are always optional and used to break up the flow of a sentance.
The ideal solution would be to have a content agnostic data pipe, be it fiber, copper, or wireless.
Kinda like cable...
The pipe is always agnostic, it's the signal that isn't. You can send cable TV over fiber if you want, no problem, you just need an optical reciever. You can broadcast over fiber just as easily as copper, there's no difference, it's just the specific equipment needed will be different.
Really, there is no excuse for vendor lockin for cable other than the vendors like vendor lockin. There is pretty much one cable company in my area, and they sell internet (over cable) and phone service (over their competitor's lines) too. However, unlike the phone company - who is forced to sell the cable company the right to use their lines at a rate that allows the cable company to compete with the phone company - the cable company doesn't have to sell the right to use their cable lines to anybody, and they don't. It's a bit lopsided and I can tell you the phone company hates it, but it's mandated by the state.
If cable equipment became universal, I'm sure someone would sue for the right to use the cable lines and we'd get more competition, which is the only tool the market has for driving down price.
But, hey, it was consistent, so it paid the bills, right?
Well, you did get paid, right?
If a manager thinks he knows better than the guys he hired to do the work, you're never going to win. This is true for everything. If it bugs you that much to bzero calloc then find a new company to work for.
For example, cdate, mdate, adate (creation, modification, and access dates)
Not being a C programmer from the dawn of the language, I had no idea what your arbitrary conventions meant until you qualified them. Is cdate an odd date you're using as a constant? Maybe you wrote an ActiveX that you for some strange reason call cdate, how am I to know? Maybe it calls the function to configure the date, I don't know!
Is cdate really better than CreationDate when you can type cre-tab to fill it in? Especially since it is then impossible to mis-type it and create one of those bugs that only rarely surface and take hours of mind-numbing testing to track down? Seems I save a bit of coding time and an assload of clarity by just giving it a sensible name. obuff is particularly bad, is that an output buffer or did you set an object to use the buffalo class? Beats me.
Maybe you only do your coding in plain vanilla C, but for everybody else those variable names are unreadable and difficult to maintain. Why do you demand I revert to the convention spec when there is no good reason for the convention to generate easy to read code?
I dunno, maybe if I had decades of idiotic and completely arbitrary naming conventions behind me these meaningless variable names would be more useful to me.
That's how a nice IDE helps you out, once you've typed it once you can type a few characters and tab it. Microsoft has fantastic IDE's.
Though, going from Visual Studio to a text editor makes you go "Ooooh snap...".
Yeah, but now you could re-write the whole program based on that one variable name!
Maybe it's because the GPL only stipulates that the code needs to be availabe upon request?
Besides, Palm did provide the source, the FSF simply couldn't be bothered to look (or ask):
http://palm.cdnetworks.net/opensource/1.3.1/documentserver.tar.gz
Derivative works are perfectly fine under Copyright law as long as the new work is sufficiently original and adds enough value to the old (note that these are very subjective qualifications). If they add little or nothing meaningful of their own to the work then it would certainly be in violation of Copyright law.
However, it seems to me that a linked library would have to be significantly more substantial than the app that calls it in order for this to be the case, even if the application were specifically built around using the library. If they designed it such that they could easilly swap out a different library, it's obviously not derivative, and the library is simply used to enhance their own original code. That case tends to fall under fair use, and if fair use applies then the GPL doesn't.
Also, regarding linking and the GPL, Copyright is all about distribution - I can write whatever the hell I want based on whatever the hell I want, and if I never distribute any copyrighted material I am never in violation of copyright. Period. The GPL does not magically turn what I write into what somebody else wrote, and therefore distributing what I myself wrote violates Copyright. If all I am doing is linking libraries (which are copyrighted) and I never distribute those libraries, it is not possible for me to ever be in violation of the copyright on those libraries. It does not matter where I got the inspiration for the code, what calls I make, any of it. The I wrote is my code to do with as I please. If I want to distribute a version of my code that does not include the GPL'd libraries, there is nothing the GPL can do to force me to GPL my code. They did not write it, I am not distributing their code, they cannot dictate what I do with it. It's not a EULA, it's a Copyright license. Copyright deals with, say it with me now, COPYING. If I don't copy their code, I don't require their license.
In fact, if I am simply calling a function within a GPL'd library a few times, and it is not intrinsicly vital to my own code (perhaps it is a better and more convenient implimentation, but I have a function that works if the library is not available), I could probably still distribute the GPL'd code without distributing mine as GPL under fair use. That's a much more subjective case, and a determination of just HOW derivative a work is would be required. At the very least, as anal and intolerant as the FSF is, it would probably ending up costing a ton of money in court fees, and I don't have the money to go up against an organization like the FSF.
Frankly, in my opinion the GNU GPL is coercive and disgusting, and I think it goes far beyond what it should. The idea, of course, is to force everyone to give their code away for free even if they don't want to. I find this attitude offensive (less the free, and more the forcing). I only have a few documentaries on the history of Linux to base this on, but based on those I think Stallman himself is a man with no class. I know his type, they tend to believe everyone should be free, even if they have to force you. Can you see the hippocracy there? Anyway, I'm rambling, turns out this is a hotbutton issue for me - who knew?
Finally, Palm did distribute the source for PDFViewer, as per the GPL requirements - the FSF are just assholes who couldn't be bothered to do more than a cursory check to see if there was something they could sue for.