But PUE isn't that a good thing there either. It speaks to some overhead, but does not speak to how that power is sourced or how efficient it is put to use. A horribly inefficient processor that sucks down power can have really good PUE through a complex cooling system and in a region powered by coal, even if you can do the same work with a tenth of the power, but that part is not available in a design without a fan, and installed in a place where solar power provides a good chunk of the power. The more sustainable answer in that made hypothetical would be the fan cooled efficient processor getting a lot from solar, but PUE does not care about that.
That aside, just don't screw with things. You mention caps lock, which I don't use, but any change is likely to just screw with muscle memory and not have any practical benefit except as some symbolic gesture against caps lock. For example, see second gen X1 carbon which replaced caps lock with home and end keys.
There is also the troubling by the way mention of the right mouse button. For the love of god do not advocate screwing with the right mouse button. You don't often need it, but when you do, all the schemes that try to de-emphasize it's footprint really screw with you and again *nothing of value is gained*.
The more troubling question is why an application should feel forced to do anything in the face of a platform upgrade in order to work at all. A modern Windows desktop can still run 10 year old software without a hiccup. Going back 20 years you start needing something like dosbox to use a lot of the applications, though still doable. I haven't tried firing it up in a while, but last time I tried the commercial package of quake 3 under linux, it still worked on a modern distribution. Same for linux neverwinter nights. As an application maintainer for some linux stuff, the only things that I can recall forcing my hand to change something for things to work were systemd and python changes.
Android (and to a significant, but somewhat lesser extent Apple) are not doing that good with respect to application and/or hardware compatibility into the past. It's a tiring situation for developers to have to follow an upgrade treadmill in order to cater to new system sales, just to keep the current applications workable as-is.
1. I suggest looking at Xpra. It's married to X, but is far better than X or NX at seamless remote applications. It's also an example of exactly the sort of remote experience that *could* be done within a Wayland context. The problem obviously being I had to point out something married to X as an example, rather than knowing off hand something that pulls off the same in Wayland, but the concepts are pretty sound.
I suggest looking at xpra. X and even NX I didn't have a lot of fun with, but Xpra has treated me well. The kicker is that the Xpra strategy concept translates to an architecture like Wayland (it captures applications via compositor interface and contextual data through window manager calls).
I have to side with those that say X's inherent network protocols are less interesting. The unfortunate fact is that everyone then cites things like SPICE and typical RDP configurations and VNC, rather than something that achieves the same seamless behavior that the fans of X want.
Spice is pretty crappy (after really wanting to like it for a while). I hear rumor that RDP can be decent, but thus far I've not seen examples of it doing remote application access in a seamless way.
My personal example of how seamless remote applications can work well is Xpra. Despite it's current marriage to X, the strategy used does not use the 'remote' capabilities of X and the concept translates directly to something like Wayland. It intercepts things at the compositor layer rather than remote X calls.
I find this interesting. I know of people who strangely put a lot of their 401Ks into the stock of the company they work for, but mostly in my experience 401k investments aren't particularly tied to the company of employment. At least I make sure my investments are not particularly tied to any one company.
Are there any rendering mistakes or quality differences? Are there any issues with stability? Frame rate is not the only metric, it's just the only metric anyone can simply publish.
Intel has had a process lead, but that's not the only reason they make abnormal margins.
- Lock in. AMD's the only viable x86 vendor and they've been off in the weeds after their glory days that culminated in x86-64 and NUMA x86 architecture -Ecosystem. Intel invests heavily in things like compilers and standard libraries and so forth. They pay to have good software developers enrich an ecosystem that favors their processors -Microarchitecture. They frankly have very good hardware engineers.
ARM came to prevail because Intel took their eye off the ball in the low power space. Recent Atom family designs have made a strong showing in that space (in part due to software developers creating remarkable ARM emulation, in part due to excellent hardware design, and in part due to the business call to compete at more typical (for the market) margin). The 'ARMs sip power' reality was (unreasonably) extrapolated to "they'd kick ass in the datacenter", but now studies are being done and the ARM server designs are losing both on raw performance and performance per watt to the Intel offering (e.g. one done by CERN did open power 8 v. aarch64 v. two x86 variants (atom and xeon e3) and the x86 variants won most everything (except POWER did SMT better than most, but even that fell apart most of the time).
has the sheer volume of cancer risen in the United States in the last 20 years?
Also as people who are dying from other stuff decreases over time, cancer gets a crack at people who were otherwise knocked out by something else first.
While this looks like a perfectly reasonable language, I'm a bit weary of this sort of bragging about line counts. I could do the same thing, it would look roughly like: ssh pi2.local 'while:; do pitemp=`ssh pi.local get_temp`; mytemp=`get_temp`; if [ abs($((mytemp - pitemp)) -gt 2 ]; then echo "Temperature on pi is $mytemp and on pi2 $mytemp. "' (abs and get_temp are up to the person to have the functions).
Talk about the syntax being nicer, but lines of code is no big deal in this particular case. It has a nice and non-ugly 'run this on another host' syntax and automatically takes care of the communication channels in a reasonable fashion with a low amount of fuss. Leave it at that.
Also, the trap is that any term that gets adopted will *become* yet another idiotic marketing term.
Any phrase attracting buzz is doomed to become a meaningless marketing term abused by companies with their agendas to be relevant.
I particularly dislike the phrase 'internet of things', but I know I'll dislike any term that sees common adoption while the media/marketers have an interest in the field until that interest dies down and it no longer becomes fashionable for companies to shoehorn it into their message.
For contrast, I had a minimum mortgage payment of 850/month on a 3,000 square foot house, had enough extra to pay it all off in 8 years. It's a fair point that $66k/yr in most areas easily beats $100k/year in SV. That's one thing if you really *want* to live in Silicon Valley, but if you move there because of a better job opportunity and didn't particularly care about being in SV specifically, you are probably making the wrong move.
Basically, I've encountered two classes of H1-Bs: -Folks who are exceedingly good at what they do and are sought out by name. They are by no means cheaper, but a company has to do H1-B to get them.
-Folks who are cheaper and held hostage to their circumstances.
I think across the industry the latter is at least somewhat more common (it's the simplest explanation for the high volume of H1-B requests from specific companies, it's unlikely one company would need the former case by the hundreds). However this situation results in some reactions that are highly offensive to those in the first category.
After reading through the paper a bit, it seems interesting, but perhaps a bit overblown. It seemed to have a lot of work to understand the very specific problem domain before this could be applied. It's more like a methodology *enabled* expert engineers to do optimization, not that it did optimization *instead of* expert engineers.
It's also a field with a lot of solid technical high level algorithms, so there was a pretty good space to map things to. Basically it was identifying what inscrutable code was doing as it relates to well known algorithms, enabling them to start fresh to apply the best practice today of said algorithm. If you are not in this sort of space, the strategy doesn't really have a way to help very much.
Incidentally, it's (probably) not in this case that the code was sub-optimal, just mis-optimized. Whether it's something like code written before AVX2 existed, now adding AVX2 codepath, or scenarios with two algorithms that end the same way that use different operations where a choice was made based on chips that could do one of those faster, and newer chips started getting faster the other way.
If there is a substantial removal, it's hard to imagine that there *wouldn't* be roads that provide direct access to homes, or sole access to some homes in the middle. If a road *can* have a house or business built along it, a house or business will likely end up connected to it. Freeways are the only sorts of roads that wouldn't suffer this phenomenon, but even then there are likely to be roads that are only connected to the larger road network by way of the freeway.
Most current smartphones use processors containing 14nm technology
Only a few use 14nm today. It's still relatively scarce.
Also, a company that no longer had a fab did a proof of concept in a lab. This is not what the headline suggests. It's nice to know that we have a proven hypothetical to get down to 7, but the practical side of things has a tenuous relation to research.
There are still a lot of use cases for solid on-premises OS deployments on physical, local machines. They're not mainstream anymore
I think you can be more strong on this point. The reality is that this *is* the mainstream. 'The Cloud' work is important, but more than important, the people doing it are *louder* than everyone else and the media coverage high since it is novel, but mainstream is remarkably little changed over the last several years.
RTM did mean that all the showstopper bugs were taken care of, and the concept of "ship it, we'll patch it later" just didn't work. All I do know is this -- Microsoft is toast if Grandma can't upgrade her Windows 7 box she bought at Best Buy with zero issues.
That is the facet I find concerning, 'RTM is no big deal' statement is bad because it *should* be a big deal.
Maybe they can juggle LTS and non-LTS effectively, but they have every risk of getting too caught up in the enthusiast perspective and pissing off a lot of their users. I know a fair number of people pissed that their google apps change drastically on a whim on their phones, and it seems MS may jump to that model. That said, the pissed off users don't really have anywhere to go. The developers rule the roost nowadays and all companies are enabling new and shiny and changing and no one is being pushed to drive for a stable experience.
It would be bad form to reset the password when anyone clicked 'reset this accounts password' anyway. So until the link is followed, no action should be taken with regard to the account password anyway. This way a malicious person can't just denial of service a valid account by clicking 'reset my password'.
This means if an attacker is able to intercept your SMTP, they could still hijack your account through requesting a password reset at will, so it's not perfect, and yes some 2 factor authentication would be nice *if* it were an important site. Account creation needn't have this particular hole, just password reset.
If you didn't want to SMS, you could use TOTP (e.g. google authenticator is one implementation, but not the only one). Though either way that's something to potentially lose so it would be a suggestion option for those increasing security.
Slashdot Mirror
But PUE isn't that a good thing there either. It speaks to some overhead, but does not speak to how that power is sourced or how efficient it is put to use. A horribly inefficient processor that sucks down power can have really good PUE through a complex cooling system and in a region powered by coal, even if you can do the same work with a tenth of the power, but that part is not available in a design without a fan, and installed in a place where solar power provides a good chunk of the power. The more sustainable answer in that made hypothetical would be the fan cooled efficient processor getting a lot from solar, but PUE does not care about that.
Of course, the biggest monster jump didn't make it in:
http://wccftech.com/mainstream...
So there might not be very dramatic bumps to be had even with updated libraries/compilers/etc.
farmed algae is inhumane. Constrained to live in limited vats I eat only free range algae. They get to exercise you see.
http://bash.org/?835030
That aside, just don't screw with things. You mention caps lock, which I don't use, but any change is likely to just screw with muscle memory and not have any practical benefit except as some symbolic gesture against caps lock. For example, see second gen X1 carbon which replaced caps lock with home and end keys.
There is also the troubling by the way mention of the right mouse button. For the love of god do not advocate screwing with the right mouse button. You don't often need it, but when you do, all the schemes that try to de-emphasize it's footprint really screw with you and again *nothing of value is gained*.
The problem being they didn't do the same to ARM. Either that argument applies to both sides or neither. They need to be held to same standard.
The more troubling question is why an application should feel forced to do anything in the face of a platform upgrade in order to work at all. A modern Windows desktop can still run 10 year old software without a hiccup. Going back 20 years you start needing something like dosbox to use a lot of the applications, though still doable. I haven't tried firing it up in a while, but last time I tried the commercial package of quake 3 under linux, it still worked on a modern distribution. Same for linux neverwinter nights. As an application maintainer for some linux stuff, the only things that I can recall forcing my hand to change something for things to work were systemd and python changes.
Android (and to a significant, but somewhat lesser extent Apple) are not doing that good with respect to application and/or hardware compatibility into the past. It's a tiring situation for developers to have to follow an upgrade treadmill in order to cater to new system sales, just to keep the current applications workable as-is.
It is about the *seamless* version, not the full remote desktop version.
1. I suggest looking at Xpra. It's married to X, but is far better than X or NX at seamless remote applications. It's also an example of exactly the sort of remote experience that *could* be done within a Wayland context. The problem obviously being I had to point out something married to X as an example, rather than knowing off hand something that pulls off the same in Wayland, but the concepts are pretty sound.
I suggest looking at xpra. X and even NX I didn't have a lot of fun with, but Xpra has treated me well. The kicker is that the Xpra strategy concept translates to an architecture like Wayland (it captures applications via compositor interface and contextual data through window manager calls).
I have to side with those that say X's inherent network protocols are less interesting. The unfortunate fact is that everyone then cites things like SPICE and typical RDP configurations and VNC, rather than something that achieves the same seamless behavior that the fans of X want.
Spice is pretty crappy (after really wanting to like it for a while). I hear rumor that RDP can be decent, but thus far I've not seen examples of it doing remote application access in a seamless way.
My personal example of how seamless remote applications can work well is Xpra. Despite it's current marriage to X, the strategy used does not use the 'remote' capabilities of X and the concept translates directly to something like Wayland. It intercepts things at the compositor layer rather than remote X calls.
everyone lost their 401Ks
I find this interesting. I know of people who strangely put a lot of their 401Ks into the stock of the company they work for, but mostly in my experience 401k investments aren't particularly tied to the company of employment. At least I make sure my investments are not particularly tied to any one company.
Are there any rendering mistakes or quality differences? Are there any issues with stability? Frame rate is not the only metric, it's just the only metric anyone can simply publish.
Intel has had a process lead, but that's not the only reason they make abnormal margins.
- Lock in. AMD's the only viable x86 vendor and they've been off in the weeds after their glory days that culminated in x86-64 and NUMA x86 architecture
-Ecosystem. Intel invests heavily in things like compilers and standard libraries and so forth. They pay to have good software developers enrich an ecosystem that favors their processors
-Microarchitecture. They frankly have very good hardware engineers.
ARM came to prevail because Intel took their eye off the ball in the low power space. Recent Atom family designs have made a strong showing in that space (in part due to software developers creating remarkable ARM emulation, in part due to excellent hardware design, and in part due to the business call to compete at more typical (for the market) margin). The 'ARMs sip power' reality was (unreasonably) extrapolated to "they'd kick ass in the datacenter", but now studies are being done and the ARM server designs are losing both on raw performance and performance per watt to the Intel offering (e.g. one done by CERN did open power 8 v. aarch64 v. two x86 variants (atom and xeon e3) and the x86 variants won most everything (except POWER did SMT better than most, but even that fell apart most of the time).
has the sheer volume of cancer risen in the United States in the last 20 years?
Also as people who are dying from other stuff decreases over time, cancer gets a crack at people who were otherwise knocked out by something else first.
While this looks like a perfectly reasonable language, I'm a bit weary of this sort of bragging about line counts. I could do the same thing, it would look roughly like: :; do pitemp=`ssh pi.local get_temp`; mytemp=`get_temp`; if [ abs($((mytemp - pitemp)) -gt 2 ]; then echo "Temperature on pi is $mytemp and on pi2 $mytemp. "'
ssh pi2.local 'while
(abs and get_temp are up to the person to have the functions).
Talk about the syntax being nicer, but lines of code is no big deal in this particular case. It has a nice and non-ugly 'run this on another host' syntax and automatically takes care of the communication channels in a reasonable fashion with a low amount of fuss. Leave it at that.
Also, the trap is that any term that gets adopted will *become* yet another idiotic marketing term.
Any phrase attracting buzz is doomed to become a meaningless marketing term abused by companies with their agendas to be relevant.
I particularly dislike the phrase 'internet of things', but I know I'll dislike any term that sees common adoption while the media/marketers have an interest in the field until that interest dies down and it no longer becomes fashionable for companies to shoehorn it into their message.
For contrast, I had a minimum mortgage payment of 850/month on a 3,000 square foot house, had enough extra to pay it all off in 8 years. It's a fair point that $66k/yr in most areas easily beats $100k/year in SV. That's one thing if you really *want* to live in Silicon Valley, but if you move there because of a better job opportunity and didn't particularly care about being in SV specifically, you are probably making the wrong move.
Basically, I've encountered two classes of H1-Bs:
-Folks who are exceedingly good at what they do and are sought out by name. They are by no means cheaper, but a company has to do H1-B to get them.
-Folks who are cheaper and held hostage to their circumstances.
I think across the industry the latter is at least somewhat more common (it's the simplest explanation for the high volume of H1-B requests from specific companies, it's unlikely one company would need the former case by the hundreds). However this situation results in some reactions that are highly offensive to those in the first category.
I was $55k right out of college 13 years ago. Those were, frankly, the easy jobs to get too.
After reading through the paper a bit, it seems interesting, but perhaps a bit overblown. It seemed to have a lot of work to understand the very specific problem domain before this could be applied. It's more like a methodology *enabled* expert engineers to do optimization, not that it did optimization *instead of* expert engineers.
It's also a field with a lot of solid technical high level algorithms, so there was a pretty good space to map things to. Basically it was identifying what inscrutable code was doing as it relates to well known algorithms, enabling them to start fresh to apply the best practice today of said algorithm. If you are not in this sort of space, the strategy doesn't really have a way to help very much.
Incidentally, it's (probably) not in this case that the code was sub-optimal, just mis-optimized. Whether it's something like code written before AVX2 existed, now adding AVX2 codepath, or scenarios with two algorithms that end the same way that use different operations where a choice was made based on chips that could do one of those faster, and newer chips started getting faster the other way.
If there is a substantial removal, it's hard to imagine that there *wouldn't* be roads that provide direct access to homes, or sole access to some homes in the middle. If a road *can* have a house or business built along it, a house or business will likely end up connected to it. Freeways are the only sorts of roads that wouldn't suffer this phenomenon, but even then there are likely to be roads that are only connected to the larger road network by way of the freeway.
Most current smartphones use processors containing 14nm technology
Only a few use 14nm today. It's still relatively scarce.
Also, a company that no longer had a fab did a proof of concept in a lab. This is not what the headline suggests. It's nice to know that we have a proven hypothetical to get down to 7, but the practical side of things has a tenuous relation to research.
There are still a lot of use cases for solid on-premises OS deployments on physical, local machines. They're not mainstream anymore
I think you can be more strong on this point. The reality is that this *is* the mainstream. 'The Cloud' work is important, but more than important, the people doing it are *louder* than everyone else and the media coverage high since it is novel, but mainstream is remarkably little changed over the last several years.
RTM did mean that all the showstopper bugs were taken care of, and the concept of "ship it, we'll patch it later" just didn't work. All I do know is this -- Microsoft is toast if Grandma can't upgrade her Windows 7 box she bought at Best Buy with zero issues.
That is the facet I find concerning, 'RTM is no big deal' statement is bad because it *should* be a big deal.
Maybe they can juggle LTS and non-LTS effectively, but they have every risk of getting too caught up in the enthusiast perspective and pissing off a lot of their users. I know a fair number of people pissed that their google apps change drastically on a whim on their phones, and it seems MS may jump to that model. That said, the pissed off users don't really have anywhere to go. The developers rule the roost nowadays and all companies are enabling new and shiny and changing and no one is being pushed to drive for a stable experience.
It would be bad form to reset the password when anyone clicked 'reset this accounts password' anyway. So until the link is followed, no action should be taken with regard to the account password anyway. This way a malicious person can't just denial of service a valid account by clicking 'reset my password'.
This means if an attacker is able to intercept your SMTP, they could still hijack your account through requesting a password reset at will, so it's not perfect, and yes some 2 factor authentication would be nice *if* it were an important site. Account creation needn't have this particular hole, just password reset.
If you didn't want to SMS, you could use TOTP (e.g. google authenticator is one implementation, but not the only one). Though either way that's something to potentially lose so it would be a suggestion option for those increasing security.