MeeGo will simply fail because of the arrogance of the Qt developers.
Technical reasons: o one can NOT ask them on blogs, Jira, nor Twitter why Qt has such an uncompetitive and huge footprint in memory and storage for embedded, besides normal desktop o they don't care their software rendering path (new in 4.x and influenced by AGG) is also bloated in memory/storage and hurts them in the long-run for OGLES acceleration o they have 3-4 renderer paths inside Qt which all sit there taking RSS in the.so/dlls and is STILL without a clean, straight OGLES rendering path involving no such side conversions through an optimized specialized-purpose lib load (ie, instead of libGUI with EVERYTHING, libGUI_GL) o pointing out footprint issues AFTER using their qconfig and lots of work to already optimize/slash footprint, but devs will say you're an idiot and use qconfig.... Exactly, wth. o one can NOT file a bugs in their Jira that Qt Creator takes 2x more memory than the MSVC equivalent (for even Qt code itself) without getting it shut down as invalid o if you submitted patches to switch their naive optimizations to tune toward more footprint-savings (because -O2 creates uselessly-bloated libs that aren't any benchmarked faster on mobile) they will "take it under consideration" and then ignore it o if you submitted patches into their Jira and are not a primary partner like Nvidia, they will nitpick the patch over tabbing and spacing (because it also fixes previous violations of their Style standards), ignore it the patch, and let it die on the vine
Qt is simply not tuned for mobiles. Their internal forking of it as "Mobility" subversions helps themselves even less.
It's been said it's a planetary gear system. That's 5 gears at least and the same CVT setup as Toyota's. That's not more efficient and better than Toyota esp when Toyota has been innovating in this space a lot longer.
You don't necessarily need high RPMs for ultimate efficiency until hill-climbing in a Prius. Therefore, noise is easily modulated for normal road driving at a manageable industry-wide ICE 2-3K RPMs for a constant-speed workload.
Your citation also proves that moderate ridership is more efficient than cars. It also ignores that train systems run LESS train-cars and less trains during non-commuter hours to even out density per total number of train-cars.
Factoring these in, plus lower maintenance costs of rail vs asphalt, mass-transit is still a win.
Due to the HSD planetary gearing, the Prius can not only direct drive the wheels, but also charge the batteries at the same time. The ICE runs at optimal RPM and the excess power is leached through the motor/generator back to the battery. There's even times when it can charge the battery while driving uphill.
It does this with a 60mph. Maintaining speed due to frictional losses from wind resistance doesn't take that much HP. This is also why the Prius has low drag coefficient.
Just to note, the Toyota HSD ICE always runs at optimum RPM to drive wheels OR charge because the HSD planetary gear system decouples the engine RPMs from the wheel rpms. In fact, the generator and motor is the same thing for Toyota depending on which direction current flows through it.
Since this has been there since day-one for Toyota, I fail to see how this is an advantage on the Volt's side. Meantime, it's a disadvantage to have an ICE drive a generator to drive a motor due to energy conversion losses from mechanical->electrical->mechanical. It is definitely better to direct drive the wheels, even with the slight loss from planetary gearing instead of clutch.
Wtf, the planetary gearset IS the mechanical linkage between the wheels and the engine. On the Prius, the center gear is driven by the ICE, and the outer ring is driven by the electric motor. Together, they drive the axles of the wheels.
If the Volt is using the same system, it's violating Toyota-patents on this.
Since this planetary gearset is what Ford originally patented on the Model-T, and not much different from a differential, then might as well claim there's no mechanical linkage between the engine and wheels if any differential is involved.
Yes, because there's no big government and lobbyists with enough money to pay them down. Then without market regulation from big government, the corn economy can burn and crash constantly driving farms out of business.
Until Silicon Valley has consolidated into ONE company that is hugely SUCCESSFUL at doing everything, their multitude existence speaks more loudly of how their words are bold-faced naive.
Just scale it up, and imagine what a small USA government can't do. Welcome back to third-world agricultural, Dickens, industrialization-level America.
Full of it. Since these CEOs don't have to directly deal with centralization, they only see the bottom line numbers which are entirely deceptive.
Centralization increases bureaucracy by putting all your eggs in one basket. This central authority will not care to do anything faster (because of overload, or by tenure sloth) and nothing you can do can threaten them to do move it. Been to the DMV, worked with SAP?
Also centralization makes it loose mobility and locality awareness/experience that it could use to optimize its processes. This is where secret Linux servers will pop up to work around all the centralized Windows server standardization. Forcing people to work outside the system to get things done is poor architecture.
Meantime, this also spells unemployment because it'll cut a lot of jobs in an economy that needs to keep people working. You can't cut your way into growth and success.
This is optimization of the pea next to the watermelon that is military spending.
No kidding! I get the same experience with Qt by Nokia where I report a memory bloat bug with Qt Creator or portability bugs with their blog examples. They either delete the bug or ignore it. Wtf?
Seems to push their buttons if you submit bug fixes too.
Sierra Mist Natural.. real-sugar and 2L of it at a time, if you can drink that much -- considering how natural sugar drinks do make you feel full faster than HFCS drinks.
That was an old study in Discover, or something, that claimed that because Asian countries didn't drink that much milk nor consumed other animal proteins, their prostate cancer and morning sickness levels were much lower.
Everything is bad for if you concentrate a diet on it.
How about this, don't friend people you don't really know then. QED.
Alternatively, use Facebook's filtering, and stop being a pithy twit giving up info about yourself; whatever happens, it's self-inflicted. Most robberies are by people you know.
I appreciate your reply, but I don't feel you've read mine. You also don't seem to have any experience with pkgsrc, nor Ports.
I did name yum, and I'm installing RPMs meant for the system, specifically FedoraCore9.
As a specific example, why does the Mercurial RPM from FC project have ANY FC release dependency? It should be dependant only on if I have a minimal Python, and associated packages available. Same with git.
I should be able to install the latest Python/Git without worrying about how old my FC is. Why doesn't yum either pull the RPM updates for my current FC, or pull the SRPMs to rebuild them if there's incompatibility along with side-by-side support and dependencies? Without that, RPM Hell.
Why can't I install multiple versions of gcc at the same time? Why is gcc2.95 dependent on any specific FC release, again? The only thing it should need is a patch system for migrating it from the upstream to the current directory structure, nothing else.
I know specifically that Ports/pkgsrc supports gcc2.95 and toolchain, and forward, for newer OS releases because they update their upstream app patches. Side-by-side installation with the latest gcc4.x (and any number of other gcc versions) is also supported; really.
RPM Hell is losing RPMs for apps just because the OS updated, and has nothing to do with ABI breakage. The lack of distributed or hosted SRPM configuration updates is what it is.
This is my view of one of the things that has driven many toward apt and.deb and Ubuntu; RPM Hell.
In the real world of corporate dev, multiple versions of everything have to be installed and maintained due to releases that are very dependent on specific "bugs/characteristics" of that toolchain.
Companies spend a lot of man-power to privately and individually maintain that RPM Hell (by building from source instead), when RH/FC could easily mirror what Pkgsrc/Ports does already, and has been doing for years, as shared effort.
But, as you've demonstrated, there's very little interest, and so the RPM Treadmill is born. Either keep the OS up to date, or be screwed out of any app updates within one year.
Slashdot Mirror
Plugin-rebuttal.
Wow, programming strategies based on a strawman (re Taco Bell) argument. Has "win" written all over it.
MeeGo will simply fail because of the arrogance of the Qt developers.
Technical reasons: .so/dlls and is STILL without a clean, straight OGLES rendering path involving no such side conversions through an optimized specialized-purpose lib load (ie, instead of libGUI with EVERYTHING, libGUI_GL) ... Exactly, wth.
o one can NOT ask them on blogs, Jira, nor Twitter why Qt has such an uncompetitive and huge footprint in memory and storage for embedded, besides normal desktop
o they don't care their software rendering path (new in 4.x and influenced by AGG) is also bloated in memory/storage and hurts them in the long-run for OGLES acceleration
o they have 3-4 renderer paths inside Qt which all sit there taking RSS in the
o pointing out footprint issues AFTER using their qconfig and lots of work to already optimize/slash footprint, but devs will say you're an idiot and use qconfig.
o one can NOT file a bugs in their Jira that Qt Creator takes 2x more memory than the MSVC equivalent (for even Qt code itself) without getting it shut down as invalid
o if you submitted patches to switch their naive optimizations to tune toward more footprint-savings (because -O2 creates uselessly-bloated libs that aren't any benchmarked faster on mobile) they will "take it under consideration" and then ignore it
o if you submitted patches into their Jira and are not a primary partner like Nvidia, they will nitpick the patch over tabbing and spacing (because it also fixes previous violations of their Style standards), ignore it the patch, and let it die on the vine
Qt is simply not tuned for mobiles. Their internal forking of it as "Mobility" subversions helps themselves even less.
You're slamming it wrong?
Slashdot ate it. The Prius direct drives the wheels and charges the battery with less than 100hp engine at speeds more than 60mph.
It's been said it's a planetary gear system. That's 5 gears at least and the same CVT setup as Toyota's. That's not more efficient and better than Toyota esp when Toyota has been innovating in this space a lot longer.
You don't necessarily need high RPMs for ultimate efficiency until hill-climbing in a Prius. Therefore, noise is easily modulated for normal road driving at a manageable industry-wide ICE 2-3K RPMs for a constant-speed workload.
Your citation also proves that moderate ridership is more efficient than cars. It also ignores that train systems run LESS train-cars and less trains during non-commuter hours to even out density per total number of train-cars.
Factoring these in, plus lower maintenance costs of rail vs asphalt, mass-transit is still a win.
Due to the HSD planetary gearing, the Prius can not only direct drive the wheels, but also charge the batteries at the same time. The ICE runs at optimal RPM and the excess power is leached through the motor/generator back to the battery. There's even times when it can charge the battery while driving uphill.
It does this with a 60mph. Maintaining speed due to frictional losses from wind resistance doesn't take that much HP. This is also why the Prius has low drag coefficient.
Just to note, the Toyota HSD ICE always runs at optimum RPM to drive wheels OR charge because the HSD planetary gear system decouples the engine RPMs from the wheel rpms. In fact, the generator and motor is the same thing for Toyota depending on which direction current flows through it.
Since this has been there since day-one for Toyota, I fail to see how this is an advantage on the Volt's side. Meantime, it's a disadvantage to have an ICE drive a generator to drive a motor due to energy conversion losses from mechanical->electrical->mechanical. It is definitely better to direct drive the wheels, even with the slight loss from planetary gearing instead of clutch.
Wtf, the planetary gearset IS the mechanical linkage between the wheels and the engine. On the Prius, the center gear is driven by the ICE, and the outer ring is driven by the electric motor. Together, they drive the axles of the wheels.
If the Volt is using the same system, it's violating Toyota-patents on this.
Since this planetary gearset is what Ford originally patented on the Model-T, and not much different from a differential, then might as well claim there's no mechanical linkage between the engine and wheels if any differential is involved.
Don't forget GM has been billing the Toyota transmission as "more complicated" than the Volt's. Irony on irony.
Yes, because there's no big government and lobbyists with enough money to pay them down. Then without market regulation from big government, the corn economy can burn and crash constantly driving farms out of business.
Right!
Until Silicon Valley has consolidated into ONE company that is hugely SUCCESSFUL at doing everything, their multitude existence speaks more loudly of how their words are bold-faced naive.
This is small government, letting your house burn down:
http://thelede.blogs.nytimes.com/2010/10/06/tennessee-firefighters-watch-home-burn/
Just scale it up, and imagine what a small USA government can't do. Welcome back to third-world agricultural, Dickens, industrialization-level America.
You gotta pay to be in first-class.
Full of it. Since these CEOs don't have to directly deal with centralization, they only see the bottom line numbers which are entirely deceptive.
Centralization increases bureaucracy by putting all your eggs in one basket. This central authority will not care to do anything faster (because of overload, or by tenure sloth) and nothing you can do can threaten them to do move it. Been to the DMV, worked with SAP?
Also centralization makes it loose mobility and locality awareness/experience that it could use to optimize its processes. This is where secret Linux servers will pop up to work around all the centralized Windows server standardization. Forcing people to work outside the system to get things done is poor architecture.
Meantime, this also spells unemployment because it'll cut a lot of jobs in an economy that needs to keep people working. You can't cut your way into growth and success.
This is optimization of the pea next to the watermelon that is military spending.
No kidding! I get the same experience with Qt by Nokia where I report a memory bloat bug with Qt Creator or portability bugs with their blog examples. They either delete the bug or ignore it. Wtf?
Seems to push their buttons if you submit bug fixes too.
Sierra Mist Natural.. real-sugar and 2L of it at a time, if you can drink that much -- considering how natural sugar drinks do make you feel full faster than HFCS drinks.
That was an old study in Discover, or something, that claimed that because Asian countries didn't drink that much milk nor consumed other animal proteins, their prostate cancer and morning sickness levels were much lower.
Everything is bad for if you concentrate a diet on it.
You mean the mercenary company formerly known was Blackwater.
Sierra Mist Natural is out.
That's right, 2 LITERS of no HFCS soda to be had.
How about this, don't friend people you don't really know then. QED.
Alternatively, use Facebook's filtering, and stop being a pithy twit giving up info about yourself; whatever happens, it's self-inflicted. Most robberies are by people you know.
This explains why the HD2 running Froyo 2.2 suddenly got fully working Broadcom WiFi drivers dropped into the git tree a couple of weeks ago.
http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=commit;h=26c66976c838c956c7b003cec8fd96c7cdac4026
What? All this time and SCO never found this?
I appreciate your reply, but I don't feel you've read mine. You also don't seem to have any experience with pkgsrc, nor Ports.
I did name yum, and I'm installing RPMs meant for the system, specifically FedoraCore9.
As a specific example, why does the Mercurial RPM from FC project have ANY FC release dependency? It should be dependant only on if I have a minimal Python, and associated packages available. Same with git.
I should be able to install the latest Python/Git without worrying about how old my FC is. Why doesn't yum either pull the RPM updates for my current FC, or pull the SRPMs to rebuild them if there's incompatibility along with side-by-side support and dependencies? Without that, RPM Hell.
Why can't I install multiple versions of gcc at the same time? Why is gcc2.95 dependent on any specific FC release, again? The only thing it should need is a patch system for migrating it from the upstream to the current directory structure, nothing else.
I know specifically that Ports/pkgsrc supports gcc2.95 and toolchain, and forward, for newer OS releases because they update their upstream app patches. Side-by-side installation with the latest gcc4.x (and any number of other gcc versions) is also supported; really.
RPM Hell is losing RPMs for apps just because the OS updated, and has nothing to do with ABI breakage. The lack of distributed or hosted SRPM configuration updates is what it is.
This is my view of one of the things that has driven many toward apt and .deb and Ubuntu; RPM Hell.
In the real world of corporate dev, multiple versions of everything have to be installed and maintained due to releases that are very dependent on specific "bugs/characteristics" of that toolchain.
Companies spend a lot of man-power to privately and individually maintain that RPM Hell (by building from source instead), when RH/FC could easily mirror what Pkgsrc/Ports does already, and has been doing for years, as shared effort.
But, as you've demonstrated, there's very little interest, and so the RPM Treadmill is born. Either keep the OS up to date, or be screwed out of any app updates within one year.