I see no problem with putting large files on flash drives, and it's quite common: zip files, tar files, root partition backups, virtual machine disks, etc. Works fine with ext3.
Last I checked, paper books don't flicker, nor are they blurry. But reading them can still cause eye strain; just less so than with a computer screen.
Reading anything can cause eye strain if you do it long enough. The question here is whether eInk displays are any better in that regard than LCDs.
People who claim that have provided not a shred of evidence. LCDs are as good or better in all areas that matter to eye strain: flicker, contrast, sharpness.
FYI, high contrast greatly increases eye strain
Very high contrast does (due to glare), but not the kind of contrast you get with LCD screens (if it did, people would reduce the contrast).
eInk contrast, however, is lower contrast even than regular printed paper, and that makes characters harder to see and may lead to eye strain.
Yes, eInk displays don't flicker. But neither do modern LCDs, not because their refresh rate is fast (which it happens to be), but because the image doesn't fade between refreshes. If you think your LCD flickers, you're imagining things.
I don't see much, if anything, in that quote (or the rest of the short article) that says anything about eInk displays.
The article says (correctly) that "eye strain" is the result of blurriness and flicker. CRTs have those, LCDs and eInk displays don't. Hence there is no plausible mechanism by which LCDs could cause more eye strain than eInk.
If you want to claim LCDs cause eye strain, either put up or shut up.
I'd suggest that if you really believe that LCDs and eInk displays are the same
They are not the same: eInk displays are low contrast and slow refresh; in short, they are pretty lousy displays. However, like LCDs, they don't cause eye strain (at least no more than reading paper).
If anything, due to their lower contrast, eInk displays are worse than LCDs in terms of eye strain.
eInk is superior to LCDs only in terms of power consumption. In terms of readability in sunlight, it's comparable to LCDs designed for outdoor use. And in terms of contrast ratio, color, and refresh rate, it's much worse than other display technologies.
Good ideas are a dime a dozen. The hard part is making a business out of them.
Apple, for example, has hardly ever come up with any original ideas, but they have done an excellent job turning other people's good ideas into successful products.
Mathematical biology has a history that goes back further than computer science. Many biologists probably know a lot more math and statistics than your average computer scientists.
This sounds like an academic trying to make a name for himself again by labeling something that already exists with his own label. "Computational photography"? Well, how exactly did digital photography ever work without that?
Open source camera OS? Nice try, but the reason manufacturers haven't standardized on anything yet is because the technology keeps changing.
However, FWIW, Canon cameras effectively can be reprogrammed using the CHDK firmware.
Running Linux on Apple hardware is not supported. Furthermore, Apple hardware is weird in some ways, and it also changes haphazardly over time even for the same model number. Overall, you're much better off buying hardware from vendors that actually support Linux.
In terms of quality, my experience with Apple hardware has been decidedly mixed, while I have never had a problem with HP.
Who cares whether it runs faster on CPU with nominally similar specs. For many of these measurements, I/O, disks, and other components make a big difference, too.
What they should do is compare performance on regular, mainstream desktops and laptops that you can get at various price points: $500, $1000, $2000.
Phones are meant to be carried around in pockets; "external forces" act on them as a matter of normal usage.
Two features that may make the iPhone susceptible to exploding are its thinness and its use of a non-removable battery. If you look at Nokia's 5800 touch screen phone, it's significantly thicker, but it can be carried around in a pocket without exploding.
I've had a dozen cell phones so far, and they have lived in bags, backpacks, and pockets. I've dropped them and sat on them. They've never broken or exploded. If the iPhone does, it's a design problem with the iPhone.
There are many cancers that creep up on you slowly and almost unrecognised until they hit a critical mass
But the immune system may get rid of a lot of those asymptomatic cancers. In your case, early detection might have helped, but in the case of many other people, the treatment may just get rid of a cancer that the immune system would have gotten rid of anyway.
QObject stuff can be trivially integrated to existing C & C++ code. Apart from the moc phase, nothing that special is happening.
No, it cannot be "trivially integrated" with C code or any other language. Anything that involves C++ involves dealing with global constructors, initialization order, new-vs-malloc, destructors, name mangling, exception handling, STL, template expansion, and RTTI, among many other things. The C++ standard and runtime are an unportable, complicated mess, and it's getting worse and worse with every succeeding standard. And Qt makes the mess even worse by duplicating a lot of that functionality.
C is a necessary evil; C++ is a bloated evolutionary dead end.
Qt works in practice much better than it looks on paper.
If you want to program in C++, Gtkmm provides C++ programming support that is at least as good as Qt, it requires no preprocessor, and it is far more C++ standards conforming.
Natural CO2 production has to be balanced because otherwise we'd already have a nearly pure CO2 atmosphere. It's balanced because it's mostly based on a cycle of decay and photosynthesis in plants and animals.
Now, you say that humans add an extra 5% of that total production each year. That comes from burning oil and gas. Unlike the natural production, which is balanced by photosynthesis, human production is all excess CO2, since there is no photosynthesis or absorption to balance it.
Adding 5% of the total natural CO2 production each year as excess to the atmosphere is a huge deal. It's roughly like turning off all photosynthesis on earth several weeks each year.
So, thanks, your "20x" argument shows actually how severe human CO2 production actually is.
Both GObject and QObject are non-standard object models because neither base language (C, C++) supports an object model that is suitable for GUI development.
GObject is harder to develop for, but easier to integrate into other software.
QObject uses syntactic tricks in C++ to make it easier to develop for in C++, but it's harder to integrate into, and extend, in other languages.
An additional problem with QObject and Qt is that it doesn't even conform to C++ library standards very well.
He is "confusing" it in the sense of using Nokia's GPL-to-LGPL change in order to argue that the "end point" is a BSD/MIT/Apache license. In fact, I would argue that the natural "end point" for licenses is the LGPL, not the BSD license. There are good reasons to rewrite a GPL'ed library in LGPL or Apache form (I have done that myself). But people don't usually rewrite LGPL libraries under BSD/MIT/Apache form, and if they do, there is no reason to believe that the BSD/MIT/Apache version is going to be more successful than the LGPL form. Actually, BSD/MIT/Apache has potential problems from the point of view of long-term sustainability.
The error in his and your reasoning is to view licenses along a 1D continuum and to conclude that because it moves a little in one direction, it will move further. But the 1D view and the assumption of continued motion along it are fiction; there is no evidence for it.
Slashdot Mirror
I see no problem with putting large files on flash drives, and it's quite common: zip files, tar files, root partition backups, virtual machine disks, etc. Works fine with ext3.
umm, the defaults (fat32 formatted keys) work just fine in every distro automatically
Only to the degree that FAT32 works at all, which is not very well. FAT32 has lots of limitations and incompatibilities with POSIX file systems.
Last I checked, paper books don't flicker, nor are they blurry. But reading them can still cause eye strain; just less so than with a computer screen.
Reading anything can cause eye strain if you do it long enough. The question here is whether eInk displays are any better in that regard than LCDs.
People who claim that have provided not a shred of evidence. LCDs are as good or better in all areas that matter to eye strain: flicker, contrast, sharpness.
FYI, high contrast greatly increases eye strain
Very high contrast does (due to glare), but not the kind of contrast you get with LCD screens (if it did, people would reduce the contrast).
eInk contrast, however, is lower contrast even than regular printed paper, and that makes characters harder to see and may lead to eye strain.
They should consider moving to Linux at the same time; it's a whole lot easier to use and administer remotely than Windows.
Yes, eInk displays don't flicker. But neither do modern LCDs, not because their refresh rate is fast (which it happens to be), but because the image doesn't fade between refreshes. If you think your LCD flickers, you're imagining things.
http://www.xbitlabs.com/articles/monitors/display/lcd-parameters_3.html
Of course, you may be getting eye strain from your LCD monitor for other reasons, but that has nothing to do with LCD technology.
I don't see much, if anything, in that quote (or the rest of the short article) that says anything about eInk displays.
The article says (correctly) that "eye strain" is the result of blurriness and flicker. CRTs have those, LCDs and eInk displays don't. Hence there is no plausible mechanism by which LCDs could cause more eye strain than eInk.
If you want to claim LCDs cause eye strain, either put up or shut up.
I'd suggest that if you really believe that LCDs and eInk displays are the same
They are not the same: eInk displays are low contrast and slow refresh; in short, they are pretty lousy displays. However, like LCDs, they don't cause eye strain (at least no more than reading paper).
LCDs don't give people eye strain anymore than books or eInk displays.
http://en.wikipedia.org/wiki/Asthenopia
If anything, due to their lower contrast, eInk displays are worse than LCDs in terms of eye strain.
eInk is superior to LCDs only in terms of power consumption. In terms of readability in sunlight, it's comparable to LCDs designed for outdoor use. And in terms of contrast ratio, color, and refresh rate, it's much worse than other display technologies.
It works more like paper,
No, it doesn't. I can quickly flip through a paper book; flipping through an eInk book is like watching grss grow.
What's the refresh time on your paperback, when you turn a page?
Milliseconds.
There are several kinds of color LCD screens that work outdoors. Nokia cell phones commonly use one kind, the OLPC uses another kind.
I am tired of all those eInk readers (I've owned a couple); their slow refresh time makes them awful.
Good ideas are a dime a dozen. The hard part is making a business out of them.
Apple, for example, has hardly ever come up with any original ideas, but they have done an excellent job turning other people's good ideas into successful products.
Mathematical biology has a history that goes back further than computer science. Many biologists probably know a lot more math and statistics than your average computer scientists.
This sounds like an academic trying to make a name for himself again by labeling something that already exists with his own label. "Computational photography"? Well, how exactly did digital photography ever work without that?
Open source camera OS? Nice try, but the reason manufacturers haven't standardized on anything yet is because the technology keeps changing.
However, FWIW, Canon cameras effectively can be reprogrammed using the CHDK firmware.
Running Linux on Apple hardware is not supported. Furthermore, Apple hardware is weird in some ways, and it also changes haphazardly over time even for the same model number. Overall, you're much better off buying hardware from vendors that actually support Linux.
In terms of quality, my experience with Apple hardware has been decidedly mixed, while I have never had a problem with HP.
Apple knows what hardware things will run on, so they can enable a lot more CPU-specific options when they compile.
Who cares whether it runs faster on CPU with nominally similar specs. For many of these measurements, I/O, disks, and other components make a big difference, too.
What they should do is compare performance on regular, mainstream desktops and laptops that you can get at various price points: $500, $1000, $2000.
Phones are meant to be carried around in pockets; "external forces" act on them as a matter of normal usage.
Two features that may make the iPhone susceptible to exploding are its thinness and its use of a non-removable battery. If you look at Nokia's 5800 touch screen phone, it's significantly thicker, but it can be carried around in a pocket without exploding.
I've had a dozen cell phones so far, and they have lived in bags, backpacks, and pockets. I've dropped them and sat on them. They've never broken or exploded. If the iPhone does, it's a design problem with the iPhone.
It's fine for it to break, it's not OK for it to explode.
"Just recently?" That's been a standard example in introductory statistics classes for many decades.
There are many cancers that creep up on you slowly and almost unrecognised until they hit a critical mass
But the immune system may get rid of a lot of those asymptomatic cancers. In your case, early detection might have helped, but in the case of many other people, the treatment may just get rid of a cancer that the immune system would have gotten rid of anyway.
QObject stuff can be trivially integrated to existing C & C++ code. Apart from the moc phase, nothing that special is happening.
No, it cannot be "trivially integrated" with C code or any other language. Anything that involves C++ involves dealing with global constructors, initialization order, new-vs-malloc, destructors, name mangling, exception handling, STL, template expansion, and RTTI, among many other things. The C++ standard and runtime are an unportable, complicated mess, and it's getting worse and worse with every succeeding standard. And Qt makes the mess even worse by duplicating a lot of that functionality.
C is a necessary evil; C++ is a bloated evolutionary dead end.
Qt works in practice much better than it looks on paper.
If you want to program in C++, Gtkmm provides C++ programming support that is at least as good as Qt, it requires no preprocessor, and it is far more C++ standards conforming.
Let's take your numbers at face value.
Natural CO2 production has to be balanced because otherwise we'd already have a nearly pure CO2 atmosphere. It's balanced because it's mostly based on a cycle of decay and photosynthesis in plants and animals.
Now, you say that humans add an extra 5% of that total production each year. That comes from burning oil and gas. Unlike the natural production, which is balanced by photosynthesis, human production is all excess CO2, since there is no photosynthesis or absorption to balance it.
Adding 5% of the total natural CO2 production each year as excess to the atmosphere is a huge deal. It's roughly like turning off all photosynthesis on earth several weeks each year.
So, thanks, your "20x" argument shows actually how severe human CO2 production actually is.
Wow, pots and kettles.
Both GObject and QObject are non-standard object models because neither base language (C, C++) supports an object model that is suitable for GUI development.
GObject is harder to develop for, but easier to integrate into other software.
QObject uses syntactic tricks in C++ to make it easier to develop for in C++, but it's harder to integrate into, and extend, in other languages.
An additional problem with QObject and Qt is that it doesn't even conform to C++ library standards very well.
He is "confusing" it in the sense of using Nokia's GPL-to-LGPL change in order to argue that the "end point" is a BSD/MIT/Apache license. In fact, I would argue that the natural "end point" for licenses is the LGPL, not the BSD license. There are good reasons to rewrite a GPL'ed library in LGPL or Apache form (I have done that myself). But people don't usually rewrite LGPL libraries under BSD/MIT/Apache form, and if they do, there is no reason to believe that the BSD/MIT/Apache version is going to be more successful than the LGPL form. Actually, BSD/MIT/Apache has potential problems from the point of view of long-term sustainability.
The error in his and your reasoning is to view licenses along a 1D continuum and to conclude that because it moves a little in one direction, it will move further. But the 1D view and the assumption of continued motion along it are fiction; there is no evidence for it.
Android has already been ported to Ubuntu and can run as an application on top of a regular Linux kernel. The same should be possible on the N900.