Depending on the defaults in mom's camera app and the mail app that might impose its own preferred resolution, you will get the same compressed jpegs with e.g. 5 megapixels of effective image data.
Uh, presumably they'd be doing that because tablets are at the same resolution. And yes, thanks to Moore's law phones are approaching PS3 level graphics. Does this surprise you? Even on a 4-5 inch display that makes a difference, so it becomes acceptable for both.
I can halfway understand the case for tablets, but are you saying that the same game UI can be played equally well on a big TV screen and on a phone, that furthermore has little in the way of input usable for typical 3D games? I guess I'm just not into gaming that much, and certainly not to a compulsory degree that would make me want to play big screen games on a phone.
What are you talking about? Two years ago phones ran like absolute pieces of crap. Even one year ago, for the most part. There was constant stuttering, things weren't that smooth, etc.
Sounds like a typical Android UI experience:) I suspect that part of the drive for multi-core devices is to compensate for poorly designed software that couldn't respond to the user and wait for something else in the same thread.
Only since december or thereabouts have phones actually been getting towards powerful enough to handle everything smoothly.
I have a Nokia Lumia 800, that was released in November and was right then panned as hopelessly inadequate in the Self-Evidently-Important Core Count Smackdown charts. As it happens, I fail to find a case where I would want it to work much faster. Few applications take a little time to load into a useful state, but nothing blocks or causes annoying disruption. I would hazard an observation that one important thing often overlooked is how cleverly the software uses the CPUs that it is given to run on.
Four processors on a smartphone is fairly trivial in cost, so no it doesn't include a significantly larger price point. At the end of the day we're talking a $12 chip versus a $25 chip (maximum) for example.
Gaming at sufficient graphics quality to make full HD gaming possible when I hook up to larger displays. I want PS3 level graphics at the least, and that's coming via a) lots of GPU CUDA cores and b) lots of CPU helping out as with known hardware much of the effects rendering (physics etc) can be pushed back on the CPU cores. It's not like consoles don't use them, and that kind of customisation is the whole benefit of having known SoCs used widely.
So you don't want to buy a console and tap its mature and focused market of games, instead you expect game vendors to have come forward to meet your use case and not just provide a shrunken down phone gameplay for mobile use. How many of them already did so? You plug in your phone whenever you need to play, and carry the extra hardware in your phone, putting up with some overhead in size, battery life, etc., even if you don't use it most of the time?
Spot on. Also, this is a more ingenious use of the resolution than just throwing in megapixels for the spec sheet value with no difference to actual image quality for the tiny lens and the respectively constrained matrix size. Without multisampling or other processing, higher resolution matrices may actually produce worse results because sensitivity of individual elements gets lower as they get smaller.
Standby battery life with Google sync, a few IM clients (I run Skype and imo.im), Whatsapp, Viber and so on, should be around 4-5 days.
I wonder what Skype did to achieve this. On N900 and N9, the Skype engine is the monstrous wakeup hog that drains your battery in a day and exchanges packets with various hosts on the network all the time. Did they subscribe to some push wakeup mechanism where the app can be launched on incoming activity that needs user interaction?
More cores means better multitasking since threads can run in parallel.
In my experience, many of the cases where people thought they need to use threads were really cases of doin' it wrong. When you have properly designed asynchronous APIs, inter-process communication, a decent kernel scheduler, and a GPU to offload graphics to, you can do non-blocking UI even on a single CPU, and the difference between single and multiple cores only manifests in performance improvements, often fairly marginal, and hitting different bugs (which good software should not have, of course).
Also, even for handheld devices you are unlikely to find, for example, a single-core CPU that is four times faster than each core of a quad-core CPU.
I've been searching for someone to answer to a simple question: what are the tasks at which you feel your high-end smartphone should be faster, that are not attributed to things like network roundtrips where a faster proc is irrelevant? "Four times faster than good enough" just does not equal to "four times as good" to me, especially if it comes with a larger price point.
Another major advantage of multi-core systems is if a poorly written piece of software locks up it is highly likely to also be single-threaded and your system will chug along nicely despite the misbehaving program, allowing you to kill the process (by comparison, on a single-core system you're likely to suffer through five minutes of waiting for the system to respond before you are able to kill the process). Sure, in an ideal world this wouldn't happen but when it does happen it's nice to not be locked out of your system because of a single process misbehaving.
Unless we are talking of processes with privileged scheduling which should be part of the system and therefore should be well-written, which modern smartphone OS can't preempt a process that has locked up?
Not two years ago everything in the smartphone world worked nicely on a single core, and everybody except extreme performance junkies were happy with that (can't vouch for Android users, their pain tolerance threshold appears to be higher), what happened since then?
Also Sweeden I guess, both my Saab and Volvo did the same. On the other hand, the lighting conditions are quite bad for the majority of the year over there therefore it makes sense.
I wouldn't say so: depending where you are, for a good part of a summer, you can see around at night with no artificial light. I think it's more about safety-mindedness than anything else.
I don't think the headlight one with engine thing is a requirement by law or regulation.
Not in the US, but in parts of the EU it seems to be the case, probably highly correlated with headlights mandatory to be on while driving at all times. Every car I've driven in Finland (I'm a fresh driver, and I have only driven recent builds so far) turned on driving lights upon engine start, no extra switches required.
The cars in Germany have an idiot-proof option as well: you can just keep the switch at full-on at all times, and the car will turn the lights off when the engine is off, so the battery won't be draining like it would in my car (mine will leave the parking lights on, and peep worriedly when I exit the driver seat).
It probably works like it does in my car, bought in Finland and produced in Burnaston, UK: the "default" (historically marked as "0") is low-beam headlights, but you can get it down to parking lights. Not that you should, when you are actually driving.
I was the unintentional jackass when I first rented a car in Germany: it turned out there are still countries with cars where the headlights do not always turn on whenever the engine is running. I even shrugged off the first guy behind who flashed his lights at me, thinking he's an impatient twit.
Your point about the interface between the lit and the non-lit is correct, but it has unintended consequences. I did a fair amount of research into street and highway lighting as part of astronomy related "dark sky" issues. Some things are counter intuitive. It would seem that the brighter the light, the better and safer the roadway would be. That might be true when entering a well lit area, but upon leaving it, you will see much less until your eyes adapt.
It'd be interesting to see any research on how sodium-vapor lights help with this. The orange-yellow lighting is commonly used on roads at least where I'm driving, and apart from being an affordable and energy-efficient technology, it may work akin to the red lighting used by submariners, or it may not: accordingly to Wikipedia, LPS emission spectrum hits the peak sensitivity spot of the human eye.
I've seen how this happens: 1. Gee, I can just fire INSERTs in SQLite like I did in SQL Server, isn't it convenient? 2. (few months in development) Crap, these queries thrash the flash medium and cause a lot of waiting on I/O, we need to batch them and use transactions more. 3. (with deadlines looming) Attempts to tweak the database access flags or even relax the durability requirements, to get out of the corner we have painted ourselves into.
It would be instrumental for better performing code if database access was always treated as slow and therefore asynchronous, but SQLite does not provide an easy-to-use async API.
And if you have to use SQL for whatever reason, don't use indices unless absolutely necessary. It seldom is, despite what school has taught you. The index has to get updated too, which causes additional non-sequential writes. The minor speed boost you may get from selects are easily eaten up by the major speed bumps you cause on inserts and updates.
In many applications reads (SQL SELECT) happen much more often than writes. In this case, indexing still brings an overall benefit. In fact, the hardware architecture of flash memory is tilted to fast reads versus very slow writes, so if you have to do any writes at all, you already pay the price. The non-sequentiality issue is also mooted by controller sicruitry in bulk flash devices like SD cards, which reallocates logical buffers for wear leveling, hiding bad blocks, and write optimization.
The real issue with SQL in embedded devices is mainstream transactional semantics applied to flash storage. Often the programmers are not even aware that each INSERT not framed in an explicit transaction causes a full flush to the medium, which may be disastrous not only to this application's performance, but other concurrent file I/O.
Actually it is not. If you use any applications built for new GNOME, you have to remove old GNOME because the bastards kept the old names of everything but broken the backward compatibility.
Any specific examples? What GNOME has been good about is proper side-by-side installability of incompatible versions of their libraries. GTK+ 3 coexists in my box with GTK+ 2.
, as long as applications remember my preferred dimensions,
This, I must say drives me absoloutely nuts. I stitch frequently between my laptop's small internal screen and a large external screen. If I last ran a program on the external monitor, it will helpfully remember that it last ran way off in the corner and start off-screen.
I actually did not mean restoring the window position, and certainly not making it the same for different resolution screens. This does sound like a bad idea, and it's not what gnome-shell seems to be doing: it places a new window in a "good" position regarding screen size and other windows. My primary work laptop happens to have the same resolution as the monitor I use it with, and I just clone the screen and keep the lid closed (being more of a virtual display monkey), so I don't know how it works across multiple differently sized screens.
Regardless, I tend to agree that developers who absolutely need a separate screen to debug a GUI application are a corner case for GNOME, and the workarounds are not that hard.
The GP described large screens as a "corner case".
No, the article quote specifically mentioned large screens as something they need to address better. See, if you read what people are actually saying and not just let your opinions sway with a wave of mass hysteria, you'll notice they have brains and may have already noticed your issue.
No, they are complaining that they finally got their car customized just the way they wanted, and now the car maker has come back and said that they are taking the car back
Your car analogy fails here. Nobody is taking GNOME 2 back, it's still available in its open source glory and anyone is free to continue hacking on it. Hey, if 10th of the energy in comments here was not wasted as heat, but went into making commits to Cinnamon, wouldn't that be more useful?
I would go so far as to say that many programmers are similar.
I'm a programmer too. I run Eclipse maximized. I fail to see what's the big deal, as long as applications remember my preferred dimensions, which every Gnome application I use either does, or it does not bother me enough to remember that it doesn't.
I guess I'm also one of those ninnies who has two large screens too.
And this makes it more difficult how? I guess even a maximized application uses only one screen.
Slashdot Mirror
Depending on the defaults in mom's camera app and the mail app that might impose its own preferred resolution, you will get the same compressed jpegs with e.g. 5 megapixels of effective image data.
Uh, presumably they'd be doing that because tablets are at the same resolution. And yes, thanks to Moore's law phones are approaching PS3 level graphics. Does this surprise you? Even on a 4-5 inch display that makes a difference, so it becomes acceptable for both.
I can halfway understand the case for tablets, but are you saying that the same game UI can be played equally well on a big TV screen and on a phone, that furthermore has little in the way of input usable for typical 3D games? I guess I'm just not into gaming that much, and certainly not to a compulsory degree that would make me want to play big screen games on a phone.
What are you talking about? Two years ago phones ran like absolute pieces of crap. Even one year ago, for the most part. There was constant stuttering, things weren't that smooth, etc.
Sounds like a typical Android UI experience :) I suspect that part of the drive for multi-core devices is to compensate for poorly designed software that couldn't respond to the user and wait for something else in the same thread.
Only since december or thereabouts have phones actually been getting towards powerful enough to handle everything smoothly.
I have a Nokia Lumia 800, that was released in November and was right then panned as hopelessly inadequate in the Self-Evidently-Important Core Count Smackdown charts. As it happens, I fail to find a case where I would want it to work much faster. Few applications take a little time to load into a useful state, but nothing blocks or causes annoying disruption. I would hazard an observation that one important thing often overlooked is how cleverly the software uses the CPUs that it is given to run on.
Four processors on a smartphone is fairly trivial in cost, so no it doesn't include a significantly larger price point. At the end of the day we're talking a $12 chip versus a $25 chip (maximum) for example.
Let's see how it looks like in retail.
Gaming at sufficient graphics quality to make full HD gaming possible when I hook up to larger displays. I want PS3 level graphics at the least, and that's coming via a) lots of GPU CUDA cores and b) lots of CPU helping out as with known hardware much of the effects rendering (physics etc) can be pushed back on the CPU cores. It's not like consoles don't use them, and that kind of customisation is the whole benefit of having known SoCs used widely.
So you don't want to buy a console and tap its mature and focused market of games, instead you expect game vendors to have come forward to meet your use case and not just provide a shrunken down phone gameplay for mobile use. How many of them already did so? You plug in your phone whenever you need to play, and carry the extra hardware in your phone, putting up with some overhead in size, battery life, etc., even if you don't use it most of the time?
Spot on. Also, this is a more ingenious use of the resolution than just throwing in megapixels for the spec sheet value with no difference to actual image quality for the tiny lens and the respectively constrained matrix size. Without multisampling or other processing, higher resolution matrices may actually produce worse results because sensitivity of individual elements gets lower as they get smaller.
Standby battery life with Google sync, a few IM clients (I run Skype and imo.im), Whatsapp, Viber and so on, should be around 4-5 days.
I wonder what Skype did to achieve this. On N900 and N9, the Skype engine is the monstrous wakeup hog that drains your battery in a day and exchanges packets with various hosts on the network all the time.
Did they subscribe to some push wakeup mechanism where the app can be launched on incoming activity that needs user interaction?
It's not the number of cores that matters, what matters is how you use them.
More cores means better multitasking since threads can run in parallel.
In my experience, many of the cases where people thought they need to use threads were really cases of doin' it wrong.
When you have properly designed asynchronous APIs, inter-process communication, a decent kernel scheduler, and a GPU to offload graphics to, you can do non-blocking UI even on a single CPU, and the difference between single and multiple cores only manifests in performance improvements, often fairly marginal, and hitting different bugs (which good software should not have, of course).
Also, even for handheld devices you are unlikely to find, for example, a single-core CPU that is four times faster than each core of a quad-core CPU.
I've been searching for someone to answer to a simple question: what are the tasks at which you feel your high-end smartphone should be faster, that are not attributed to things like network roundtrips where a faster proc is irrelevant? "Four times faster than good enough" just does not equal to "four times as good" to me, especially if it comes with a larger price point.
Another major advantage of multi-core systems is if a poorly written piece of software locks up it is highly likely to also be single-threaded and your system will chug along nicely despite the misbehaving program, allowing you to kill the process (by comparison, on a single-core system you're likely to suffer through five minutes of waiting for the system to respond before you are able to kill the process). Sure, in an ideal world this wouldn't happen but when it does happen it's nice to not be locked out of your system because of a single process misbehaving.
Unless we are talking of processes with privileged scheduling which should be part of the system and therefore should be well-written, which modern smartphone OS can't preempt a process that has locked up?
Not two years ago everything in the smartphone world worked nicely on a single core, and everybody except extreme performance junkies were happy with that (can't vouch for Android users, their pain tolerance threshold appears to be higher), what happened since then?
Also Sweeden I guess, both my Saab and Volvo did the same. On the other hand, the lighting conditions are quite bad for the majority of the year over there therefore it makes sense.
I wouldn't say so: depending where you are, for a good part of a summer, you can see around at night with no artificial light. I think it's more about safety-mindedness than anything else.
I don't think the headlight one with engine thing is a requirement by law or regulation.
Not in the US, but in parts of the EU it seems to be the case, probably highly correlated with headlights mandatory to be on while driving at all times. Every car I've driven in Finland (I'm a fresh driver, and I have only driven recent builds so far) turned on driving lights upon engine start, no extra switches required.
The cars in Germany have an idiot-proof option as well: you can just keep the switch at full-on at all times, and the car will turn the lights off when the engine is off, so the battery won't be draining like it would in my car (mine will leave the parking lights on, and peep worriedly when I exit the driver seat).
It probably works like it does in my car, bought in Finland and produced in Burnaston, UK: the "default" (historically marked as "0") is low-beam headlights, but you can get it down to parking lights. Not that you should, when you are actually driving.
I was the unintentional jackass when I first rented a car in Germany: it turned out there are still countries with cars where the headlights do not always turn on whenever the engine is running. I even shrugged off the first guy behind who flashed his lights at me, thinking he's an impatient twit.
Your point about the interface between the lit and the non-lit is correct, but it has unintended consequences. I did a fair amount of research into street and highway lighting as part of astronomy related "dark sky" issues. Some things are counter intuitive. It would seem that the brighter the light, the better and safer the roadway would be. That might be true when entering a well lit area, but upon leaving it, you will see much less until your eyes adapt.
It'd be interesting to see any research on how sodium-vapor lights help with this. The orange-yellow lighting is commonly used on roads at least where I'm driving, and apart from being an affordable and energy-efficient technology, it may work akin to the red lighting used by submariners, or it may not: accordingly to Wikipedia, LPS emission spectrum hits the peak sensitivity spot of the human eye.
Actually, when the push came to shove, Russia's finances were in a bad shape as well, so they refused even a revised loan of $500 million.
Here's an interesting article that says Microsoft (pronounced 'Ballmer') missed the boat: http://minimalmac.com/post/17758177061/microsofts-biggest-miss Tablets in general are proof that Microsoft Office is not 'required' to do useful work.
Tablets are proof that people who have no idea how that useful work is done can tout the latest fad as a solution for every need.
I've seen how this happens:
1. Gee, I can just fire INSERTs in SQLite like I did in SQL Server, isn't it convenient?
2. (few months in development) Crap, these queries thrash the flash medium and cause a lot of waiting on I/O, we need to batch them and use transactions more.
3. (with deadlines looming) Attempts to tweak the database access flags or even relax the durability requirements, to get out of the corner we have painted ourselves into.
It would be instrumental for better performing code if database access was always treated as slow and therefore asynchronous, but SQLite does not provide an easy-to-use async API.
Do you have any idea what are you talking about?
The GP probably does, but SRAM is still prohibitively expensive for any practical memory size for a smartphone.
And if you have to use SQL for whatever reason, don't use indices unless absolutely necessary. It seldom is, despite what school has taught you. The index has to get updated too, which causes additional non-sequential writes. The minor speed boost you may get from selects are easily eaten up by the major speed bumps you cause on inserts and updates.
In many applications reads (SQL SELECT) happen much more often than writes. In this case, indexing still brings an overall benefit. In fact, the hardware architecture of flash memory is tilted to fast reads versus very slow writes, so if you have to do any writes at all, you already pay the price. The non-sequentiality issue is also mooted by controller sicruitry in bulk flash devices like SD cards, which reallocates logical buffers for wear leveling, hiding bad blocks, and write optimization.
The real issue with SQL in embedded devices is mainstream transactional semantics applied to flash storage. Often the programmers are not even aware that each INSERT not framed in an explicit transaction causes a full flush to the medium, which may be disastrous not only to this application's performance, but other concurrent file I/O.
Uh oh. There is a war on, the war for users, and "we" must win.
Get a life.
True. The Alternate Tab extension made my peace with GNOME 3, and then it got improved to cycle the current screen first.
Actually it is not. If you use any applications built for new GNOME, you have to remove old GNOME because the bastards kept the old names of everything but broken the backward compatibility.
Any specific examples? What GNOME has been good about is proper side-by-side installability of incompatible versions of their libraries. GTK+ 3 coexists in my box with GTK+ 2.
Well, sorry about not using 12 xterm windows with vim or whatever it is for you. I can't feel your pain.
, as long as applications remember my preferred dimensions,
This, I must say drives me absoloutely nuts. I stitch frequently between my laptop's small internal screen and a large external screen. If I last ran a program on the external monitor, it will helpfully remember that it last ran way off in the corner and start off-screen.
I actually did not mean restoring the window position, and certainly not making it the same for different resolution screens. This does sound like a bad idea, and it's not what gnome-shell seems to be doing: it places a new window in a "good" position regarding screen size and other windows. My primary work laptop happens to have the same resolution as the monitor I use it with, and I just clone the screen and keep the lid closed (being more of a virtual display monkey), so I don't know how it works across multiple differently sized screens.
Regardless, I tend to agree that developers who absolutely need a separate screen to debug a GUI application are a corner case for GNOME, and the workarounds are not that hard.
The GP described large screens as a "corner case".
No, the article quote specifically mentioned large screens as something they need to address better. See, if you read what people are actually saying and not just let your opinions sway with a wave of mass hysteria, you'll notice they have brains and may have already noticed your issue.
No, they are complaining that they finally got their car customized just the way they wanted, and now the car maker has come back and said that they are taking the car back
Your car analogy fails here. Nobody is taking GNOME 2 back, it's still available in its open source glory and anyone is free to continue hacking on it. Hey, if 10th of the energy in comments here was not wasted as heat, but went into making commits to Cinnamon, wouldn't that be more useful?
I would go so far as to say that many programmers are similar.
I'm a programmer too. I run Eclipse maximized. I fail to see what's the big deal, as long as applications remember my preferred dimensions, which every Gnome application I use either does, or it does not bother me enough to remember that it doesn't.
I guess I'm also one of those ninnies who has two large screens too.
And this makes it more difficult how? I guess even a maximized application uses only one screen.