Linux works too, but that needs a *serious* injection of usability knowledge to get anywhere near Linux, and you have the chicken-and-egg issue of commercial applications. A Macbook (and a Linux machine if set up correctly) is a close-the-lid-and-go proposition that I can also put in the hands of an executive without worrying too much that they'll screw it up, and still force them to make a safe backup when travelling. I don't have the time to tweak settings, nor do I want to have my workflow interrupted by a Windows update which blocks a shutdown until it, on its own time, decides it's done. I use all three platforms (Linux, mostly Debian, MacOS and Windows), and my personal preference is still MacOS combined with a lot of FOSS (LibreOffice, for instance, and wireshark via brew). One is cheap to obtain and costs you more in wasted time, one is expensive upfront but you waste less time waiting for upgrades that too plentiful. You buy Apple because you value your time. you still want a commercial grade desktop where you can execute commercial applications alongside Open Source ones with Unix and all the associated benefits and languages underneath, accompanied by hardware that you can get serviced anywhere in the world without having to spend a fortune on "support" contracts. Its obviously more complex to design a system to take advantage of this flexibility but its a whole lot more efficient, and secure, than recompiling everything to be unnecessarily '64 bit'.Īnd now you've basically done that, you're paying for Apple because.? So my understanding of this processor is that it should be able to use a mixture of 16, 32 and 64 bit designated memory areas depending on what they're used for. This architecture is inherently secure but it does involve some overhead if protection mechanisms are invoked (and its only got four 'rings' although modern code only seems to use two).
I think a lot of our problems arise because this model is not compatible with the "bloody great pool of generic memory" model that much of our code is written for, the model that doesn't differentiate between executable, data and stack memory (so is easily surprised when bad actors fudge getting code onto the stack or into data areas and force execution of that code).
The descriptor identifies a block of memory and its properties such as usage (stack, code, data), properties and dimensions.
If I recall correctly the Intel architecture accesses memory as combination of a descriptor and an offset. AMD who figured out how to make the x86 both 32 bit and 64 bit at the same time.
0 kommentar(er)
