The only reason why I have a Mac Mini is because you are running a modified version of UNIX. This pleases me. But be forewarned: If your future plans include replacing BSD UNIX with your shitass iOS, I am so fucking gone. Your shitty phones are already on my do not buy list, and I have no qualms with dumping your PCs.
iOS is still Unix-y underneath. If you jailbreak your iOS you can get a root shell:
http://stackoverflow.com/questions/8516370/
I think he wants a Unix where he doesn't have to jailbreak it to get a root shell, or a shell at all, or to run whatever software he wants, or possibly even to add kernel modules or boot with his own/mach_kernel.
As critical as I am of Apple on occasion, I see this as a smart idea. Staying limber by making sure your kernel and toolset can compile on multiple platforms only makes sense. It's a wonder that, four decades after Unix lead the path to portability, now commercial outfits like Apple and Microsoft are seeing the value as well (well, to be fair, MS saw the value back in the early 1990s but guys like DEC and MIPS priced their stuff into the stratosphere thus guaranteeing x86's continued dominance).
And Apple saw it, at least for Unix, somewhere between the late '90's and early 00's (and NeXT saw it earlier), but the portability there was to x86, not from x86....
Now that people look at iDevices and their non-Apple kin as devices, it just takes some time to convince them that the idea of a "computer" really isn't what they ever wanted. They've always wanted devices, and with OSX and now Windows drawing more and more from the closed ecosystem models they spawned off for the mobile realm, people will eventually come around.
I give it around two years before Apple comes out with a new line of ARM-based Macbook Airs
It's not as if there's anything about ARM itself that makes a machine using ARM processors inherently a walled-garden "device". (Hell, ARM was originally developed for a line of general-purpose personal computers.) Maybe the architecture switch enables that, but there's nothing about that that inherently makes the new machines walled-garden "devices" (that's not what happened with the PPC -> x86 transition).
The company I work for has a product that was last re-written back in 1999. At that time it worked both on Macs and PCs.
At the time, mainstream desktop Windows supported Win32 (not quite to the same degree as NT, but still not too bad) on x86. At the time, did Mac OS 8 or 9 support Carbon and, if so, did you use it? Even if you did, you would have had to build it as PEF rather than Mach-O, as OS X wasn't out yet, so you would have had to switch to Mach-O in order to survive the PPC -> x86 transition except under Rosetta.
Now here we are 13 years later and it still works on the PC side, but not at all on Macs.
...and Windows NT 6.2, or whatever it is they're calling "Windows 8", still supports Win32 on x86, but OS X no longer supports PPC binaries or PEF, so you might have had to make significant changes to the way you built your app (and significant changes to the app itself if you weren't using Carbon).
So, to some degree, it's a matter of bad luck - if you'd had a reason to rewrite it in, say, 2001, you might have had something not so hard to make work natively on OS X and not so hard to port from (big-endian) PPC to (little-endian) x86.
When you have a build server, you code on entry level laptops which aren't Mac as OSX tends not to play well with code repositories like Subversion.
SVN works fine for me on OS X as a Wireshark core developer. (And Git works fine for me on OS X as a libpcap/tcpdump core developer.) What problems are people seeing with SVN on OS X? (Then again, I don't use a build server, as my 4-core doubly-threaded 16GB machine is pretty much fast enough; faster would be nice, but....)
Coders doing local builds are also falling off Mac because it's too hard to get an off the shelf SSD working in one.
It works fine for me, but the Mac I bought comes standard with one.
Unix developers in particular have almost completely abandoned Mac because Apple have made it too difficult to get Linux running on there.
To which sort of "Unix developer" are you referring?
If you mean "people primarily developing Linux or for Linux", to what extent did they care about Macs in the first place, unless one of the Unixes for which they're developing was OS X? Unless they needed to run OS X (and weren't going to hackintosh their machine or see if they could hackintosh some virtual machine system), they probably would only run Linux, or run Linux with the occasional boot to some other flavor of Unix, or run Linux and then run the other Unixes atop Parallels or VMware.
If you mean "people developing for a variety of Unixes", a lot of them could run OS X and run Linux in Parallels or VMware - most of my development work on the projects I listed above is done under OS X, with one of my horde of VMs fired up if I need to do something on another platform; VMware Fusion happily runs Ubuntu {7.10,9.10,10.10} and Fedora {9,16}, as well as Solaris {10,11}, FreeBSD {7.3,9.0}, OS X 10.{5 Server,6 Server,7,8}, Windows NT {5.1,6.1}, and, with some issues, NetBSD 5.1 and OpenBSD 4.8. (It may well run others, but, until my new machine, I didn't have the "disk" space for enough VMs, and I really don't need a full panoply of OSes - those were what either happened to be current when I {downloaded,bought} them or what platform somebody happened to be bitching about in a mail message or bug report.)
If the rumors are already out there, it means the kernel has been compiled for ARM already.
Yes. It's called "the iOS kernel". Yeah, #ifdef this/that/the other thing and all that, so maybe not every single code path used by the OS X version has been used on ARM, and the machine-dependent parts for ARM might not support everything OS X nees, but several bits of Darwin support more than one instruction set architecture, so it's not as if it's a completely exotic port.
2) FreeBSD is workstation/server oriented. Suspend/hibernate support isn't crucial for these machines. Sorry. It's just not a high priority. FreeBSD doesn't prioritize supporting laptops
My workstation is a laptop, and I open and close it all the time. Fortunately, it's running a 4.4-Lite-flavored OS that does do a good job of handling suspend/hibernate.
Linus is talking about laptops. You know, the topic of this discussion.
And he's not bitching about screen real estate, he's bitching about pixel density, as per TFGPP:
And the next technology journalist that asks you whether you want fonts that small, I'll just hunt down and give an atomic wedgie. I want pixels for high-quality fonts, and yes, I want my fonts small, but "high resolution" really doesn't equate "small fonts" like some less-than-gifted tech pundits seem to constantly think.
Fair enough. I don't think many here would begrudge you buying Apple for the hardware. The quality and design are clearly very high. All the problems I hear about Apple are about it's walled garden (purely a software issue).
...and it's only iOS where you have to jailbreak to climb over the walls; for OS X you aren't obliged to run App Store apps (or even apps from "registered developers", although the Gatekeeper default setting requires that you control+click those and select "Open" to launch binaries downloaded from a network not signed by a registered developer - compile the binary yourself, or download it with something that doesn't slap a quarantine extended attribute on it, and that's not an issue, though).
Wow. Didn't think I would have to point out I was referring to the AC talking about it being the same on the iPad, but apparently I do.
For the other dense readers, yes, the iPad runs iOS. Just to be on the safe side.
...and the first part of what you said, "The only things that MAGICALLY get blown up is older software that doesn't understand the new resolutions.", also applies, mutatis mutandis, to OS X, as per my response to Anonymous Howard, and this bit of Apple documentation that apparently didn't get linked in my post (sorry about that).
Satirical scientific articles are a field of literature ripe for expansion. The only one I know of to have really found a wide readership (at least among those who follow modern literature) is Georges Perec's Cantatrix Sopranica L..
And the next technology journalist that asks you whether you want fonts that small, I'll just hunt down and give an atomic wedgie. I want pixels for high-quality fonts, and yes, I want my fonts small, but "high resolution" really doesn't equate "small fonts" like some less-than-gifted tech pundits seem to constantly think.
In fact, if you have bad vision, sharp good high-quality fonts will help.
(+1 for Linus for "atomic wedgie" - but, really, "less-than-gifted" is kinda the default for tech pundits, given that a lot of them are paid to be adbait)
Who can read anything at that resolution for fuck sake?
Those of us with 1) aging eyes and 2) desktop environments that draw text, GUI widgets, etc. at high resolution (i.e., they use ~4x the number of pixels to draw stuff at the same size, rather than drawing stuff at 1/2 the horizontal and vertical sizes).
I have. I got one a month or so ago, have been using it as my only machine since then, and am typing this response on it. (The main reason was to get 16GB of memory and a lot more "disk" space, not anything to do with the display.)
Apparently not, since you're trying to argue it's not just blown up. It's exact 4x the size of the default 1440x900 for a reason.
Yes, it allows applications/images/etc. that don't use the native resolution to do pixel-doubling while allowing those that do to use the native resolution. No, the graphics layer does not make all apps think they're on a 1440x900 display and then do pixel-doubling; it exposes the native 2880x1800 to Cocoa apps that can handle it, and does some high-res stuff ("framework-scaled mode") for Cocoa apps "whose code base has not yet been optimized for high-resolution graphics" and "[aren't] known to have significant issues when running in framework-scaled mode" and weren't explicitly opened in low-resolution mode, and does pixel-doubling ("magnified mode") for everything else. Follow The Fine Link for details.
So the claim that "the retina display and other 'high def' isn't actually a true display of that resolution, just a multiplication of the pixels in a 1:4 ratio of a smaller resolution.", if meant to be a general description of the behavior of all code on a Retina MBP under all OSes including OS X, is false. I can't speak for other high-def machines and the graphics layers of the desktop environments that run on them, but I wouldn't be surprised if at least some of them also provide native resolution to apps that can handle it. Anybody making the strong version of that claim has either not ever used a Retina MBP, did so on an OS that doesn't handle the native resolution, or did use it on an OS that can handle it but wasn't paying attention.
As for the rest of the post in question:
Laptops are lacking in graphical power and actually providing that as a true resolution is a bit of a hard proposition for anyone for an actual laptop that might have to do anything graphically demanding.
...which doesn't ipso facto mean that no laptop provides that as a true resolution. I don't know how you define "graphically demanding"; I generally don't do anything I would consider too "graphically demanding" (a lot of Terminal.app, a fair bit of Safari.app and Mail.app and NetNewsWire.app, a fair bit of VMware Fusion.app and Quicken.app, and bits of other things), so maybe anything truly "graphically demanding" wouldn't work well, but that doesn't mean that Apple didn't say "OK, maybe your laptop will heat up a fair bit and slow down somewhat if you do something really graphically demanding, but it'll still show pretty crisp text, UI controls, and images properly tuned for high resolution" (yes, some stuff probably not tuned for high resolution, such as the gear next to the "Post Anonymously" label in the posting box for the reply I'm typing, look noticeably fuzzy).
That and it doesn't particularly look very good just making those smaller resolutions just 'blown up'.
True, as noted, but when it's rendering stuff at native resolution, it looks pretty good. I'm willing to put up with fuzzy images in some cases in order to get the crisper text for my aging eyes.
I always wonder, why change the ABI so often? after all the instruction set is only the interface between the C compiler
XXX compiler, for all values of XXX where machine code (rather than some virtual instruction set or code in some lower-level language) is generated, and also assembler.
and the underlying VLIW CPU engine.
For which instruction sets other than x86, in Pentium Pro and later, and z/Architecture, in z196 and later, is that the case?
That's why the first 64 bit processors were actually slower in 64 bit than in 32 bits, and even today they aren't that faster in 64-bit mode.
Unless you happen to be dealing with more data than fits into a 32-bit addressing space, in which case all the I/O, or memory mapping/unmapping, you're doing might slow you down a bit.
If not, pointers will be larger, so pointer-heavy data structures might have a bigger cache footprint and get a slowdown from that; data copying might get a speedup, as would 64-bit arithmetic, but other stuff might not get any speedup, unless there's register pressure and the 64-bit version of the instruction has more registers (as per x86-64 and ARMv8) or has, in newer versions, some tricks to let you use the two halves of a 64-bit register for two 32-bit quantities (as in newer versions of z/Architecture).
I suspect is all a Patent game, that's why CPU designers keeps modifying the ABI. Their patents are expiring all the time.
CPU designers "keep modifying the ABI" because they're adding new instructions; perhaps they think that they'll speed up certain operations rather than thinking it'll protect them from cloners. They don't keep making incompatible changes, at least for CPUs where incompatible instruction set changes would break binary packaged software. And, for those CPUs, if you make a 64-bit version of an instruction set, you can choose to make incompatible changes as long as the 32-bit version doesn't change; that's what, for example, AMD did (stuff such as 8 more general-purpose registers and a PC-relative addressing mode) and ARM did.
Apple didn't have a "head of software". It had a head of iOS software (Forstall), a head of OS X software (Federighi), and possibly a head of "Internet Software and Services" (Cue) (alas, I don't have a copy of yesterday's http://www.apple.com/pr/bios/, just some old June 2012-vintage stuff from the Internet Archive). It now has a head of Software Engineering (Federighi), and a head of Internet Software and Services (Cue), so....
As Steve Jobs said software is the soul of the products.
...and Apple still has people in charge of it.
We NEED to support people who think different!
Thinking differently is a means to an end. The end is to think better, which may require thinking differently, but merely thinking differently is insufficient to think better.
After reading that, I realized that this was indeed true and in fact there has been an alternate philosphy besides the skeuomorphic design which is the "war on color" in some aspects of OS X (e.g., the flat gray scroll bars, the gray linen background for the virtual desktop manager, even the world map for changing the time zone). So, now I'm wondering if the skeuomorphic faction led by Forstall has lost the debate, was Ive and the other minimalist design people behind the "war on color" and if that's true, is that what we'll see in future versions of the OS with Ive leading the interface design?
As long as whoever started the "war on contrast" is either fired or re-educated, I can live with the war on color. The Fine Corinthian Leather in iCal/Calendar is one shot in the war on contrast - black on white is easier to read than black on light brown.
For example, the way the OS X Address Book attempts to resemble
a paper address book. This is pointless and stupid
And harder to use than the Boring Old Doesn't Pretend It Looks Like Something Many Of You Have Never Seen In Your Life pre-Lion Address Book. (Yes, pretend it looks like - I've never seen a real life address book that had "groups" into which you could put entries and that showed the groups on the left page and a summary of the addresses in that group on the right page and had a bookmark ribbon that, when you touched it, turned the pages so that the summary of items in the group was on the left page and the full item was on the right page. Steaming heap of concentrated stupid....) At least Mountain Lion brought the three-pane view back, so you could see your groups and the summary of the currently selected group and the currently selected item at the same time.
I find the faux book cover and faux stitching irritating, but, hey, maybe there are people who like that stuff, just as there are probably people who like fake wood in car designs. The shit UI is inexcusable - that is the real problem with Skeuomorphism Gone Apeshit.
Also, and MUCH more important : Apple MUST quit trying to blend the
interface used by OS X with the interface used by iOS. The result of
such attempts at blending is stuff that is annoying and awful to use and
it is an insult to a user who has a modicum of intelligence. QUIT THIS
SHIT, Tim Cook, or your legacy will be that of the guy who fucked up
a good thing, and that is not a legacy anyone with honor wants.
To be fair, I think that started before Cook was CEO.
Well, the DEC-10 is mainly discrete logic chips and Transistors. Depending upon its exact vintage I expect that there would be lots of 74xxx IC's.
There's a KI and a KL. From reading the KI10 schematics and pages such as the one for the M133 NAND gate module (the schematics referred to module names such as that), I infer the KI10 had DEC-proprietary ICs. The KL10 was ECL, so it wouldn't use 74xxx's (unless there was an ECL variant).
Slashdot Mirror
68000 was CISC, not RISC.
And its addressing modes, at least, were CISCier than x86's (auto-increment, auto-decrement, etc.).
I didnt know Berkley was in Switzerland.
Or that Murray Hill, New Jersey was in Switzerland either. (I.e., both parts of that saying are false claims.)
is about to go off the cliff. The first clue is when the CEO is asleep at the wheel, and the car starts wandering aimlessly.
This is one of those times.
Yeah, Jobs would never have let engineering consider changing processor architectures.
The only reason why I have a Mac Mini is because you are running a modified version of UNIX. This pleases me. But be forewarned: If your future plans include replacing BSD UNIX with your shitass iOS, I am so fucking gone. Your shitty phones are already on my do not buy list, and I have no qualms with dumping your PCs.
iOS is still Unix-y underneath. If you jailbreak your iOS you can get a root shell:
http://stackoverflow.com/questions/8516370/
I think he wants a Unix where he doesn't have to jailbreak it to get a root shell, or a shell at all, or to run whatever software he wants, or possibly even to add kernel modules or boot with his own /mach_kernel.
As critical as I am of Apple on occasion, I see this as a smart idea. Staying limber by making sure your kernel and toolset can compile on multiple platforms only makes sense. It's a wonder that, four decades after Unix lead the path to portability, now commercial outfits like Apple and Microsoft are seeing the value as well (well, to be fair, MS saw the value back in the early 1990s but guys like DEC and MIPS priced their stuff into the stratosphere thus guaranteeing x86's continued dominance).
And Apple saw it, at least for Unix, somewhere between the late '90's and early 00's (and NeXT saw it earlier), but the portability there was to x86, not from x86....
Now that people look at iDevices and their non-Apple kin as devices, it just takes some time to convince them that the idea of a "computer" really isn't what they ever wanted. They've always wanted devices, and with OSX and now Windows drawing more and more from the closed ecosystem models they spawned off for the mobile realm, people will eventually come around.
I give it around two years before Apple comes out with a new line of ARM-based Macbook Airs
It's not as if there's anything about ARM itself that makes a machine using ARM processors inherently a walled-garden "device". (Hell, ARM was originally developed for a line of general-purpose personal computers.) Maybe the architecture switch enables that, but there's nothing about that that inherently makes the new machines walled-garden "devices" (that's not what happened with the PPC -> x86 transition).
The company I work for has a product that was last re-written back in 1999. At that time it worked both on Macs and PCs.
At the time, mainstream desktop Windows supported Win32 (not quite to the same degree as NT, but still not too bad) on x86. At the time, did Mac OS 8 or 9 support Carbon and, if so, did you use it? Even if you did, you would have had to build it as PEF rather than Mach-O, as OS X wasn't out yet, so you would have had to switch to Mach-O in order to survive the PPC -> x86 transition except under Rosetta.
Now here we are 13 years later and it still works on the PC side, but not at all on Macs.
...and Windows NT 6.2, or whatever it is they're calling "Windows 8", still supports Win32 on x86, but OS X no longer supports PPC binaries or PEF, so you might have had to make significant changes to the way you built your app (and significant changes to the app itself if you weren't using Carbon).
So, to some degree, it's a matter of bad luck - if you'd had a reason to rewrite it in, say, 2001, you might have had something not so hard to make work natively on OS X and not so hard to port from (big-endian) PPC to (little-endian) x86.
When you have a build server, you code on entry level laptops which aren't Mac as OSX tends not to play well with code repositories like Subversion.
SVN works fine for me on OS X as a Wireshark core developer. (And Git works fine for me on OS X as a libpcap/tcpdump core developer.) What problems are people seeing with SVN on OS X? (Then again, I don't use a build server, as my 4-core doubly-threaded 16GB machine is pretty much fast enough; faster would be nice, but....)
Coders doing local builds are also falling off Mac because it's too hard to get an off the shelf SSD working in one.
It works fine for me, but the Mac I bought comes standard with one.
Unix developers in particular have almost completely abandoned Mac because Apple have made it too difficult to get Linux running on there.
To which sort of "Unix developer" are you referring?
If you mean "people primarily developing Linux or for Linux", to what extent did they care about Macs in the first place, unless one of the Unixes for which they're developing was OS X? Unless they needed to run OS X (and weren't going to hackintosh their machine or see if they could hackintosh some virtual machine system), they probably would only run Linux, or run Linux with the occasional boot to some other flavor of Unix, or run Linux and then run the other Unixes atop Parallels or VMware.
If you mean "people developing for a variety of Unixes", a lot of them could run OS X and run Linux in Parallels or VMware - most of my development work on the projects I listed above is done under OS X, with one of my horde of VMs fired up if I need to do something on another platform; VMware Fusion happily runs Ubuntu {7.10,9.10,10.10} and Fedora {9,16}, as well as Solaris {10,11}, FreeBSD {7.3,9.0}, OS X 10.{5 Server,6 Server,7,8}, Windows NT {5.1,6.1}, and, with some issues, NetBSD 5.1 and OpenBSD 4.8. (It may well run others, but, until my new machine, I didn't have the "disk" space for enough VMs, and I really don't need a full panoply of OSes - those were what either happened to be current when I {downloaded,bought} them or what platform somebody happened to be bitching about in a mail message or bug report.)
If the rumors are already out there, it means the kernel has been compiled for ARM already.
Yes. It's called "the iOS kernel". Yeah, #ifdef this/that/the other thing and all that, so maybe not every single code path used by the OS X version has been used on ARM, and the machine-dependent parts for ARM might not support everything OS X nees, but several bits of Darwin support more than one instruction set architecture, so it's not as if it's a completely exotic port.
2) FreeBSD is workstation/server oriented. Suspend/hibernate support isn't crucial for these machines. Sorry. It's just not a high priority. FreeBSD doesn't prioritize supporting laptops
My workstation is a laptop, and I open and close it all the time. Fortunately, it's running a 4.4-Lite-flavored OS that does do a good job of handling suspend/hibernate.
....yet
...and perhaps not ever.
Linus is talking about laptops. You know, the topic of this discussion.
And he's not bitching about screen real estate, he's bitching about pixel density, as per TFGPP:
Fair enough. I don't think many here would begrudge you buying Apple for the hardware. The quality and design are clearly very high. All the problems I hear about Apple are about it's walled garden (purely a software issue).
...and it's only iOS where you have to jailbreak to climb over the walls; for OS X you aren't obliged to run App Store apps (or even apps from "registered developers", although the Gatekeeper default setting requires that you control+click those and select "Open" to launch binaries downloaded from a network not signed by a registered developer - compile the binary yourself, or download it with something that doesn't slap a quarantine extended attribute on it, and that's not an issue, though).
Wow. Didn't think I would have to point out I was referring to the AC talking about it being the same on the iPad, but apparently I do.
For the other dense readers, yes, the iPad runs iOS. Just to be on the safe side.
...and the first part of what you said, "The only things that MAGICALLY get blown up is older software that doesn't understand the new resolutions.", also applies, mutatis mutandis, to OS X, as per my response to Anonymous Howard, and this bit of Apple documentation that apparently didn't get linked in my post (sorry about that).
Satirical scientific articles are a field of literature ripe for expansion. The only one I know of to have really found a wide readership (at least among those who follow modern literature) is Georges Perec's Cantatrix Sopranica L. .
Or this paper.
Of course, the Sokal hoax paper is also a brilliant piece of writing.
And here ya go.
Apple now offers you two laptops with that res and higher. Yet instead of praising what apple has done, he says "stop with the retina crap".
He's praising the hardware and condemning the marketing term Apple applies to it.
(emphasis mine).
Or, to quote some dude up in Oregon:
(+1 for Linus for "atomic wedgie" - but, really, "less-than-gifted" is kinda the default for tech pundits, given that a lot of them are paid to be adbait)
Who can read anything at that resolution for fuck sake?
Those of us with 1) aging eyes and 2) desktop environments that draw text, GUI widgets, etc. at high resolution (i.e., they use ~4x the number of pixels to draw stuff at the same size, rather than drawing stuff at 1/2 the horizontal and vertical sizes).
Have you even TRIED a retina display macbook?
I have. I got one a month or so ago, have been using it as my only machine since then, and am typing this response on it. (The main reason was to get 16GB of memory and a lot more "disk" space, not anything to do with the display.)
Apparently not, since you're trying to argue it's not just blown up. It's exact 4x the size of the default 1440x900 for a reason.
Yes, it allows applications/images/etc. that don't use the native resolution to do pixel-doubling while allowing those that do to use the native resolution. No, the graphics layer does not make all apps think they're on a 1440x900 display and then do pixel-doubling; it exposes the native 2880x1800 to Cocoa apps that can handle it, and does some high-res stuff ("framework-scaled mode") for Cocoa apps "whose code base has not yet been optimized for high-resolution graphics" and "[aren't] known to have significant issues when running in framework-scaled mode" and weren't explicitly opened in low-resolution mode, and does pixel-doubling ("magnified mode") for everything else. Follow The Fine Link for details.
So the claim that "the retina display and other 'high def' isn't actually a true display of that resolution, just a multiplication of the pixels in a 1:4 ratio of a smaller resolution.", if meant to be a general description of the behavior of all code on a Retina MBP under all OSes including OS X, is false. I can't speak for other high-def machines and the graphics layers of the desktop environments that run on them, but I wouldn't be surprised if at least some of them also provide native resolution to apps that can handle it. Anybody making the strong version of that claim has either not ever used a Retina MBP, did so on an OS that doesn't handle the native resolution, or did use it on an OS that can handle it but wasn't paying attention.
As for the rest of the post in question:
Laptops are lacking in graphical power and actually providing that as a true resolution is a bit of a hard proposition for anyone for an actual laptop that might have to do anything graphically demanding.
...which doesn't ipso facto mean that no laptop provides that as a true resolution. I don't know how you define "graphically demanding"; I generally don't do anything I would consider too "graphically demanding" (a lot of Terminal.app, a fair bit of Safari.app and Mail.app and NetNewsWire.app, a fair bit of VMware Fusion.app and Quicken.app, and bits of other things), so maybe anything truly "graphically demanding" wouldn't work well, but that doesn't mean that Apple didn't say "OK, maybe your laptop will heat up a fair bit and slow down somewhat if you do something really graphically demanding, but it'll still show pretty crisp text, UI controls, and images properly tuned for high resolution" (yes, some stuff probably not tuned for high resolution, such as the gear next to the "Post Anonymously" label in the posting box for the reply I'm typing, look noticeably fuzzy).
That and it doesn't particularly look very good just making those smaller resolutions just 'blown up'.
True, as noted, but when it's rendering stuff at native resolution, it looks pretty good. I'm willing to put up with fuzzy images in some cases in order to get the crisper text for my aging eyes.
I always wonder, why change the ABI so often? after all the instruction set is only the interface between the C compiler
XXX compiler, for all values of XXX where machine code (rather than some virtual instruction set or code in some lower-level language) is generated, and also assembler.
and the underlying VLIW CPU engine.
For which instruction sets other than x86, in Pentium Pro and later, and z/Architecture, in z196 and later, is that the case?
That's why the first 64 bit processors were actually slower in 64 bit than in 32 bits, and even today they aren't that faster in 64-bit mode.
Unless you happen to be dealing with more data than fits into a 32-bit addressing space, in which case all the I/O, or memory mapping/unmapping, you're doing might slow you down a bit.
If not, pointers will be larger, so pointer-heavy data structures might have a bigger cache footprint and get a slowdown from that; data copying might get a speedup, as would 64-bit arithmetic, but other stuff might not get any speedup, unless there's register pressure and the 64-bit version of the instruction has more registers (as per x86-64 and ARMv8) or has, in newer versions, some tricks to let you use the two halves of a 64-bit register for two 32-bit quantities (as in newer versions of z/Architecture).
I suspect is all a Patent game, that's why CPU designers keeps modifying the ABI. Their patents are expiring all the time.
CPU designers "keep modifying the ABI" because they're adding new instructions; perhaps they think that they'll speed up certain operations rather than thinking it'll protect them from cloners. They don't keep making incompatible changes, at least for CPUs where incompatible instruction set changes would break binary packaged software. And, for those CPUs, if you make a 64-bit version of an instruction set, you can choose to make incompatible changes as long as the 32-bit version doesn't change; that's what, for example, AMD did (stuff such as 8 more general-purpose registers and a PC-relative addressing mode) and ARM did.
Unfortunate end to Apple's head of software
Apple didn't have a "head of software". It had a head of iOS software (Forstall), a head of OS X software (Federighi), and possibly a head of "Internet Software and Services" (Cue) (alas, I don't have a copy of yesterday's http://www.apple.com/pr/bios/, just some old June 2012-vintage stuff from the Internet Archive). It now has a head of Software Engineering (Federighi), and a head of Internet Software and Services (Cue), so....
As Steve Jobs said software is the soul of the products.
...and Apple still has people in charge of it.
We NEED to support people who think different!
Thinking differently is a means to an end. The end is to think better, which may require thinking differently, but merely thinking differently is insufficient to think better.
After reading that, I realized that this was indeed true and in fact there has been an alternate philosphy besides the skeuomorphic design which is the "war on color" in some aspects of OS X (e.g., the flat gray scroll bars, the gray linen background for the virtual desktop manager, even the world map for changing the time zone). So, now I'm wondering if the skeuomorphic faction led by Forstall has lost the debate, was Ive and the other minimalist design people behind the "war on color" and if that's true, is that what we'll see in future versions of the OS with Ive leading the interface design?
As long as whoever started the "war on contrast" is either fired or re-educated, I can live with the war on color. The Fine Corinthian Leather in iCal/Calendar is one shot in the war on contrast - black on white is easier to read than black on light brown.
For example, the way the OS X Address Book attempts to resemble a paper address book. This is pointless and stupid
And harder to use than the Boring Old Doesn't Pretend It Looks Like Something Many Of You Have Never Seen In Your Life pre-Lion Address Book. (Yes, pretend it looks like - I've never seen a real life address book that had "groups" into which you could put entries and that showed the groups on the left page and a summary of the addresses in that group on the right page and had a bookmark ribbon that, when you touched it, turned the pages so that the summary of items in the group was on the left page and the full item was on the right page. Steaming heap of concentrated stupid....) At least Mountain Lion brought the three-pane view back, so you could see your groups and the summary of the currently selected group and the currently selected item at the same time.
I find the faux book cover and faux stitching irritating, but, hey, maybe there are people who like that stuff, just as there are probably people who like fake wood in car designs. The shit UI is inexcusable - that is the real problem with Skeuomorphism Gone Apeshit.
Also, and MUCH more important : Apple MUST quit trying to blend the interface used by OS X with the interface used by iOS. The result of such attempts at blending is stuff that is annoying and awful to use and it is an insult to a user who has a modicum of intelligence. QUIT THIS SHIT, Tim Cook, or your legacy will be that of the guy who fucked up a good thing, and that is not a legacy anyone with honor wants.
To be fair, I think that started before Cook was CEO.
There's a KI and a KL.
...and a KS, which used AMD 2901's in the data path.
Well, the DEC-10 is mainly discrete logic chips and Transistors. Depending upon its exact vintage I expect that there would be lots of 74xxx IC's.
There's a KI and a KL. From reading the KI10 schematics and pages such as the one for the M133 NAND gate module (the schematics referred to module names such as that), I infer the KI10 had DEC-proprietary ICs. The KL10 was ECL, so it wouldn't use 74xxx's (unless there was an ECL variant).