Might as well start off writing it all in assembly, since compilers don't always produce the fastest possible code.
Actually, things are advanced to the point where with very rare exception a human writing assembly is almost certainly not going to produce the optimal approach anymore. First, compliers represent the result of the best and brightest and trial and error for optimizing code structures into streams of assembly that are frequently counter-intuitively faster than a person is likely to think of on their own. Secondly, prcossor manufacturers tend to get their latest and greatest instruction sets into compilers, and trying to keep up with those dynamics would be implausible for a human writing special purpose code.
So manually writing in assembly is no longer always faster in practice and in fact usually slower. I don't think the same claim can be made of any particular managed language compared to C/C++.
Although I will agree that language choice *usually* matters far less than algorithmic choices and occasionally people jump to a language change in a project to alleviate slowness only to end up not significantly better than they started because of glaring design problems that dwarf the language performance concerns.
In that set of benchmarks, HD4000 does indeed edge out A8 in three of the tests, one by 40%, one by 25% and another by 5%. In the rest, AMD wins by 67%, 12%, 23%, and 34%.
So yes, the as-yet unavailable HD4000 based product starts making the results ambiguous compared to AMDs contemporary of the HD3000. However, AMD still comes out on top more often than not and at larger average gaps. Advance the clock when Ivy Bridge will be realistically available and the FM2 based AMD offerings will also be available, and HD4000 is likely to be significantly at a disadvantage once again.
Also consider that the HD4000 has no choice but to stand on its own. AMD has a nice path to augment the on-package GPU with a discrete GPU of matching architecture that Intel simply does not have. I was thinking about taking my Conroe system with an 8800GT and upgrading to the A10-5700 and the highest end discrete GPU that would crossfire with it (depending on benchmark results of course). I expect a modest improvement at significantly reduced power consumption with that strategy. I might change my mind later, but it's certainly an appealing option in theory.
AMD doesn't have much, but you got to give them credit for how their ATI acquisition has brought something to the table Intel has a tough time answering.
Besides, whatever plan Intel currently has for Haswell, I wouldn't be surprised if they slow down a bit. When they only face 'real' competition from themselves, they tend to get a bit more sluggish and unimpressive with their product line enhancements. Sure, they'll be hammering on Medfield sucessors to try to make inroads into the ARM dominated mobile space, but desktop and server lines don't have a lot of pressure to force them to be aggressive in product development right now.
If you are expecting to upgrade and actually wanting to *plan* on retaining a motherboard, Intel is actually a pretty poor choice. Socket AM2 (first out in 2006) can still run the latest Bulldozer based AMD processors. Meanwhile, LGA1155 was released in 2011 and is already hitting the end of the line with Ivy Bridge. Given that he waited this long to upgrade conroe (my desktop is still conroe), there is nearly zero chance that his next round of reasonable upgrade will be within the life of LGA1155 or LGA1150, though it probably will be within the life of AM3 or maybe FM2.
That said, it's not necessarily a wise idea to pin a lot of hopes on retaining the motherboard on an update. It's just another component and when someone is looking to upgrade, they'll probably also be interested in PCIe generation increases, memory speed and size (e.g. DDR2 is now a liability of AM2), and assorted other nice things that come with newer motherboards. I wouldn't keep the motherboard from my Conroe system even if the latest intel processor would work in it.
I said it was serviceable, but road warrior AD function is actually fairly awkward if you take a step away and consider it objectively. The way credentials pretty much must be cached in order to overcome the chicken and the egg problem and leads to some inconsistency between vpn connected and initial boot state in how it works. Being forced to explicitly manage a user's system indepedent of the user seems a bit weird in the case where a system is not really anything more than an extension of the owner, unlike a server or shared system where the distinction makes sense.
While some portion of what AD provides may make sense, the model as a philosophy may not endure. Basically I'm picturing something that provides the assurances/benefits you want without the awkwardness of elements of the authentication and having to manage single-user devices indpendentry of the user they are dedicated to.
As much as I'd like to imagine MS bumbling a release, I'd wager this is intentional. I also don't think of it as an 'enterprise' v. 'consumer' play. As some has pointed out, there is little reason to believe it couldn't be trivially carried over from the x86 codebase, but MS may not see it as relevant to the way a tablet would likely work, even in an enterprise scenario.
AD is built upon a strategy that was explicitly designed for fixed position systems in a corporate environment, owned by a company, logging into resources managed centrally by one coherent team, and to some extent potentially shared/interchangeable amongst employees. Back in the mid 90s when MS designed their implementation of domains, the world was a lot different. Even in the current reality of people with travelling laptops already feels very awkward, though it is serviceable. In an environment where resources spend at least as much time outside as in, where increasingly companies are getting employees to volunteer personally owned equipment instead of company issued equipment, where rarely does more than one person ever use a particular system, where people are often authenticating to multiple companies during the course of their work, and management is increasingly decentralized, active directory value significantly erodes.
It may be the case that MS recognizes the concept of a system 'joining an AD domain' as ill-fitting of the usage model. Joining a domain requires the 'system' be authenticated, to facilitate the case of the system to provide others service independent of user. This just doesn't happen with tablets and is unlikely to happen with tablets (after all, they are suspended unless a user is pretty much actively engaged and they are pretty much consume-only type devices). Maintaining the concept of the user and the user's system as independent just doesn't have practical benefit.
Of course, as a strategy this is certainly dubious. Even if it is a bad idea, MS has a lot of mindshare of companies without much vision in this regard. Those companies are a gold mine for companies like MS.
Startups these days are focused, driven, and efficient, creating products that people actually use.
Having users with no business plan to monetize that popularity isn't particularly different than having no users at all... I think the same held true in the late 90s, there was the interest and the users, but a lack of sold plans to translate that into something economically feasible.
Don't think in percentage of charge and in terms of capacity or range. 80% of 100 miles and 80% of 500 miles is likely not going to charge in the same time.
Cars certainly are keenly interested in weight as well, it's a large driver of efficiency. Also, given the ability to omit an engine and some drivetrain components means even if you still have relatively lower volumetric density that the battery might still come out ahead.
The challenge is that is 80% of a realitvely low capcity. If ayou can get 80% of a current 100 mile range vehicle in half an hour, that may amount to 16% of a 500 mile battery.
To be fair, it may represent a different business model entirely.
Gas stations mostly operate on thin margins on the gasoline itself, with the profit center being trying to get people to walk in the door to by some snacks/drink/whatever. Generally only items that can be browsed and purchase comfortably in a minute or so, since the store doesn't want a car consuming a spot more than that.
However, having vehicles that require a lot longer to charge and can be safely recharged without the operator in attendance changes the dynamics. No longer do you have businesses that are places to replenish vehicle range primarily, but you have a wider variety of businesses where they want people to sit around for a lot longer time away from their car. Some may provide metered charging as a way to augment their revenue or recover cost of the service, some even may provide it for 'free' to draw people in the door. You can already see this happening. In my area, there are shopping malls with currently free charging access. There are also restauraunts with metered chargers. A number of employers are starting to mention free charging as a perk, in part to draw people in and in part to show off how 'green' they are.
There are plenty of tools to do unattended remote deployment with or without remote server management capability (though it really is helpful for assuring things work and kicking the server should something unexpected happen during deployment). Installing an OS at the same level as a vendor preload would be takes about 30 minutes to complete of which at most seconds requires a human to pay attention, depending on solution, some require no attention beyond plugging in the server and hitting the power button once.
In my experience, it's more about the outsourcing strategy of work goes to the lowest bidder. The good teams in China/India are priced out of the market of most companies looking to outsource. The same is true in the US, but US executives I don't think have a real intuitive grasp on the cost of living implications and thus fail to recognize a too-cheap chinese bidder as too good to be true. When faced with a competitive US outsourcing bidder, they may sense something wrong and is more likely to figure out that the 'company' is some guy in a basement with maybe a cousin or something helping him.
Well, to be fair to IBM this time, I don't think retail store shared a lot of fixed costs with other parts of IBM. Now PC division and the impact on their servers was pretty significant from what I hear.
Also, at the same time, IBM is also buying companies like crazy too.
Again, this is something I find a bit silly, but the security people were worried that your MAC address was part of the address, but they are *also* concerned that traffic analyses can glean another dimension about the traffic they analyze. Traffic can be more trivially grouped by system, the numbers of systems on the other side of a gateway counted, etc etc. Of course, I've never really gotten a good idea of what non-trivial bad thing an 'attacker' could do with this data, and I've seen enough discussion that traffic analysis of similar quality is possible even with most NAT/PAT configurations to erode the argument, but stateless addressing won't sate the proponents of 'NAT for security!'
I won't argue that. But look at my needs and what I have working now. I'm doing just fine with DHCP on an IPv4 internal network.
Let's say you and I become business partners, and you need to reach my server. If you used 192.168.0.0/16 as your network and I used 192.168.0.0/16, we are kind of screwed.
Apropos of the original article... I suspect the real reason why Apple has done this is for two reasons:
Reason 3: They did a major overhaul and people are reading too much into a deferred feature release.
The only "security" NAT provides is *exactly* the same as a stateful firewall.
As much as I agree with the sentiment, I will play devil's advocate for a moment. In an ideal world they are 100% equivalent. However, I think security people may consider NAT to be more 'failsafe'. If a NAT fails to apply its capabilities correctly, you have an outage and a problem, but it failed in a way that more likely than not still doesn't let foreign traffic in. For a stateful firewall, a failure is more equally likely to cause unwanted traffic to flow. Or, if being more pessimistic, cheap home routers stop bothering to set up rules as they aren't needed and naive consumers don't care.
And I'm still not sure what so many people want to do with DHCPv6
At the very least life is a bit more straightforward/familiar. I know a lot of people are content with RA for routing and mDNS for service discovery. Sometimes people like managing the address space a little differently. Having things more predictive and centralized also opens up the opportunity for things like trust relationships with DHCP servers in a way that's a bit more manageable than analagous meausers to mDNS. Also, RA by itself doesn't lend itself well for a non-routable network (I have networks with no current 'router' I'm DHCP managing with ULA, optimistically assuming I might get connected to other islands one day and not have to fret the nightmare of private address conflicts). I will add to your point that IPv6 has another nice characteristic. If your legitimate network management tracks the LLA, even if rouge DHCPv6/RA disrupts things, you actually have a shot at remotely recovering systems through their LLA.
I think one of the biggest enemies of IPv6 adoption has been the attitudes of some of the architects behind it. You don't have to look for in various IETF mailing lists or similar places to see people making an earnest effort to adopt IPv6, but hitting roadblocks. They very specifically identify their problem and identify some behavior that could be brought forward from IPv4 to make their lives easier, and architects will rebuff them thoroughly. The most blatant example to come to mind is the refusal to put 'chaddr' from BOOTP into DHCPv6, or if it were even allowed as an option insist that it *must* not be used the way it was in BOOTP/DHCP. I'm content with client identifiers instead of interface identifiers and in fact my life is actually easier that way (well, after RFC 6355 at least). However some people have legitimate need and even among those that could change their thinking if they tried hard enough, why should they bother? The reason against chaddr seems more 'religious' than anything, which is a bad point to be stubborn on in the face of overwhelming demand.
For IPv6 to IPv4, now they've (admittedly a bit late) have endorsed NAT64 as a strategy.
The biggest challenge IPv6 faces is that a lack of urgency makes these changes slow. In IPv4, things have historically been as bad and worse as IPv6 today. Advances and changes came about more quickly as the world really had no choice. However, slowly, the same thing is happening with ipv6. As more and more take it seriously, RFCs emerge and things evolve.
Really? Because I had to renumber my home network because I happened to conflict with one of my employers non-routable networks. I had established a peer VPN with an associate, but he had to renumber his network to do it. There are numerous departments I have had to deal with, but I can't connect to all their VPNs at the same time. Why? Because half of them used 10.0.0.0/8 as 'their' network.
I don't believe, for a second, that all addresses in companies or homes need to be public addresses!
Even if you believe that, ULA in IPv6 is really quite nice. Instead of conflicting with everyone using 10.0.0.0/8 because everyone likes having a fake class A, I have a 1 in 1^40 chance of conflicting with private addresses.
I don't WANT my address to be easily and directly reachable.
Everyone knows the address of the white house. That does not mean a gunman can walk through the front door just because he knows where to find it. Firewalling rules are still viable even if you aren't NATing.
NAT as a 'security' feature is one of the worst concepts to come out of the whole mess. Just because an address is actually consistent in the wide world does not mean your home router suddenly can no longer filter incoming traffic to various embedded device.
Basically, it was a smartphone. It might've been the first if they pursued it, but then again, the Simon being first didn't buy it much in the long run: http://en.wikipedia.org/wiki/IBM_Simon
Having a smartphone on the market in the early 90s didn't really matter. Internet in early 90s didn't matter one bit to the mass market. The first browser wouldn't even exist for two more years. Until the relatively late 90s, most people didn't even bother with the internet. Without a large market demanding internet (and appropriate cellular resources to actually service that demand), there is no possibility of an 'iPhone'. This is no more an 'iPhone' than numerous smartphones that cropped up before the iPhone (and enjoyed moderate success too). What the iPhone specifically brought in its initial successful incarnation were two things. One, a web browser/interface that could reasonably render and navigate 'desktop' websites instead of being limited to crippled mobile sites that few sites bothered with at all or put something useless up. Two, the marketing momentum of their brand value from the iPod success.
using that time for doing extra work and donating the proceedings for the NASA -or even for improving the funding of the local schools- would have been more efficient.
I doubt the 30 or so seconds they probably spent praying could realistically be put to other use. I guess you could be referring to time spent in church services and, perhaps more critically, the money used to construct and maintain churches. In relation to NASA, money spent on churches is probably insignificant, but might go a non-trivial amount to helping schools or feeding and sheltering the unfortunate, though at least some churches help with the latter.
The problem now is that people in power are agreeing to reintroduce superstition as a valid alternative for science
Though I agree we must be careful, thusfar I don't see purely religion as a significant driver in government relation to science except in the teaching of evolution vs creationism. As far as NASA goes, I don't think anyone is suggesting that NASA is upsetting a higher power or in any other way 'blaspheming', but instead is doubting the return on investment. I think embryonic stem-cell research could be counted, but I think more than the religous are concerned over the ethics of that. Abstinence-only sex education is probably another area that is pretty tightly correlated with religion, though I don't think the prudishness that drives that is absolutely correlated to religion either.
Tmux's biggest claim is one of idealogy (BSD vs GPL) rather than any real technical merit.
Actually, tmux defaults at least are nice. When I 'tmux a' to share a session with someone else, our multi-window view is synced. Fit-to-terminal is a bit more sane too.
Screen developer/advocates really need to provide a guide on how to make screen behave like tmux default, if possible. Ctrl-A default bind is annoying as anything too.
Bad analogy. PS3 isn't more powerful, cheaper, more efficient or really much of anything good compared to a low-end PC architecture system that would run circles around 'OtherOS' within the confines Sony permitted. Sony's dick move of GPU lockdown from launch made OtherOS impractical even before their dick move of disabling it entirely. It's still a dick move, but people relying upon OtherOS were already pre-boned and would have been much better served by giving up on OtherOS and doing a cheap PC instead with or without Sony keeping OtherOS around.
Slashdot Mirror
Might as well start off writing it all in assembly, since compilers don't always produce the fastest possible code.
Actually, things are advanced to the point where with very rare exception a human writing assembly is almost certainly not going to produce the optimal approach anymore. First, compliers represent the result of the best and brightest and trial and error for optimizing code structures into streams of assembly that are frequently counter-intuitively faster than a person is likely to think of on their own. Secondly, prcossor manufacturers tend to get their latest and greatest instruction sets into compilers, and trying to keep up with those dynamics would be implausible for a human writing special purpose code.
So manually writing in assembly is no longer always faster in practice and in fact usually slower. I don't think the same claim can be made of any particular managed language compared to C/C++.
Although I will agree that language choice *usually* matters far less than algorithmic choices and occasionally people jump to a language change in a project to alleviate slowness only to end up not significantly better than they started because of glaring design problems that dwarf the language performance concerns.
In that set of benchmarks, HD4000 does indeed edge out A8 in three of the tests, one by 40%, one by 25% and another by 5%. In the rest, AMD wins by 67%, 12%, 23%, and 34%.
So yes, the as-yet unavailable HD4000 based product starts making the results ambiguous compared to AMDs contemporary of the HD3000. However, AMD still comes out on top more often than not and at larger average gaps. Advance the clock when Ivy Bridge will be realistically available and the FM2 based AMD offerings will also be available, and HD4000 is likely to be significantly at a disadvantage once again.
Also consider that the HD4000 has no choice but to stand on its own. AMD has a nice path to augment the on-package GPU with a discrete GPU of matching architecture that Intel simply does not have. I was thinking about taking my Conroe system with an 8800GT and upgrading to the A10-5700 and the highest end discrete GPU that would crossfire with it (depending on benchmark results of course). I expect a modest improvement at significantly reduced power consumption with that strategy. I might change my mind later, but it's certainly an appealing option in theory.
AMD doesn't have much, but you got to give them credit for how their ATI acquisition has brought something to the table Intel has a tough time answering.
Besides, whatever plan Intel currently has for Haswell, I wouldn't be surprised if they slow down a bit. When they only face 'real' competition from themselves, they tend to get a bit more sluggish and unimpressive with their product line enhancements. Sure, they'll be hammering on Medfield sucessors to try to make inroads into the ARM dominated mobile space, but desktop and server lines don't have a lot of pressure to force them to be aggressive in product development right now.
If you are expecting to upgrade and actually wanting to *plan* on retaining a motherboard, Intel is actually a pretty poor choice. Socket AM2 (first out in 2006) can still run the latest Bulldozer based AMD processors. Meanwhile, LGA1155 was released in 2011 and is already hitting the end of the line with Ivy Bridge. Given that he waited this long to upgrade conroe (my desktop is still conroe), there is nearly zero chance that his next round of reasonable upgrade will be within the life of LGA1155 or LGA1150, though it probably will be within the life of AM3 or maybe FM2.
That said, it's not necessarily a wise idea to pin a lot of hopes on retaining the motherboard on an update. It's just another component and when someone is looking to upgrade, they'll probably also be interested in PCIe generation increases, memory speed and size (e.g. DDR2 is now a liability of AM2), and assorted other nice things that come with newer motherboards. I wouldn't keep the motherboard from my Conroe system even if the latest intel processor would work in it.
I said it was serviceable, but road warrior AD function is actually fairly awkward if you take a step away and consider it objectively. The way credentials pretty much must be cached in order to overcome the chicken and the egg problem and leads to some inconsistency between vpn connected and initial boot state in how it works. Being forced to explicitly manage a user's system indepedent of the user seems a bit weird in the case where a system is not really anything more than an extension of the owner, unlike a server or shared system where the distinction makes sense.
While some portion of what AD provides may make sense, the model as a philosophy may not endure. Basically I'm picturing something that provides the assurances/benefits you want without the awkwardness of elements of the authentication and having to manage single-user devices indpendentry of the user they are dedicated to.
As much as I'd like to imagine MS bumbling a release, I'd wager this is intentional. I also don't think of it as an 'enterprise' v. 'consumer' play. As some has pointed out, there is little reason to believe it couldn't be trivially carried over from the x86 codebase, but MS may not see it as relevant to the way a tablet would likely work, even in an enterprise scenario.
AD is built upon a strategy that was explicitly designed for fixed position systems in a corporate environment, owned by a company, logging into resources managed centrally by one coherent team, and to some extent potentially shared/interchangeable amongst employees. Back in the mid 90s when MS designed their implementation of domains, the world was a lot different. Even in the current reality of people with travelling laptops already feels very awkward, though it is serviceable. In an environment where resources spend at least as much time outside as in, where increasingly companies are getting employees to volunteer personally owned equipment instead of company issued equipment, where rarely does more than one person ever use a particular system, where people are often authenticating to multiple companies during the course of their work, and management is increasingly decentralized, active directory value significantly erodes.
It may be the case that MS recognizes the concept of a system 'joining an AD domain' as ill-fitting of the usage model. Joining a domain requires the 'system' be authenticated, to facilitate the case of the system to provide others service independent of user. This just doesn't happen with tablets and is unlikely to happen with tablets (after all, they are suspended unless a user is pretty much actively engaged and they are pretty much consume-only type devices). Maintaining the concept of the user and the user's system as independent just doesn't have practical benefit.
Of course, as a strategy this is certainly dubious. Even if it is a bad idea, MS has a lot of mindshare of companies without much vision in this regard. Those companies are a gold mine for companies like MS.
Startups these days are focused, driven, and efficient, creating products that people actually use.
Having users with no business plan to monetize that popularity isn't particularly different than having no users at all... I think the same held true in the late 90s, there was the interest and the users, but a lack of sold plans to translate that into something economically feasible.
Don't think in percentage of charge and in terms of capacity or range. 80% of 100 miles and 80% of 500 miles is likely not going to charge in the same time.
Cars certainly are keenly interested in weight as well, it's a large driver of efficiency. Also, given the ability to omit an engine and some drivetrain components means even if you still have relatively lower volumetric density that the battery might still come out ahead.
The challenge is that is 80% of a realitvely low capcity. If ayou can get 80% of a current 100 mile range vehicle in half an hour, that may amount to 16% of a 500 mile battery.
To be fair, it may represent a different business model entirely.
Gas stations mostly operate on thin margins on the gasoline itself, with the profit center being trying to get people to walk in the door to by some snacks/drink/whatever. Generally only items that can be browsed and purchase comfortably in a minute or so, since the store doesn't want a car consuming a spot more than that.
However, having vehicles that require a lot longer to charge and can be safely recharged without the operator in attendance changes the dynamics. No longer do you have businesses that are places to replenish vehicle range primarily, but you have a wider variety of businesses where they want people to sit around for a lot longer time away from their car. Some may provide metered charging as a way to augment their revenue or recover cost of the service, some even may provide it for 'free' to draw people in the door. You can already see this happening. In my area, there are shopping malls with currently free charging access. There are also restauraunts with metered chargers. A number of employers are starting to mention free charging as a perk, in part to draw people in and in part to show off how 'green' they are.
I don't think IBM does yet. IBM is a partner of Canonical, but IBM the software company and not so much IBM the server company as far as I've heard.
There are plenty of tools to do unattended remote deployment with or without remote server management capability (though it really is helpful for assuring things work and kicking the server should something unexpected happen during deployment). Installing an OS at the same level as a vendor preload would be takes about 30 minutes to complete of which at most seconds requires a human to pay attention, depending on solution, some require no attention beyond plugging in the server and hitting the power button once.
In my experience, it's more about the outsourcing strategy of work goes to the lowest bidder. The good teams in China/India are priced out of the market of most companies looking to outsource. The same is true in the US, but US executives I don't think have a real intuitive grasp on the cost of living implications and thus fail to recognize a too-cheap chinese bidder as too good to be true. When faced with a competitive US outsourcing bidder, they may sense something wrong and is more likely to figure out that the 'company' is some guy in a basement with maybe a cousin or something helping him.
Well, to be fair to IBM this time, I don't think retail store shared a lot of fixed costs with other parts of IBM. Now PC division and the impact on their servers was pretty significant from what I hear.
Also, at the same time, IBM is also buying companies like crazy too.
Again, this is something I find a bit silly, but the security people were worried that your MAC address was part of the address, but they are *also* concerned that traffic analyses can glean another dimension about the traffic they analyze. Traffic can be more trivially grouped by system, the numbers of systems on the other side of a gateway counted, etc etc. Of course, I've never really gotten a good idea of what non-trivial bad thing an 'attacker' could do with this data, and I've seen enough discussion that traffic analysis of similar quality is possible even with most NAT/PAT configurations to erode the argument, but stateless addressing won't sate the proponents of 'NAT for security!'
I won't argue that. But look at my needs and what I have working now. I'm doing just fine with DHCP on an IPv4 internal network.
Let's say you and I become business partners, and you need to reach my server. If you used 192.168.0.0/16 as your network and I used 192.168.0.0/16, we are kind of screwed.
Apropos of the original article ... I suspect the real reason why Apple has done this is for two reasons:
Reason 3: They did a major overhaul and people are reading too much into a deferred feature release.
The only "security" NAT provides is *exactly* the same as a stateful firewall.
As much as I agree with the sentiment, I will play devil's advocate for a moment. In an ideal world they are 100% equivalent. However, I think security people may consider NAT to be more 'failsafe'. If a NAT fails to apply its capabilities correctly, you have an outage and a problem, but it failed in a way that more likely than not still doesn't let foreign traffic in. For a stateful firewall, a failure is more equally likely to cause unwanted traffic to flow. Or, if being more pessimistic, cheap home routers stop bothering to set up rules as they aren't needed and naive consumers don't care.
And I'm still not sure what so many people want to do with DHCPv6
At the very least life is a bit more straightforward/familiar. I know a lot of people are content with RA for routing and mDNS for service discovery. Sometimes people like managing the address space a little differently. Having things more predictive and centralized also opens up the opportunity for things like trust relationships with DHCP servers in a way that's a bit more manageable than analagous meausers to mDNS. Also, RA by itself doesn't lend itself well for a non-routable network (I have networks with no current 'router' I'm DHCP managing with ULA, optimistically assuming I might get connected to other islands one day and not have to fret the nightmare of private address conflicts). I will add to your point that IPv6 has another nice characteristic. If your legitimate network management tracks the LLA, even if rouge DHCPv6/RA disrupts things, you actually have a shot at remotely recovering systems through their LLA.
I think one of the biggest enemies of IPv6 adoption has been the attitudes of some of the architects behind it. You don't have to look for in various IETF mailing lists or similar places to see people making an earnest effort to adopt IPv6, but hitting roadblocks. They very specifically identify their problem and identify some behavior that could be brought forward from IPv4 to make their lives easier, and architects will rebuff them thoroughly. The most blatant example to come to mind is the refusal to put 'chaddr' from BOOTP into DHCPv6, or if it were even allowed as an option insist that it *must* not be used the way it was in BOOTP/DHCP. I'm content with client identifiers instead of interface identifiers and in fact my life is actually easier that way (well, after RFC 6355 at least). However some people have legitimate need and even among those that could change their thinking if they tried hard enough, why should they bother? The reason against chaddr seems more 'religious' than anything, which is a bad point to be stubborn on in the face of overwhelming demand.
For IPv6 to IPv4, now they've (admittedly a bit late) have endorsed NAT64 as a strategy.
The biggest challenge IPv6 faces is that a lack of urgency makes these changes slow. In IPv4, things have historically been as bad and worse as IPv6 today. Advances and changes came about more quickly as the world really had no choice. However, slowly, the same thing is happening with ipv6. As more and more take it seriously, RFCs emerge and things evolve.
existing solutions work just fine with ipv4.
Really? Because I had to renumber my home network because I happened to conflict with one of my employers non-routable networks. I had established a peer VPN with an associate, but he had to renumber his network to do it. There are numerous departments I have had to deal with, but I can't connect to all their VPNs at the same time. Why? Because half of them used 10.0.0.0/8 as 'their' network.
I don't believe, for a second, that all addresses in companies or homes need to be public addresses!
Even if you believe that, ULA in IPv6 is really quite nice. Instead of conflicting with everyone using 10.0.0.0/8 because everyone likes having a fake class A, I have a 1 in 1^40 chance of conflicting with private addresses.
I don't WANT my address to be easily and directly reachable.
Everyone knows the address of the white house. That does not mean a gunman can walk through the front door just because he knows where to find it. Firewalling rules are still viable even if you aren't NATing.
NAT as a 'security' feature is one of the worst concepts to come out of the whole mess. Just because an address is actually consistent in the wide world does not mean your home router suddenly can no longer filter incoming traffic to various embedded device.
Basically, it was a smartphone. It might've been the first if they pursued it, but then again, the Simon being first didn't buy it much in the long run:
http://en.wikipedia.org/wiki/IBM_Simon
Having a smartphone on the market in the early 90s didn't really matter. Internet in early 90s didn't matter one bit to the mass market. The first browser wouldn't even exist for two more years. Until the relatively late 90s, most people didn't even bother with the internet. Without a large market demanding internet (and appropriate cellular resources to actually service that demand), there is no possibility of an 'iPhone'. This is no more an 'iPhone' than numerous smartphones that cropped up before the iPhone (and enjoyed moderate success too). What the iPhone specifically brought in its initial successful incarnation were two things. One, a web browser/interface that could reasonably render and navigate 'desktop' websites instead of being limited to crippled mobile sites that few sites bothered with at all or put something useless up. Two, the marketing momentum of their brand value from the iPod success.
using that time for doing extra work and donating the proceedings for the NASA -or even for improving the funding of the local schools- would have been more efficient.
I doubt the 30 or so seconds they probably spent praying could realistically be put to other use. I guess you could be referring to time spent in church services and, perhaps more critically, the money used to construct and maintain churches. In relation to NASA, money spent on churches is probably insignificant, but might go a non-trivial amount to helping schools or feeding and sheltering the unfortunate, though at least some churches help with the latter.
The problem now is that people in power are agreeing to reintroduce superstition as a valid alternative for science
Though I agree we must be careful, thusfar I don't see purely religion as a significant driver in government relation to science except in the teaching of evolution vs creationism. As far as NASA goes, I don't think anyone is suggesting that NASA is upsetting a higher power or in any other way 'blaspheming', but instead is doubting the return on investment. I think embryonic stem-cell research could be counted, but I think more than the religous are concerned over the ethics of that. Abstinence-only sex education is probably another area that is pretty tightly correlated with religion, though I don't think the prudishness that drives that is absolutely correlated to religion either.
Tmux's biggest claim is one of idealogy (BSD vs GPL) rather than any real technical merit.
Actually, tmux defaults at least are nice. When I 'tmux a' to share a session with someone else, our multi-window view is synced. Fit-to-terminal is a bit more sane too.
Screen developer/advocates really need to provide a guide on how to make screen behave like tmux default, if possible. Ctrl-A default bind is annoying as anything too.
Bad analogy. PS3 isn't more powerful, cheaper, more efficient or really much of anything good compared to a low-end PC architecture system that would run circles around 'OtherOS' within the confines Sony permitted. Sony's dick move of GPU lockdown from launch made OtherOS impractical even before their dick move of disabling it entirely. It's still a dick move, but people relying upon OtherOS were already pre-boned and would have been much better served by giving up on OtherOS and doing a cheap PC instead with or without Sony keeping OtherOS around.