So the PC and MSFT are NOT going away, but when AMD and Intel hit the thermal wall and decided to switch from the MHz war to the core war the chips they produced, hell even for the low end like the Athlon triples or the first gen Core based Pentiums on the laptops, are just sooooo damned powerful the users just aren't stressing them so they just ain't needing replaced nearly as often.
I predict we have less than 3 years before we see mobile, which TFA thinks is to blame (Protip: Its not) have the same damned thing happen to it that happened to X86.
Yes, and even less than that I'd bet. The latest ARM implementations, whether Cortex A15 or Krait, are already hitting a thermal wall. When benchmarking the latest Qualcomm quad-core S4 based on Krait on Nexus 4 and the cousin LG phone Anandtech saw some discrepancies in the benchmarks results that they eventually traced to thermal throttling. On one phone they had to run the benchmark is several goes due to software issues, and it had better results than on the phone where the benchmarks all run in one go. The only difference was due to cooling between tests on the first phone. To prove the point and avoid the effect they benchmarked both phones in a zip bag in a freezer:-P
Just as for PC chips we'll still see some incremental improvements with new processes and tweaks, but I expect this mobile next gen to be able to last for a while.
I don't think so (but I'm not in this business either, so this is just my opinion).
These ARM servers are not for the general public. A lot of servers now go to the Facebook, Google and Amazons. These guys run their own stacks based on open source, so are not much tied to any ISA. Linux based software run fine on ARM. And they have a lot of loads that are I/O bounds (network mostly), so no need for huge CPU. And costs are critical, both in term of cost of hardware and power consumption (direct and cooling) as the services are often free. ARM is well know for its power efficiency, and the prices and margins are much lower than what Intel is used too.
These companies are the targets for ARM servers in a first step IMHO. Some already have expressed interest so it's not science fiction there: Facebook has join Linaro server workgroup recently for example. Once you have a foot there, you can scale later on to other markets. I don't expect ARM servers to go head to head with Intel in single thread performance for a long while, but I don't think they need to have good business either.
It is not clear that they can beat future Intel CPUs on power usage, especially since Intel's manufacturing process leads the industry by a significant margin.
Everybody says that, but it's only true for the high performance / high power consumption process variant. It's not true for the lower power variant(s), which have some differences and are more tricky than the high perf ones (I'm not an expert on this but one issue for example is that LP needs larger wires to reduce resistance and power consumption. This requires in turn more precision to avoid shorts between wires. People who know more on this topic, please share. It's important to understand how the race can turn in the low power area). For low power Atom chips Intel is right now on 32 nm, while TSMC has been on 28 nm for a while now. It's a one year and half-node advantage for TSMC clients. And Samsung is also now on 32 nm (par). Intel announced they will speed up the availability of new finer processes for low power in the future, but based on their respective announcements Intel and TSMC would be on par for LP (we'll have to see how this turns out in practice...).
This means that ARM clients can have a competitive process in the low power space today, and possibly tomorrow. It's likely that ARM clients would focus on many cores / low power servers for I/O bounds loads. They can be competitive there, and gain a foothold. Going to higher single thread performance can come later, it would be hard to attack Intel there in the short / medium term anyway. If you pick a fight, pick one you can win. And the ARM world has more experience in LP.
Yes, but where this matters Robust Header Compression (ROHC, RFC 3095. See also wikipedia) will be used so the IP header overhead is not a problem. And where it matters is over the radio link itself, where capacity is the most constrained. ROHC will reduce the IP/UDP/RTP headers to 1 byte typically. VoLTE (Voice over LTE) requires supporting ROHC in the LTE modem for example.
Actually this does exist. Wacom makes exactly such products (for a steep price). But it's a niche product, and a niche usage. For the discussion here they only care about mass volume opportunities. If it's small volume, however useful to some, it doesn't exist here.
It applies to convertible tablets, that can be used as a laptop with a keyboard (the cover type of the Surface, or any detachable keyboard really). It's not only for the Surface but could also be said for some Android tablet with detachable keyboards. I made a similar comparison, but with a seaplane not a futuristic car. It's not a good plane, it's not a good boat, but it has its uses. But it's not mainstream. So here's my very personal point of view.
I used to think that such hybrid devices would be perfect. Get a tablet and a laptop in the same device, so cool. I changed my mind. The reason is that it's either too small (for my taste) as a laptop, or too big as a tablet. And as a laptop the balance is all wrong: to have a stable laptop you want a light screen part and the weight on the bottom part, so it can easily rest on any surface and be stable. A convertible tablet has too much weight in the screen. So you need to put them on a table to be stable, which is less convenient. It's a tabletop not a laptop;)
In the end I much prefer a true light laptop with a true light tablet (7" for me, I don't agree with Apple on that). Combined it's both lighter than my previous laptop, so no big deal. And they're better for their dedicated use-cases: the tablet as a simple "potato couch" / consuming device, the laptop for productive work. Plus I've no problem giving the small and cheap tablet to the kids, and I can to use the laptop in parallel. As for having separate devices, it's really no big deal. There are tons of ways to sync information across devices conveniently. And having different OS on both devices is a non issue too.
But really, to each his own here. It's more a matter of taste and priorities than anything. If you really need a single device for any reason, then why not a convertible tablet. Just like a seaplane, there will be use-cases where it's best. I don't know if my tastes are mainstream here or not on that topic, we'll see. But if the majority think like this I don't see much future for convertible tablets in the consumer space (actually, did many people bought the external keyboard for the Asus convertible for example? I'm not sure). Maybe for the professional space, for some applications (input while on the go,...). But it's not the same volume at all.
Write the same sum but in the other direction just below the previous one, and sum both lines term by term. Notice you have N times N+1, and that's for twice the sum. So one half for a single line. A visual way to let a kid old enough to know multiplication tables to find it for small cases is to draw the sum as dots on a piece of grid paper as a rectangular triangle. Then double the triangle (symmetry on the long edge) and you get a rectangle where the number of dots can be computed with a simple multiplication.
The antenna gain do have an impact on the power consumption. In the transmit side the device power is controlled by the base station to reach a given level at the BS receiver. For a given channel condition a phone with better antenna gain will need to transmit at a lower power than another with a poor antenna to reach the same radiated power, and received power at the BS. So the transmit power amplifier (PA) gain will have to be bigger to compensate for a poor antenna, and the power consumption increase with it. At high gain, a few dB of output can make a big difference.
On the receive path power consumption is not an issue. But the system sensitivity will depend on the antenna gain too. With a better antenna you will receive a higher signal level, all other things being equal. That translates to less drop calls, or higher throughput.
I haven't read TFA (this is/. after all), but yes antenna designs if VERY important in devices. And it's particularly challenging in smartphones, where there are many of them to fit. It's galling to fight on the cellular modem side to scrap tenth of dBs, to see the waste in some antenna designs. But I can sympathize too, it's a too problem when you have so many antennas in a small form factor.
There is a minimum noise floor level in any system (thermal noise). This puts a lower bound on the useful sensitivity as there no point in going much under this floor. And current implementations are very close. So here again, we have a close physical boundary that limits possible gains.
You should take this Intel announcement with a big handful of salt. Intel doesn't make the waver producing machinery, they get it from companies like ASML.
Now, there's been a big struggle between companies like Intel that wanted 450mm earlier, and the tool makers who sank a lot of money on the move to 300mm before and don't want to be burned again in the move to 450mm. The Intel announcement above was to put pressure on the tools providers. It didn't worked out in the end.
All this got sorted out between big boys recently, with Intel, TSMC and Samsung investing a lot of money in ASML to speed-up the availability of 450mm. But the accelerated roadmap has nothing to do with the announcement you quote, just look at it from ASML direct (slide 14). The 450mm process development tools are worked on starting mid-2015 and production equipment is available beginning of 2018. Exactly what is said in the TFA.
450mm is important as it is the only known step that will bring the cost of chips down. Other planned changes (finer processes, 3D chips...) increase performance but also cost. But 450mm requires huge upfront investments, so you need large volumes to recoup it and it will require a big upfront spending. Which is why a lot of people are pushing back. Intel has both high volumes, high margins and deep pockets so they're the most eager to get started. But as you can see, even with their backing it's not that simple and fast.
Debian isn't a desktop distribution, you got Ubuntu for that.
In a professional context Debian is a perfectly fine workstation desktop distribution. With the longer cycles and better linux support of professional hardware I've never seen big issues, except maybe using a newer kernel for a brand new model. Which is no big deal to handle in a professional context. I've seen Debian deployed on hundreds of workstations with no problem.
Even for home use I stick to Debian. Yes, the out of the box support is not as good as a recent Ubuntu. But the stock stable is usually ok to start (with some limitations). Then grabbing a more recent kernel from backport, or maybe testing/unstable, was always enough to have perfect support in my limited experience.
And then I can benefit from a very stable distribution, where the package maintainers have a personal interest in their own packages. And from my admittedly limited experience outside Debian this makes a difference. I've been frustrated with some commercial distros I tried long ago with some packages that were half-broken. I'd rather have to fiddle a bit at first, but then be able to depend on good packages than having a nice install with bad surprises later on.
That's not applicable to all, and to each their own, but if you are a bit linux savvy you may want to try it.
As a side note, I've recently I've seen people lamenting the lack of stability on linux compared to other OSs (can't remember if it was/. or HN...). They always compared fast moving linux distros to slowly moving other OSs. Well, if you want stability with linux pick a slow moving linux distro! For professional use I've found you don't need a bleeding edge distro, and neither for personal use as far as I'm concerned. Every person will likely need a few different bleeding edge tools for sure, but that's easy to handle (backport, side installs...).
Do you (or anyone here) know about the power consumption when the transistor switches and how it compares to a silicon transistor? Today on silicon the frequency is often limited by power consumption / thermal considerations. In other words, we know how to go faster on silicon but we don't. If graphene is faster but not more power efficient, then it could limit it's use to the few applications where power / thermal are not a constraint. If it's more efficient, but not much, that could also limit the speed gain (power increases linearly with the frequency). So it seems the power efficiency is key, but I haven't seen anything about that (not that I've searched either, but at least I've RTFA;).
I'm not sure that MIPS is so well placed in the high-end. Yes, they've been high end a long time ago and have had 64 bits support for ages. But today it's a different game, they provide embedded IP now. And where ARM can help their customers optimizing the implementation for a given process (ARM gains this experience by making hard macros and working closely with TSMC, GlobalFoundries...), MIPS has much less resource and just do soft macros. Then up to you to do the optimization. In other words, if you go ARM for an embedded high-performance SoC IP you can leverage a lot of work that ARM does, that you will have to do with MIPS. To get an implementation that is less common in the end.
So the high end may be tough for MIPS. But in the medium end, where price is critical and performance less so, they can be an interesting choice.
ARM uses some 0.1-1.0W, MIPS uses 10-20W for slower clock speeds.
Not anymore, by far. Forget about MIPS as in Silicon Graphics workstations ages ago. Now MIPS is an embedded IP provider, very similar to ARM. And they do have low power cores quite similar to ARM. Who is on top in mW/MHz changes over time, but MIPS do have some competitive offers.
Now what ARM has for it is that it became the defacto architecture for mobile (nobody got fired to chose ARM and all that), and it has much more resources than MIPS. So ARM has a more extensive IP offer, and can work on process optimization too. By this I mean that where MIPS will provide a soft core in RTL, ARM can also provide hard macros optimized for some fab process. And even if you want to go soft core and optimize yourself, ARM can provide a ready to use optimization package to get you started.
ARM has fixed-width single-decode instructions; MIPS has three types of instructions of variable width.
No, they're actually very similar: their native instruction size is 32 bits, but both support a 16 bits instruction mode which is in its second generation in each case (Thumb2 for ARM, can't remember the MIPS name... Maybe MIPSe?).
MIPS is slow. You may as well put an Intel CELERON in there if you go MIPS.
Why the comparison with a discrete chip? MIPS do no sell discrete chips anymore, it's all IP. Then in IP they have offer that are performance competitive with the same class ARM. I'd give the edge in the high end to ARM though, thanks to their close work with the fab to optimize their implementation.
China is a very big and diverse country, and going China doesn't necessarily mean going low cost nowadays. Costal China is first world (or close enough already, in any case not 3rd world by far), with a very high adoption rate for smartphones. And not crappy ones, also high end ones. Plus, Android is impaired in China by no official Google Play support if I understand correctly, and side channels are full of malware making Android reputation poor. The iPhone doesn't support TD-SCDMA so is not carried by the first operator, China Mobile. WP is mostly nowhere (as everywhere). There is a gap to fill there, and if you come with a new OS it may be easier to get a foothold in such a context than in Western countries with entrenched iPhone and Android, and only a few slahsdotters like me possibly interested in a Meego phone;) Historically China Mobile was interested in Meego for this reason BTW. And Nokia was very popular there. So there could be a card to play for a well spec'd phone in China, seen as a successor to the old Nokia.
In all fairness LTE is more efficient than WiMAX for a given bandwidth and frequency, but it's not earth shattering. Let's say roughly a 15% gain (to be taken with a dash of salt, it's from memory).
The important point to understand when making a comparison is that it's not only the protocol used that matters, the bandwidth available and the frequency used have very important effects. In the case of WiMAX in the US, it's only been deployed in at high frequencies (2.6 GHz). The higher the frequency, the bigger the attenuation with distance, and hence the lower the reach. Getting a good coverage when you only have 2.6 GHz is a challenge, and that's what impaired WiMAX in many cases. What you'd rather do is use both a low band (700 or 800 MHz) for good coverage, with high bands (2.6 GHz for example) for capacity but only where it matters (to keep costs in check). The combination allows both good coverage and capacity, and will be quite common in LTE deployments. Verizon has started LTE deployments in 700 MHz, to get a good coverage quick. As subscribers increase, they will open higher bands (AWS in their case IIUC) to add capacity.
So keep an eye on the spectrum used when doing comparisons.
A handset radio subsystem is made of three parts: 1) the modem baseband, doing the digital processing, 2) the RF, pushing the signal between baseband to/from the final RF frequency and 3) the RF front-end (RFFE), doing the filtering and possibly low noise amplification in the reception direction, and power amplification (PA) in the transmit direction.
Now every time multi-bands support comes up, someone says "SDR" as the magic solution. But SDR applies to the modem baseband part only, and is actually quite common in many existing LTE devices. And it's irrelevant to this issue: the baseband, even if hardware centric, has no problem supporting any bands. Same for most recent RF chips: they're also multibands already.
The issue is the RF front-end: those filters are specific to a given bands. You want more bands? You need more filters (and possibly switches, unless the RF chips has enough separate ports) and this add cost and space on the PCB. And then there are the PAs. For now the wider the PA, the lower its efficiency (and even "wide" PA do not cover all bands, just a few 100s MHz at most). Low efficiency means higher battery consumption and higher heat (which degrades the efficiency too). There's a solution coming hopefully soon for PAs, called envelope tracking (ET). It should enable both efficient and wideband PAs. For filters, I haven't heard of any reasonably sized and cheap programmable filters with proper performance. That's the bottleneck for now. I someone can crack this nut, there's a big market to gain.
I think all mobile environment have a well defined radio interface layer (RIL) similar to what's in Android. There's something specific to Blackberry thought, it's that in 2G/3G they have their own protocol stack. It's still run on an external baseband modem chip made by others (Freescale from memory, but I may be wrong there), but the PS is BB own and not made by the modem chip vendor as is now more common. This used to be a common model when the modem was the key to a phone, as it was important to be in control and it was possible for the phone vendor to make a difference there. Now the model has changed, and the modem chip provide both the hardware and the associated protocol stack.
So maybe on LTE BB wanted to have their own stack (and even maybe modem hardware?), and didn't prioritize it as they had so much else to do and believed LTE would arrive later. When LTE took off very quickly, they got caught without an internal LTE, and possibly with a company culture that made it difficult to turn to an external provider. This is just a guess, but at least it looks possible.
The "in-house" modem development is not totally dead yet. In other big players you can find such in-house development: Moto do their own LTE hardware and stack (but for how long still?), Samsung does it too and LG did it partially in collaboration with GCT. Contrast this with Apple and HTC who just get the full modem subsystem from a third party (now Qualcomm in both cases). If you have the skills and volume it may make sense to do it yourself (Samsung), but when you have limited resources and volume this is more questionable and we'll see if this trend continue (Moto, LG).
Unfair at least for KDE, as there are different interfaces for tablets (touch based, still prototype level it seems to me), netbooks (small screen) and laptops/desktops (big screen). One of the key point of the big KDE change with version 4.X and plasma is that, as you said, a universal UI would suck. So you need different UIs optimized for each use cases. But to make this practical, you want to same foundation software underneath to minimize the changes and development costs and limit them to an as small as possible UI layer on top of a common application engine. KDE 3.X couldn't support this, while KDE 4.X is designed for this. And on the Qt side, as I understand the move to QML is also driven by this desire to support different UIs on top of a common core as easy as possible.
For some KDE applications there are alsotouch optimized and classical (mouse/keyboard) versions, although the choice for touch optimized is still much more limited (the Caligra office suite, PIM support, ?...). So the infrastructure part seems more advanced than the applications.
I'm following all this from a distance, so more expert slashdotters feel free to expand or correct me.
Re:What this is really for. (Mod this up)
on
AMD and ARM Team Up
·
· Score: 1
Only the TPM part matters actually.
Cell signaling is not relevant here, for a cellular solution you need RF and DSP functions that are just not there. And don't expect AMD to go into the cellular market, it's a specialist area they don't know about and already crowded. By the way, there's no specific acceleration on the ARM cores for cellular. The part that run on the ARM is the protocol stack and it's regular software. Neon is not even used, it's good for media but for cellular DSP processing you need much more power and use specialized DSP core(s) and dedicated hardware.
And they certainly don't need the A5 to speed up VPN support. This is better handled on a x86 core with AES-NI support.
Because there's an already existing eco-system (with 3rd party sw / solutions providers) based on ARM TrustZone technology, which is supported by the A5. So instead of reinventing the wheel, AMD just reuses all of this for cheap. Performance is a non issue there, you don't run computation intensive software, you run security control software for credentials checks and access control. The A5 is plenty enough for that.
Yes and no. They don't use the Cortex reference designs on their high and middle end application processors (AP), where they have an architecture license and derived their own implementations (Scorpion and Krait). But for low end chips and more embedded use-cases they use some reference designs (they've been using ARM11, and now Cortex A5). This is what the GP is referring too, and he's correct. You can Google the part number to check this.
Yes. It's also the smallest core in their A-line. There are 3 lines of Cortex: M for micro controllers (super small, super cheap, deeply embedded), R for real time (optimized for deterministic response time, no MMU) and A for application processors (A5, A7, A8, A9, A15 so far).
The A5 is commonly used in embedded applications too, as it's quite compact. It makes perfect sense here to leverage all the security applications developed on top of ARM TrustZone system. It's small, puny (compared to the x86 cores it will sit next to anyway, this is all relative) and cheap compared to the rest of the system. A case of not reinventing the wheel, for once.
No, but it had the "-Q" option, which is equivalent to "--no-init-file --no-site-file --no-splash". So you skip what takes most of the time.
On a few years old dual core Xeon @ 2.5 GHz, I get 60 ms like this from a fresh start (nothing cached, basic HD not SSD). By removing the "-Q" to get a more meaningful duration I was surprised to get 360 ms only on a second run. And then below 300 ms for other runs with all cached in memory. Not as fast as vi or jed for sure, but very reasonable. Of course this will depends on the complexity of the init script, but there's already some material here with most of it loaded from NFS (site init). YMMV.
I still remember how long it felt when I started working years ago and yes indeed, it took a few seconds to start emacs. Quite a change!
An A/C unit is a air/air heat pump, and from what I've seen AC is very common in Japan and in Asia in general (but I'm no expert).
There are air/air heat pumps, which move heat between inside and outside air directly and are reversible (used to heat or chill as needed). There are also air/water heat pumps, between external air and an internal water circuit. Those are only used for heating and are less common it seems to me. Where I leave there's a tax break on air/water heat pumps as they're more efficient than electric heaters and are not used for chilling, but air/air heat pumps (AC units really) have no tax break. I guess with an AC unit the temptation to use it for chilling too in summer would be too great and would negate the efficiency gained on heating vs. a basic electrical heater.
Slashdot Mirror
So the PC and MSFT are NOT going away, but when AMD and Intel hit the thermal wall and decided to switch from the MHz war to the core war the chips they produced, hell even for the low end like the Athlon triples or the first gen Core based Pentiums on the laptops, are just sooooo damned powerful the users just aren't stressing them so they just ain't needing replaced nearly as often.
I predict we have less than 3 years before we see mobile, which TFA thinks is to blame (Protip: Its not) have the same damned thing happen to it that happened to X86.
Yes, and even less than that I'd bet. The latest ARM implementations, whether Cortex A15 or Krait, are already hitting a thermal wall. When benchmarking the latest Qualcomm quad-core S4 based on Krait on Nexus 4 and the cousin LG phone Anandtech saw some discrepancies in the benchmarks results that they eventually traced to thermal throttling. On one phone they had to run the benchmark is several goes due to software issues, and it had better results than on the phone where the benchmarks all run in one go. The only difference was due to cooling between tests on the first phone. To prove the point and avoid the effect they benchmarked both phones in a zip bag in a freezer :-P
Just as for PC chips we'll still see some incremental improvements with new processes and tweaks, but I expect this mobile next gen to be able to last for a while.
I don't think so (but I'm not in this business either, so this is just my opinion).
These ARM servers are not for the general public. A lot of servers now go to the Facebook, Google and Amazons. These guys run their own stacks based on open source, so are not much tied to any ISA. Linux based software run fine on ARM. And they have a lot of loads that are I/O bounds (network mostly), so no need for huge CPU. And costs are critical, both in term of cost of hardware and power consumption (direct and cooling) as the services are often free. ARM is well know for its power efficiency, and the prices and margins are much lower than what Intel is used too.
These companies are the targets for ARM servers in a first step IMHO. Some already have expressed interest so it's not science fiction there: Facebook has join Linaro server workgroup recently for example. Once you have a foot there, you can scale later on to other markets. I don't expect ARM servers to go head to head with Intel in single thread performance for a long while, but I don't think they need to have good business either.
It is not clear that they can beat future Intel CPUs on power usage, especially since Intel's manufacturing process leads the industry by a significant margin.
Everybody says that, but it's only true for the high performance / high power consumption process variant. It's not true for the lower power variant(s), which have some differences and are more tricky than the high perf ones (I'm not an expert on this but one issue for example is that LP needs larger wires to reduce resistance and power consumption. This requires in turn more precision to avoid shorts between wires. People who know more on this topic, please share. It's important to understand how the race can turn in the low power area). For low power Atom chips Intel is right now on 32 nm, while TSMC has been on 28 nm for a while now. It's a one year and half-node advantage for TSMC clients. And Samsung is also now on 32 nm (par). Intel announced they will speed up the availability of new finer processes for low power in the future, but based on their respective announcements Intel and TSMC would be on par for LP (we'll have to see how this turns out in practice...). This means that ARM clients can have a competitive process in the low power space today, and possibly tomorrow. It's likely that ARM clients would focus on many cores / low power servers for I/O bounds loads. They can be competitive there, and gain a foothold. Going to higher single thread performance can come later, it would be hard to attack Intel there in the short / medium term anyway. If you pick a fight, pick one you can win. And the ARM world has more experience in LP.
Yes, but where this matters Robust Header Compression (ROHC, RFC 3095. See also wikipedia) will be used so the IP header overhead is not a problem. And where it matters is over the radio link itself, where capacity is the most constrained. ROHC will reduce the IP/UDP/RTP headers to 1 byte typically. VoLTE (Voice over LTE) requires supporting ROHC in the LTE modem for example.
Actually this does exist. Wacom makes exactly such products (for a steep price). But it's a niche product, and a niche usage. For the discussion here they only care about mass volume opportunities. If it's small volume, however useful to some, it doesn't exist here.
It applies to convertible tablets, that can be used as a laptop with a keyboard (the cover type of the Surface, or any detachable keyboard really). It's not only for the Surface but could also be said for some Android tablet with detachable keyboards. I made a similar comparison, but with a seaplane not a futuristic car. It's not a good plane, it's not a good boat, but it has its uses. But it's not mainstream. So here's my very personal point of view.
;)
...). But it's not the same volume at all.
I used to think that such hybrid devices would be perfect. Get a tablet and a laptop in the same device, so cool. I changed my mind. The reason is that it's either too small (for my taste) as a laptop, or too big as a tablet. And as a laptop the balance is all wrong: to have a stable laptop you want a light screen part and the weight on the bottom part, so it can easily rest on any surface and be stable. A convertible tablet has too much weight in the screen. So you need to put them on a table to be stable, which is less convenient. It's a tabletop not a laptop
In the end I much prefer a true light laptop with a true light tablet (7" for me, I don't agree with Apple on that). Combined it's both lighter than my previous laptop, so no big deal. And they're better for their dedicated use-cases: the tablet as a simple "potato couch" / consuming device, the laptop for productive work. Plus I've no problem giving the small and cheap tablet to the kids, and I can to use the laptop in parallel. As for having separate devices, it's really no big deal. There are tons of ways to sync information across devices conveniently. And having different OS on both devices is a non issue too.
But really, to each his own here. It's more a matter of taste and priorities than anything. If you really need a single device for any reason, then why not a convertible tablet. Just like a seaplane, there will be use-cases where it's best. I don't know if my tastes are mainstream here or not on that topic, we'll see. But if the majority think like this I don't see much future for convertible tablets in the consumer space (actually, did many people bought the external keyboard for the Asus convertible for example? I'm not sure). Maybe for the professional space, for some applications (input while on the go,
N*(N+1)/2
Write the same sum but in the other direction just below the previous one, and sum both lines term by term. Notice you have N times N+1, and that's for twice the sum. So one half for a single line. A visual way to let a kid old enough to know multiplication tables to find it for small cases is to draw the sum as dots on a piece of grid paper as a rectangular triangle. Then double the triangle (symmetry on the long edge) and you get a rectangle where the number of dots can be computed with a simple multiplication.
The antenna gain do have an impact on the power consumption. In the transmit side the device power is controlled by the base station to reach a given level at the BS receiver. For a given channel condition a phone with better antenna gain will need to transmit at a lower power than another with a poor antenna to reach the same radiated power, and received power at the BS. So the transmit power amplifier (PA) gain will have to be bigger to compensate for a poor antenna, and the power consumption increase with it. At high gain, a few dB of output can make a big difference.
/. after all), but yes antenna designs if VERY important in devices. And it's particularly challenging in smartphones, where there are many of them to fit. It's galling to fight on the cellular modem side to scrap tenth of dBs, to see the waste in some antenna designs. But I can sympathize too, it's a too problem when you have so many antennas in a small form factor.
On the receive path power consumption is not an issue. But the system sensitivity will depend on the antenna gain too. With a better antenna you will receive a higher signal level, all other things being equal. That translates to less drop calls, or higher throughput.
I haven't read TFA (this is
There is a minimum noise floor level in any system (thermal noise). This puts a lower bound on the useful sensitivity as there no point in going much under this floor. And current implementations are very close. So here again, we have a close physical boundary that limits possible gains.
You should take this Intel announcement with a big handful of salt. Intel doesn't make the waver producing machinery, they get it from companies like ASML.
Now, there's been a big struggle between companies like Intel that wanted 450mm earlier, and the tool makers who sank a lot of money on the move to 300mm before and don't want to be burned again in the move to 450mm. The Intel announcement above was to put pressure on the tools providers. It didn't worked out in the end.
All this got sorted out between big boys recently, with Intel, TSMC and Samsung investing a lot of money in ASML to speed-up the availability of 450mm. But the accelerated roadmap has nothing to do with the announcement you quote, just look at it from ASML direct (slide 14). The 450mm process development tools are worked on starting mid-2015 and production equipment is available beginning of 2018. Exactly what is said in the TFA.
450mm is important as it is the only known step that will bring the cost of chips down. Other planned changes (finer processes, 3D chips...) increase performance but also cost. But 450mm requires huge upfront investments, so you need large volumes to recoup it and it will require a big upfront spending. Which is why a lot of people are pushing back. Intel has both high volumes, high margins and deep pockets so they're the most eager to get started. But as you can see, even with their backing it's not that simple and fast.
Debian isn't a desktop distribution, you got Ubuntu for that.
In a professional context Debian is a perfectly fine workstation desktop distribution. With the longer cycles and better linux support of professional hardware I've never seen big issues, except maybe using a newer kernel for a brand new model. Which is no big deal to handle in a professional context. I've seen Debian deployed on hundreds of workstations with no problem.
/. or HN...). They always compared fast moving linux distros to slowly moving other OSs. Well, if you want stability with linux pick a slow moving linux distro! For professional use I've found you don't need a bleeding edge distro, and neither for personal use as far as I'm concerned. Every person will likely need a few different bleeding edge tools for sure, but that's easy to handle (backport, side installs...).
Even for home use I stick to Debian. Yes, the out of the box support is not as good as a recent Ubuntu. But the stock stable is usually ok to start (with some limitations). Then grabbing a more recent kernel from backport, or maybe testing/unstable, was always enough to have perfect support in my limited experience.
And then I can benefit from a very stable distribution, where the package maintainers have a personal interest in their own packages. And from my admittedly limited experience outside Debian this makes a difference. I've been frustrated with some commercial distros I tried long ago with some packages that were half-broken. I'd rather have to fiddle a bit at first, but then be able to depend on good packages than having a nice install with bad surprises later on.
That's not applicable to all, and to each their own, but if you are a bit linux savvy you may want to try it.
As a side note, I've recently I've seen people lamenting the lack of stability on linux compared to other OSs (can't remember if it was
Do you (or anyone here) know about the power consumption when the transistor switches and how it compares to a silicon transistor? Today on silicon the frequency is often limited by power consumption / thermal considerations. In other words, we know how to go faster on silicon but we don't. If graphene is faster but not more power efficient, then it could limit it's use to the few applications where power / thermal are not a constraint. If it's more efficient, but not much, that could also limit the speed gain (power increases linearly with the frequency). So it seems the power efficiency is key, but I haven't seen anything about that (not that I've searched either, but at least I've RTFA ;).
I'm not sure that MIPS is so well placed in the high-end. Yes, they've been high end a long time ago and have had 64 bits support for ages. But today it's a different game, they provide embedded IP now. And where ARM can help their customers optimizing the implementation for a given process (ARM gains this experience by making hard macros and working closely with TSMC, GlobalFoundries...), MIPS has much less resource and just do soft macros. Then up to you to do the optimization. In other words, if you go ARM for an embedded high-performance SoC IP you can leverage a lot of work that ARM does, that you will have to do with MIPS. To get an implementation that is less common in the end.
So the high end may be tough for MIPS. But in the medium end, where price is critical and performance less so, they can be an interesting choice.
ARM uses some 0.1-1.0W, MIPS uses 10-20W for slower clock speeds.
Not anymore, by far. Forget about MIPS as in Silicon Graphics workstations ages ago. Now MIPS is an embedded IP provider, very similar to ARM. And they do have low power cores quite similar to ARM. Who is on top in mW/MHz changes over time, but MIPS do have some competitive offers.
Now what ARM has for it is that it became the defacto architecture for mobile (nobody got fired to chose ARM and all that), and it has much more resources than MIPS. So ARM has a more extensive IP offer, and can work on process optimization too. By this I mean that where MIPS will provide a soft core in RTL, ARM can also provide hard macros optimized for some fab process. And even if you want to go soft core and optimize yourself, ARM can provide a ready to use optimization package to get you started.
ARM has fixed-width single-decode instructions; MIPS has three types of instructions of variable width.
No, they're actually very similar: their native instruction size is 32 bits, but both support a 16 bits instruction mode which is in its second generation in each case (Thumb2 for ARM, can't remember the MIPS name... Maybe MIPSe?).
MIPS is slow. You may as well put an Intel CELERON in there if you go MIPS.
Why the comparison with a discrete chip? MIPS do no sell discrete chips anymore, it's all IP. Then in IP they have offer that are performance competitive with the same class ARM. I'd give the edge in the high end to ARM though, thanks to their close work with the fab to optimize their implementation.
China is a very big and diverse country, and going China doesn't necessarily mean going low cost nowadays. Costal China is first world (or close enough already, in any case not 3rd world by far), with a very high adoption rate for smartphones. And not crappy ones, also high end ones. Plus, Android is impaired in China by no official Google Play support if I understand correctly, and side channels are full of malware making Android reputation poor. The iPhone doesn't support TD-SCDMA so is not carried by the first operator, China Mobile. WP is mostly nowhere (as everywhere). There is a gap to fill there, and if you come with a new OS it may be easier to get a foothold in such a context than in Western countries with entrenched iPhone and Android, and only a few slahsdotters like me possibly interested in a Meego phone ;) Historically China Mobile was interested in Meego for this reason BTW. And Nokia was very popular there. So there could be a card to play for a well spec'd phone in China, seen as a successor to the old Nokia.
In all fairness LTE is more efficient than WiMAX for a given bandwidth and frequency, but it's not earth shattering. Let's say roughly a 15% gain (to be taken with a dash of salt, it's from memory).
The important point to understand when making a comparison is that it's not only the protocol used that matters, the bandwidth available and the frequency used have very important effects. In the case of WiMAX in the US, it's only been deployed in at high frequencies (2.6 GHz). The higher the frequency, the bigger the attenuation with distance, and hence the lower the reach. Getting a good coverage when you only have 2.6 GHz is a challenge, and that's what impaired WiMAX in many cases. What you'd rather do is use both a low band (700 or 800 MHz) for good coverage, with high bands (2.6 GHz for example) for capacity but only where it matters (to keep costs in check). The combination allows both good coverage and capacity, and will be quite common in LTE deployments. Verizon has started LTE deployments in 700 MHz, to get a good coverage quick. As subscribers increase, they will open higher bands (AWS in their case IIUC) to add capacity.
So keep an eye on the spectrum used when doing comparisons.
A handset radio subsystem is made of three parts: 1) the modem baseband, doing the digital processing, 2) the RF, pushing the signal between baseband to/from the final RF frequency and 3) the RF front-end (RFFE), doing the filtering and possibly low noise amplification in the reception direction, and power amplification (PA) in the transmit direction.
Now every time multi-bands support comes up, someone says "SDR" as the magic solution. But SDR applies to the modem baseband part only, and is actually quite common in many existing LTE devices. And it's irrelevant to this issue: the baseband, even if hardware centric, has no problem supporting any bands. Same for most recent RF chips: they're also multibands already.
The issue is the RF front-end: those filters are specific to a given bands. You want more bands? You need more filters (and possibly switches, unless the RF chips has enough separate ports) and this add cost and space on the PCB. And then there are the PAs. For now the wider the PA, the lower its efficiency (and even "wide" PA do not cover all bands, just a few 100s MHz at most). Low efficiency means higher battery consumption and higher heat (which degrades the efficiency too). There's a solution coming hopefully soon for PAs, called envelope tracking (ET). It should enable both efficient and wideband PAs. For filters, I haven't heard of any reasonably sized and cheap programmable filters with proper performance. That's the bottleneck for now. I someone can crack this nut, there's a big market to gain.
I think all mobile environment have a well defined radio interface layer (RIL) similar to what's in Android. There's something specific to Blackberry thought, it's that in 2G/3G they have their own protocol stack. It's still run on an external baseband modem chip made by others (Freescale from memory, but I may be wrong there), but the PS is BB own and not made by the modem chip vendor as is now more common. This used to be a common model when the modem was the key to a phone, as it was important to be in control and it was possible for the phone vendor to make a difference there. Now the model has changed, and the modem chip provide both the hardware and the associated protocol stack.
So maybe on LTE BB wanted to have their own stack (and even maybe modem hardware?), and didn't prioritize it as they had so much else to do and believed LTE would arrive later. When LTE took off very quickly, they got caught without an internal LTE, and possibly with a company culture that made it difficult to turn to an external provider. This is just a guess, but at least it looks possible.
The "in-house" modem development is not totally dead yet. In other big players you can find such in-house development: Moto do their own LTE hardware and stack (but for how long still?), Samsung does it too and LG did it partially in collaboration with GCT. Contrast this with Apple and HTC who just get the full modem subsystem from a third party (now Qualcomm in both cases). If you have the skills and volume it may make sense to do it yourself (Samsung), but when you have limited resources and volume this is more questionable and we'll see if this trend continue (Moto, LG).
Unfair at least for KDE, as there are different interfaces for tablets (touch based, still prototype level it seems to me), netbooks (small screen) and laptops/desktops (big screen). One of the key point of the big KDE change with version 4.X and plasma is that, as you said, a universal UI would suck. So you need different UIs optimized for each use cases. But to make this practical, you want to same foundation software underneath to minimize the changes and development costs and limit them to an as small as possible UI layer on top of a common application engine. KDE 3.X couldn't support this, while KDE 4.X is designed for this. And on the Qt side, as I understand the move to QML is also driven by this desire to support different UIs on top of a common core as easy as possible.
For some KDE applications there are alsotouch optimized and classical (mouse/keyboard) versions, although the choice for touch optimized is still much more limited (the Caligra office suite, PIM support, ?...). So the infrastructure part seems more advanced than the applications.
I'm following all this from a distance, so more expert slashdotters feel free to expand or correct me.
Only the TPM part matters actually.
Cell signaling is not relevant here, for a cellular solution you need RF and DSP functions that are just not there. And don't expect AMD to go into the cellular market, it's a specialist area they don't know about and already crowded. By the way, there's no specific acceleration on the ARM cores for cellular. The part that run on the ARM is the protocol stack and it's regular software. Neon is not even used, it's good for media but for cellular DSP processing you need much more power and use specialized DSP core(s) and dedicated hardware.
And they certainly don't need the A5 to speed up VPN support. This is better handled on a x86 core with AES-NI support.
Because there's an already existing eco-system (with 3rd party sw / solutions providers) based on ARM TrustZone technology, which is supported by the A5. So instead of reinventing the wheel, AMD just reuses all of this for cheap. Performance is a non issue there, you don't run computation intensive software, you run security control software for credentials checks and access control. The A5 is plenty enough for that.
Yes and no. They don't use the Cortex reference designs on their high and middle end application processors (AP), where they have an architecture license and derived their own implementations (Scorpion and Krait). But for low end chips and more embedded use-cases they use some reference designs (they've been using ARM11, and now Cortex A5). This is what the GP is referring too, and he's correct. You can Google the part number to check this.
Yes. It's also the smallest core in their A-line. There are 3 lines of Cortex: M for micro controllers (super small, super cheap, deeply embedded), R for real time (optimized for deterministic response time, no MMU) and A for application processors (A5, A7, A8, A9, A15 so far).
The A5 is commonly used in embedded applications too, as it's quite compact. It makes perfect sense here to leverage all the security applications developed on top of ARM TrustZone system. It's small, puny (compared to the x86 cores it will sit next to anyway, this is all relative) and cheap compared to the rest of the system. A case of not reinventing the wheel, for once.
No, but it had the "-Q" option, which is equivalent to "--no-init-file --no-site-file --no-splash". So you skip what takes most of the time.
On a few years old dual core Xeon @ 2.5 GHz, I get 60 ms like this from a fresh start (nothing cached, basic HD not SSD). By removing the "-Q" to get a more meaningful duration I was surprised to get 360 ms only on a second run. And then below 300 ms for other runs with all cached in memory. Not as fast as vi or jed for sure, but very reasonable. Of course this will depends on the complexity of the init script, but there's already some material here with most of it loaded from NFS (site init). YMMV.
I still remember how long it felt when I started working years ago and yes indeed, it took a few seconds to start emacs. Quite a change!
An A/C unit is a air/air heat pump, and from what I've seen AC is very common in Japan and in Asia in general (but I'm no expert).
There are air/air heat pumps, which move heat between inside and outside air directly and are reversible (used to heat or chill as needed). There are also air/water heat pumps, between external air and an internal water circuit. Those are only used for heating and are less common it seems to me. Where I leave there's a tax break on air/water heat pumps as they're more efficient than electric heaters and are not used for chilling, but air/air heat pumps (AC units really) have no tax break. I guess with an AC unit the temptation to use it for chilling too in summer would be too great and would negate the efficiency gained on heating vs. a basic electrical heater.