I suggest office depot/officemax. At least in my neck of the woods they carried some of the higher end laptops that best buy didn't bother with. Also the obvious suggestion of an Apple store. MS store might work, but there isn't one within 250 miles of me so I wouldn't know.
I think it is *key* to try to find a way to actually physically evaluate whatever you narrow it down to. For mobile computing, form factor, weight, balance, rigidity, and other factors are best assessed first-hand.
A tad redundant. Tons of comments saying pretty much the exact same words without additional insight gets a tad old. Besides, unless submitter lives under a rock, they certainly already know about those offerings as Apple is *very* aggressive and savvy about their marketing. Many of the other options do not acheive the same awareness as Apple.
For me, without a pointer device on the home row, it's a non-starter. Therefore mac is off the table, even if it weren't 15-20% more expenisve than comparable quality Lenovo/HP laptops. Before you say the Macs are higher quality, they aren't. They are significantly better build quality than the Lenovo/HP products that are half the price of the Macbooks with comparable specs, but I'm talking about the higher end competitor model lines. The only thing you get is OSX, which actually isn't particularly anything special. Users unsatisfied with Windows in terms of UI flexibility or general architecture would probably be best served by Linux. Those unsatisfied with relative lack of commercial software in Linux would be best served by Windows.
Notably you should try to find a way to actually touch and hold your choice. Particularly your relative may not realize what a 17" laptop would mean for portability.
After having a few laptops ranging from 12 to 17 inches over time, I've found 14" to be what I feel to be a good compromise. 1600x900 display at least. When reasonable, I use an external 22" monitor at 1920x1200, but I wouldn't want to drag aronud the requisite bulk and weight of a 17" laptop again...
If you want to write modern Windows applications, you don't really have much choice. You can target Java, but requiring a third-party runtime like that is pretty inelegant. MiniGW used to be used a lot, but I haven't seen many projects targetting minigw toolchain since MS started giving free-as-in-beer compiler and headers, which just fits in better with their platform.
*Every* other platform has first-party supported development tools for free, to foster the success of the respective platform.
In that case, Visual Studio is less of an *I*DE and more of 'just an editor with good support for the syntax of C++'. When I think IDE, I think in-place debugging, understanding of the APIs that I'm coding against, etc.If the editor doesn't have an interface for compile, execute, and debug of code, as well as autocomplete showing unusable functions and omitting some you can use relative to your target platform, it can't be called an IDE...
You do realize why so much of the corporet segment is XP and IE6 right? It's because it's 'good enough'. Change for the sake of change is expensive. Vista started a wave of migration work, many aborted projects and feedback to MS from corporate customers on *why* they didn't want to deal with Vista. Much of the Windows 7 changes were driven by corporate requirements.
iPad's represent a far more drastic change than would iPad-centric model. The same holdouts for XP will not exactly be jumping at the chance to go iPad.
Keep in mind that Gates is still chairman of the board, and was still effectively directing strategy as chief software architect in 2006. That means he was still there overseeing things including the launch of XBox360 and.Net. I don't know where you source the gain in market share to discern what timeline you *think* Ballmer was responsible for. Effectively, up until ~2007 Ballmer had training wheels on.
MS offerings actually haven't signiicantly changed since Vista, which was released very shortly after Bill Gates stopped giving his full attention to MS (meaning he oversaw even most of Vista, though not the actual release).
Basically, they are frightened by Apple's relative success in mobile computing devices. They previously had a strategy around tablet computing, and Windows 7 represented them addressing all the obvious tweaks to be applied to the desktop environment for tablet use case. That market still hasn't taken off, so they assume Metro and ARM are required.
Of course, I think WP7 lackluster performance in the phone space demonstrates that perceived value of Windows on ARM is not particularly compelling. They might still think that the large form factor tablets might be more competitive, but I don't see any reason to believe it. In tablet space, MS best hope is probably Medfield and Brazos based devices, bringing the massive set of MS compatibile applications.
Forcing Metro on Desktop users to the extent possible is probably also a strategy to effectively throw the desktop usability under the bus to force people to get used to the interface. The hope being if users end up using Metro UI every day, it would grow on them or at least they would tolerate and understand it, and consistency between Windows Phone and Windows desktop gives the phone product a boost.
It's also the case that they are discontinuing the availability of the SDK that didn't have an IDE, just a compiler and header files. Perhaps minigw suffices, but I would've thought that MS first-party compiler and such would be the better solution for MS first-party platforms.
If you are trying to apply VPN logic to dropbox, you're likely to be in control of all 'ends'. If you want to upload to some dropxox space intended for osmeone, you use their public key to encrypt it, before it ever leaves your machine. Dropbox servers see an opaque, encrypted blob. The holder of the private key later comes along and retrieves it, decrypting it on their box. That would be analagous to the VPN case.
I think he's saying payload over dropbox is analagous to vpn over at&t. In the VPN case, you don't trust AT&T and use whatever VPN technology you want at either end to render the passing traffic undecipherable by at&t. Similarly, one could gpg a file, drop it on dropbox, and another could retrieve it, and un-gpg it. In this case, even if dropbox is a risk, the risk is greatly mitigated by the encryption that is performed outside of their framework.
Also see the MPAA endorsed poisoning of bittorrent swarms. 'secure by popular opinion' is a risky proposition, and IMHO TACK+CA is the best path and not TACK+Convergence.
It's an acknowledgement that no PKI infrastructure can offer a better assurance of continuity of trust than something along the lines of self-signed certificate. Establishing the trust in the first place is where PKI strategies are needed. In this scenario, TACK does nothing for initial connection, therefore PKI is used for that to bootstrap the TACK trust relationship. From then on, TACK protects against future PKI compromises. It's better than self-signed certificates and ssh host keys in that it provides facilities for administrators to manage expiry, revocation, and changes whereas usually changing the private key is going to induce headache.
Note also that you shouldn't "gnore Verisign from there on out". Both TACK and CA checks should pass once you can reasonably check both. In that way, a CA compromise is mitigated by TACK. Conversely, if your first visit was done when a CA was compromised, you'd end up with a malicious TACK setup. A subsequent visit having no cert verifiable by CA but passing TACK should still be rejected so that first-time MITM attacks can be mitigated later.
The CA signing is still required to verify a) that the host hasn't been breached
So for one, I don't see why TACK private key would be kept online, it doesn't have to be used continuously. Secondly, if a server is compromised enough that the private keys of any sort are compromised, *nothing* protects you. They don't need a key to sign a 'counterfeit' key, they can just grab the official, blessed server private key. First-time visitor case is better with CA, repeat-visitor case is far less secure than is possible. TACK helps the repeat visitor case to be resilient to compromised CA, which is a very real risk. No third-party trust system will work as well as something like TACK at that use case.
The way I read it, it is something closer to the way ssh known_hosts work (though with more flexibility for key changes). Not intended to wholly replace third-party attestation, but supplement it.
On first visit, browser takes the CA's word for it for lack of prior TACK knowledge. Then it also gets the TACK information, subsequent trips must pass *both* CA and TACK checks. If a trusted CA starts going wild, most traffic will not be able to be MITM because they haven't simultaneously defeated TACK. There is an exposure for first-time visits in a world with a compromised CA, but it does protect against the most common case.
That has about nothing to do with his point. Initial cost is not particularly driven by wattage. His point was that ~50 dollar x86 boards exist (though I think he is overly optimistic to say the price can include processor and memory). Even ignoring the cpu and memory, x86 boards incur more than enough complexity to offset the cost-add of an ARM chip and 512MB of memory. To support pci-e slots and a couple of DDR3 sockets, traces get significantly more complicated. To support a pluggable CPU, a much more expensive processor interconnect is used. The memory+cpu is probably cheaper than the average southbridge on a motherboard anyway.
So the question is not of 'value', the question is 'cost'. Lower power consumption adds value, but in this case doesn't really change the cost part of the equation.
I meant if Perl6 'succeeds' at making distros deprecate perl5, then perl is doomed as perl6 won't be interesting compared to other contemporary scripting languages without the stability of perl5.
No, they just can't figure out how to pass some of the checks and disable them. Generally upon investigation I find use strict complained for very good reason and I'm able to close out 'mysterious' bugs just by use strict.
Basically, most of any scripting language pretty much makes you throw out the codebase when you go to C. Exploring a concept to assess feasibility can work, but don't expect to not have to nearly start over, just with the benefit of knowing which algorithms/development paths just won't pan out.
Slashdot Mirror
I suggest office depot/officemax. At least in my neck of the woods they carried some of the higher end laptops that best buy didn't bother with. Also the obvious suggestion of an Apple store. MS store might work, but there isn't one within 250 miles of me so I wouldn't know.
I think it is *key* to try to find a way to actually physically evaluate whatever you narrow it down to. For mobile computing, form factor, weight, balance, rigidity, and other factors are best assessed first-hand.
A tad redundant. Tons of comments saying pretty much the exact same words without additional insight gets a tad old. Besides, unless submitter lives under a rock, they certainly already know about those offerings as Apple is *very* aggressive and savvy about their marketing. Many of the other options do not acheive the same awareness as Apple.
For me, without a pointer device on the home row, it's a non-starter. Therefore mac is off the table, even if it weren't 15-20% more expenisve than comparable quality Lenovo/HP laptops. Before you say the Macs are higher quality, they aren't. They are significantly better build quality than the Lenovo/HP products that are half the price of the Macbooks with comparable specs, but I'm talking about the higher end competitor model lines. The only thing you get is OSX, which actually isn't particularly anything special. Users unsatisfied with Windows in terms of UI flexibility or general architecture would probably be best served by Linux. Those unsatisfied with relative lack of commercial software in Linux would be best served by Windows.
Notably you should try to find a way to actually touch and hold your choice. Particularly your relative may not realize what a 17" laptop would mean for portability.
After having a few laptops ranging from 12 to 17 inches over time, I've found 14" to be what I feel to be a good compromise. 1600x900 display at least. When reasonable, I use an external 22" monitor at 1920x1200, but I wouldn't want to drag aronud the requisite bulk and weight of a 17" laptop again...
OSX: gcc comes along and xCode is a free download
Android: SDK is free
IOS: See XCode.
I think "coming with" isn't that critical, but free availability of the tools is.
If you want to write modern Windows applications, you don't really have much choice. You can target Java, but requiring a third-party runtime like that is pretty inelegant. MiniGW used to be used a lot, but I haven't seen many projects targetting minigw toolchain since MS started giving free-as-in-beer compiler and headers, which just fits in better with their platform.
*Every* other platform has first-party supported development tools for free, to foster the success of the respective platform.
In that case, Visual Studio is less of an *I*DE and more of 'just an editor with good support for the syntax of C++'. When I think IDE, I think in-place debugging, understanding of the APIs that I'm coding against, etc.If the editor doesn't have an interface for compile, execute, and debug of code, as well as autocomplete showing unusable functions and omitting some you can use relative to your target platform, it can't be called an IDE...
he has literally pissed away billions of dollars
To literally do that is quite an anatomical feat.
You do realize why so much of the corporet segment is XP and IE6 right? It's because it's 'good enough'. Change for the sake of change is expensive. Vista started a wave of migration work, many aborted projects and feedback to MS from corporate customers on *why* they didn't want to deal with Vista. Much of the Windows 7 changes were driven by corporate requirements.
iPad's represent a far more drastic change than would iPad-centric model. The same holdouts for XP will not exactly be jumping at the chance to go iPad.
Keep in mind that Gates is still chairman of the board, and was still effectively directing strategy as chief software architect in 2006. That means he was still there overseeing things including the launch of XBox360 and .Net. I don't know where you source the gain in market share to discern what timeline you *think* Ballmer was responsible for. Effectively, up until ~2007 Ballmer had training wheels on.
MS offerings actually haven't signiicantly changed since Vista, which was released very shortly after Bill Gates stopped giving his full attention to MS (meaning he oversaw even most of Vista, though not the actual release).
Basically, they are frightened by Apple's relative success in mobile computing devices. They previously had a strategy around tablet computing, and Windows 7 represented them addressing all the obvious tweaks to be applied to the desktop environment for tablet use case. That market still hasn't taken off, so they assume Metro and ARM are required.
Of course, I think WP7 lackluster performance in the phone space demonstrates that perceived value of Windows on ARM is not particularly compelling. They might still think that the large form factor tablets might be more competitive, but I don't see any reason to believe it. In tablet space, MS best hope is probably Medfield and Brazos based devices, bringing the massive set of MS compatibile applications.
Forcing Metro on Desktop users to the extent possible is probably also a strategy to effectively throw the desktop usability under the bus to force people to get used to the interface. The hope being if users end up using Metro UI every day, it would grow on them or at least they would tolerate and understand it, and consistency between Windows Phone and Windows desktop gives the phone product a boost.
It's also the case that they are discontinuing the availability of the SDK that didn't have an IDE, just a compiler and header files. Perhaps minigw suffices, but I would've thought that MS first-party compiler and such would be the better solution for MS first-party platforms.
If you are trying to apply VPN logic to dropbox, you're likely to be in control of all 'ends'. If you want to upload to some dropxox space intended for osmeone, you use their public key to encrypt it, before it ever leaves your machine. Dropbox servers see an opaque, encrypted blob. The holder of the private key later comes along and retrieves it, decrypting it on their box. That would be analagous to the VPN case.
I think he's saying payload over dropbox is analagous to vpn over at&t. In the VPN case, you don't trust AT&T and use whatever VPN technology you want at either end to render the passing traffic undecipherable by at&t. Similarly, one could gpg a file, drop it on dropbox, and another could retrieve it, and un-gpg it. In this case, even if dropbox is a risk, the risk is greatly mitigated by the encryption that is performed outside of their framework.
WebOS has a beautiful UI strategy, for alerts and multitasking. It however had crappy apps....
Also see the MPAA endorsed poisoning of bittorrent swarms. 'secure by popular opinion' is a risky proposition, and IMHO TACK+CA is the best path and not TACK+Convergence.
It's an acknowledgement that no PKI infrastructure can offer a better assurance of continuity of trust than something along the lines of self-signed certificate. Establishing the trust in the first place is where PKI strategies are needed. In this scenario, TACK does nothing for initial connection, therefore PKI is used for that to bootstrap the TACK trust relationship. From then on, TACK protects against future PKI compromises. It's better than self-signed certificates and ssh host keys in that it provides facilities for administrators to manage expiry, revocation, and changes whereas usually changing the private key is going to induce headache.
Note also that you shouldn't "gnore Verisign from there on out". Both TACK and CA checks should pass once you can reasonably check both. In that way, a CA compromise is mitigated by TACK. Conversely, if your first visit was done when a CA was compromised, you'd end up with a malicious TACK setup. A subsequent visit having no cert verifiable by CA but passing TACK should still be rejected so that first-time MITM attacks can be mitigated later.
The CA signing is still required to verify a) that the host hasn't been breached
So for one, I don't see why TACK private key would be kept online, it doesn't have to be used continuously. Secondly, if a server is compromised enough that the private keys of any sort are compromised, *nothing* protects you. They don't need a key to sign a 'counterfeit' key, they can just grab the official, blessed server private key. First-time visitor case is better with CA, repeat-visitor case is far less secure than is possible. TACK helps the repeat visitor case to be resilient to compromised CA, which is a very real risk. No third-party trust system will work as well as something like TACK at that use case.
The way I read it, it is something closer to the way ssh known_hosts work (though with more flexibility for key changes). Not intended to wholly replace third-party attestation, but supplement it.
On first visit, browser takes the CA's word for it for lack of prior TACK knowledge. Then it also gets the TACK information, subsequent trips must pass *both* CA and TACK checks. If a trusted CA starts going wild, most traffic will not be able to be MITM because they haven't simultaneously defeated TACK. There is an exposure for first-time visits in a world with a compromised CA, but it does protect against the most common case.
I think the criticism was of the use of "threesixty" as opposed to 360...
That has about nothing to do with his point. Initial cost is not particularly driven by wattage. His point was that ~50 dollar x86 boards exist (though I think he is overly optimistic to say the price can include processor and memory). Even ignoring the cpu and memory, x86 boards incur more than enough complexity to offset the cost-add of an ARM chip and 512MB of memory. To support pci-e slots and a couple of DDR3 sockets, traces get significantly more complicated. To support a pluggable CPU, a much more expensive processor interconnect is used. The memory+cpu is probably cheaper than the average southbridge on a motherboard anyway.
So the question is not of 'value', the question is 'cost'. Lower power consumption adds value, but in this case doesn't really change the cost part of the equation.
I meant if Perl6 'succeeds' at making distros deprecate perl5, then perl is doomed as perl6 won't be interesting compared to other contemporary scripting languages without the stability of perl5.
No, they just can't figure out how to pass some of the checks and disable them. Generally upon investigation I find use strict complained for very good reason and I'm able to close out 'mysterious' bugs just by use strict.
Basically, most of any scripting language pretty much makes you throw out the codebase when you go to C. Exploring a concept to assess feasibility can work, but don't expect to not have to nearly start over, just with the benefit of knowing which algorithms/development paths just won't pan out.
What's *really scary* is a perl script with '#use strict;'. Meaning they tried to use strict; but gave up on it.