Programming had to be done on another machine with some expensive software development packages and copied over to the Mac.
No, there existed native development tools for pre-OS X Mac OS, e.g. Metrowerks' Code Warrior.
I have lots of software that I had working 5 or 10 years ago on linux, *BSD and solaris, but still doesn't work quite right on OSX.
So are you talking about CLI and/or server apps, or are you talking about GUI apps?
If it's about CLI and/or server apps, what's not working quite right? I think a free Apple Developer Connection account will let you file bugs - and, if something UN*Xy doesn't work on OS X, there's a good chance that it could be considered a bug. (Unfortunately, if the bug is duped to another bug, you don't get any updates on the progress of the other bug.)
If it's about GUI apps, that's the one place where OS X is quite different from all other UN*Xes, for better and for worse. There is X11 for running X11 apps, although you'd probably have to download and install the toolkit you're using yourself. There's also Trolltech's^WNokia's Qt, which could hide at least some of the differences. If there are documentation issues, you might want to file bugs on them.
Note also that the TELUS mobile Web service in question is WAP-based, so it's not direct access to the "real Internet"; a lot of sites might be unavailable because they don't offer WAP or because any Web-to-WAP gatewaying TELUS might be using can't handle them.
(BTW, is there any evidence that anybody named "Dylan Patten" has ever written anything, or is writing anything, for Time Magazine? And has he actually talked to the sources that the I Power site claims he has? And did those sources say what that site claims they do, or did they say something else that was misinterpreted?)
Sorry but I don't understand the differences, they're both mass storage with some sort of failsafe built in aren't they?
No.
The Xserver RAID - and the Promise RAID - are a bunch of disks in a shelf, plus a RAID controller and Fibre Channel interface; it provides mass storage (the disks), RAID (implemented by the RAID controller - presumably that's the "failsafe" to which you're referring), and an interface that lets host computers with a direct Fibre Channel connection, or computers on a SAN, access partitions on the device.
Xsan is software; it's a file system that plugs into the OS X VFS layer, providing to xnu the standard file system interface so that xnu system calls, and code using them, see a standard file system. It stores its data on storage on a SAN - which could be an Xserve RAID or a Promise RAID or an EMC box or a NetApp box or... - and other computers on the SAN, running Xsan or Quantum's StorNext cluster file system, can access the same file system at the same time. It doesn't provide mass storage, it uses mass storage on a SAN.
As Xserve was replaced by the Xsan 2 [macworld.com] I wouldn't necessarily call it a flop.
As the Xserve RAID was a RAID shelf, and Xsan is a SAN distributed file system, the Xserve RAID wasn't replaced by Xsan 2. It was replaced by third-party RAID subsystems. (Apple currently mentions systems from Promise, as per their server storage page.)
Apple hires a lot of workers at the lower end of the 'food chain', which skews their average salary.
The sample comes from people giving their salary to glassdoor.com and, presumably, describing themselves as software engineers. TFA shows a comparison of salaries for "Software Engineer(s)", not for all employees.
I thought all the "engineering" was done in China.
You thought incorrectly. (I'm just listing the hardware group, as I'm assuming you're making that statement because most of the manufacturing is done in China, and are thus thinking of hardware engineering.)
Apple can't "go back" to something it never went away from. Tiger had limited support for 64-bit code, whether on PPC or x86, and Leopard had 64-bit versions of most of its userland libraries. The Snow Leopard page doesn't say much about what's being done other than "Snow Leopard extends the 64-bit technology in Mac OS X to support breakthrough amounts of RAM - up to a theoretical 16TB, or 500 times more than what is possible today."
The PowerPC machines were 64-bit
Some of the PowerPC machines were 64-bit. The notebooks and the Mac mini were 32-bit.
Static linking of user binaries is not supported on Mac OS X.
And, to the extent that it's supported on Solaris, there's no guarantee that a binary statically linked in Solaris N will run correctly in Solaris N+1.
OS X's and Solaris's ABI's are defined in terms of calls to routines in dynamically-linked libraries, not in terms of system calls.
There may well be other UN*Xes that work the same way. I have the impression that's how Windows works, as well. This allows the implementation of routines in those dynamically-linked libraries to change, as long as the binary interface remains the same.
Meanwhile, Flash, properly used, is great. I'm not sure why people continue hating on Flash.
Well, for one thing, a depressingly large number of Web sites don't use it "properly", in the sense that a user of the site would probably mean. I fear it's probably being used "properly", in the sense that a crappy Web designer would mean or in the sense that whoever's paying the Web designer means (i.e., for all I know, some of those sites are designed to suck at getting useful information, as the purpose is to, for example, bamboozle you into buying a product, not to give you enough information to decide whether to buy the product or not or to decide which particular product to buy).
Whether it's Java, php, or another language, the pallette called the 'browser' is the biggest, most anarchistic piece of junk I've ever seen.
What browser is written in PHP? (Note: "browser" and "server" are two separate pieces of software. To lift a line from the original article, the server is like a sewage treatment plant - the average user should only notice it when something goes wrong. Unfortunately, we live in a world where your sewer line backs up several times a day.:-))
But the screen real estate, and the number of ways that it can be buggered are just insane.
Yes, just as desktop publishing software enabled what Henry Spencer called "ransom-note typography", the Web has enabled the construction of huge numbers of crappily-designed Web sites (many of which are enabled by a not-quite-so-great plugin - one of the pieces of software mentioned in the original article, with a name that begins with the letter grade you'd like to give to a lot of the designers who use it, namely the grade for "fail", and ends with a verb describing what you'd like to do to said designers with a whip).
A good UI shouldn't have to have users embedding markup language manually.
Most browsers don't. Did you mean "Web page editor" when you said "browser"?
Mark me as flamebait if you want, but the browser is a disaster, years after its invention, and constant reinvention.
Yes, such a disaster that most businesses and government organizations haven't bothered going online, and nobody's come up with any mechanism for searching the contents of Web sites.
The Web might be a disaster, but I, at least, still find it more convenient than the "lack of a Web" that we had before.
The third slide in the presentation clearly states that the Z6 is a sibling of the Power6
As that slide says, "Siblings, not identical twins", "Different personalities", and "Very different ISAs=> very different cores".
Further along in the presentation, slide 14 talks about the use of multiple-passes and millicode to handle CISC ops.
To be precise, it says "Multi-pass handling of special cases" and "Leverage millicode for complex operations"; that means "complex instructions trap to millicode", where "millicode" is similar to, for example, PALcode in Alpha processors - it's z/Architecture machine code plus some special millicode-mode-only instructions to, for example, manipulate internal status registers. See, for example, "Millicode in an IBM zSeries processor".
Clearly the Z6 is exquisitely optimized to execute the z/Architecture instruction efficiently. It is also clear that it is part of the Power6 family.
It's clear that, as the the third slide says, the Z6 "share[s] lots of DNA" with the Power6, i.e. it shares the fab technology, some low-level "design building blocks", large portions of some functional units, the pipeline design style, and many of the designers.
It's not at all clear, however, that it would belong to a family with "Power" in its name, given that it does not implement the Power ISA. If it's a sibling of the Power6, that makes it, in a sense, a member of a family that includes the Power6, but, given that its native instruction set is different from the Power instruction set, it makes no sense to give that family a name such as "Power6" or anything else involving "Power" - and it certainly makes no sense to assert that it's "sed on the POWER archictecture", as the person to whom I was responding asserted.
It is somewhat ironic that the Core architecture chips now used by Apple in all but the Mac Pros are all below the 3GHz clock "wall" that was never overcome by the G5
So it seems like POSIX says, "this function is not guaranteed to work".
Yes.
Sounds like people were aware of the problem for a long time.
People were aware that the notion of a directory being a sequence of entries, with each entry having a position such that you can get the position of an entry and later seek to that position and have the next read return that entry even if changes were made to the directory in the interim, was wrong.
That doesn't mean that they were just trying to avoid having the standard imply that particular bug was fixed - it means that they were trying to avoid making a promise that some reasonable implementations of directories can't keep even if those implementations have no bugs.
Yes, if the game developers are willing to put in the effort necessary to make their game compile using GNUstep
...and the replacements on {fill in your non-OS X UN*X here} for any other Mac OS X-specific APIs used by the game.
Re:Remember when the Internet was like that.
on
Internet2 and You
·
· Score: 1
Before the world wide web, when the internet was mainly news groups, uucp and email (with pling addresses, because there was no dns for routing.
According to RFC 921, the host table was to be decommissioned in September 1984, although it notes that hadn't been done yet. I don't think they were off by much, however, so that was a long time before the WWW.
Or perhaps by "the internet" you meant the Matrix (Quarterman coined the term long before the movie...)? At that point, the ARPANET and Internet were mainly for academic institutions and large technology companies; most other organizations and individuals had UUCP connections for e-mail and netnews. In the late 1980's Internet connections started being offered to a wider set of users, but I think there was still a period between that point and the point at which consumer ISPs started appearing.
This is where internet2 is currently. It doesn't mean it will be in a couple of decades.
Or perhaps not, if, instead, Internet2 remains as a dedicated network and the technologies developed for it filter down to the mainstream Internet.
Actually having 64bit in the kernel does have massive advantages, from maintaining memory paging pools, tracking space, virtualization tracking, and this isn't even getting into the use of 64bit registers and other aspects that the OS can take advantage of.
I already mentioned the performance benefits in the post to which you were replying. Are there any functionality benefits, such that a 64-bit application on a 32-bit kernel simply can't do stuff that the same application could do on a 64-bit kernel? Yes, you can have bigger kernel memory pools with a 64-bit kernel address space, and can have more page tables etc. to back more physical memory, but do any current Macs have enough memory for that to matter? And what do you mean by "virtualization tracking"? (You clearly saying that you need a 64-bit kernel to run 64-bit OSes on virtual machines, as I do that all the time on my Core 2-based MacBook Pro with its boring old 32-bit kernel.)
Also the 64bit driver aspect is big, even things like HD controllers to chipsets, mainboard drivers, etc can benefit greatly from 64bit bandwidth. (Let alone Video like I mentioned before)
Presumably you're not referring to DMA transfers, as they can be 64-bit even on Boring Old 32-Bit kernels.
it is however very misleading to tell people they are the 'first 64bit OS'
Where did Apple say Leopard was the "first 64-bit OS", with no qualifications? They do describe it as "the first mainstream OS to completely and seamlessly support both 64-bit and 32-bit applications on the same platform, making use of all your existing devices" on the "UNIX" page, but that's a rather qualified statement - if "mainstream" refers to OSes that most people are likely to use, that arguably rules out what might have been one of the first, if not the first, 64-bit OS (Digital UNIX), and "making use of all your existing devices" presumably refers to third-party drivers.
I.e., that you can't call up menu items from the keyboard? (OS X's UI isn't completely mouse-driven; see, for example, the "Full keyboard access" item in the "Keyboard & Mouse" pane in System Preferences.)
Author doesn't realize Microsoft and IBM wrote most of the GUI and UI guidelines that OS X even uses today.
Leopard's idea of 64bit is providing a 64bit version of Cocoa for applicaiton development.
Leopard's idea of 64-bit is providing 64-bit versions of most frameworks and libraries for application development. The one big exception is Carbon, and, yes, that's a big exception, but it's not as if there's not much you can do in 64-bit mode (as was the case in Tiger).
Like Tiger there are a few OS level 64bit pieces for addressing more RAM than 32bit, but the majority of the OS kernel itself is 32bit still.
Yes, as I said in the posting to which you're replying. I also said, however, "64-bit userland code can talk to 32-bit kernel code just fine." There might be performance boosts from running in 64-bit mode in the kernel, but it's not as if you'd gain much in the way of application functionality, as opposed to application performance, from having a 64-bit kernel.
(Let alone OS X is still a hybrid 64bit OS, using 32bit code throughout the OS, unlike Vista x64)
Define "throughout the OS". In Leopard, almost all the libraries come in 32-bit and 64-bit forms; it's just the kernel and a lot of executables that come with the OS that are 32-bit only. 64-bit userland code can talk to 32-bit kernel code just fine.
Slashdot Mirror
No, there existed native development tools for pre-OS X Mac OS, e.g. Metrowerks' Code Warrior.
So are you talking about CLI and/or server apps, or are you talking about GUI apps?
If it's about CLI and/or server apps, what's not working quite right? I think a free Apple Developer Connection account will let you file bugs - and, if something UN*Xy doesn't work on OS X, there's a good chance that it could be considered a bug. (Unfortunately, if the bug is duped to another bug, you don't get any updates on the progress of the other bug.)
If it's about GUI apps, that's the one place where OS X is quite different from all other UN*Xes, for better and for worse. There is X11 for running X11 apps, although you'd probably have to download and install the toolkit you're using yourself. There's also Trolltech's^WNokia's Qt, which could hide at least some of the differences. If there are documentation issues, you might want to file bugs on them.
s/the iPhone 3G/iPhone OS 2.0/
It's a software feature, not a hardware feature.
No, it wouldn't.
Note that "owned by Verizon" apparently means "20.5% owned by Verizon"
Note also that the TELUS mobile Web service in question is WAP-based, so it's not direct access to the "real Internet"; a lot of sites might be unavailable because they don't offer WAP or because any Web-to-WAP gatewaying TELUS might be using can't handle them.
(BTW, is there any evidence that anybody named "Dylan Patten" has ever written anything, or is writing anything, for Time Magazine? And has he actually talked to the sources that the I Power site claims he has? And did those sources say what that site claims they do, or did they say something else that was misinterpreted?)
No.
The Xserver RAID - and the Promise RAID - are a bunch of disks in a shelf, plus a RAID controller and Fibre Channel interface; it provides mass storage (the disks), RAID (implemented by the RAID controller - presumably that's the "failsafe" to which you're referring), and an interface that lets host computers with a direct Fibre Channel connection, or computers on a SAN, access partitions on the device.
Xsan is software; it's a file system that plugs into the OS X VFS layer, providing to xnu the standard file system interface so that xnu system calls, and code using them, see a standard file system. It stores its data on storage on a SAN - which could be an Xserve RAID or a Promise RAID or an EMC box or a NetApp box or... - and other computers on the SAN, running Xsan or Quantum's StorNext cluster file system, can access the same file system at the same time. It doesn't provide mass storage, it uses mass storage on a SAN.
As the Xserve RAID was a RAID shelf, and Xsan is a SAN distributed file system, the Xserve RAID wasn't replaced by Xsan 2. It was replaced by third-party RAID subsystems. (Apple currently mentions systems from Promise, as per their server storage page.)
The sample comes from people giving their salary to glassdoor.com and, presumably, describing themselves as software engineers. TFA shows a comparison of salaries for "Software Engineer(s)", not for all employees.
Hillsborough. Not exactly typical engineer territory. The 2K-3K/month rent figure is closer to typical.
They're very high-level managers, I assume, given that they're paying USD 300,000/yr in rent. How big are the places they're renting?
You thought incorrectly. (I'm just listing the hardware group, as I'm assuming you're making that statement because most of the manufacturing is done in China, and are thus thinking of hardware engineering.)
Apple can't "go back" to something it never went away from. Tiger had limited support for 64-bit code, whether on PPC or x86, and Leopard had 64-bit versions of most of its userland libraries. The Snow Leopard page doesn't say much about what's being done other than "Snow Leopard extends the 64-bit technology in Mac OS X to support breakthrough amounts of RAM - up to a theoretical 16TB, or 500 times more than what is possible today."
Some of the PowerPC machines were 64-bit. The notebooks and the Mac mini were 32-bit.
And, to the extent that it's supported on Solaris, there's no guarantee that a binary statically linked in Solaris N will run correctly in Solaris N+1.
OS X's and Solaris's ABI's are defined in terms of calls to routines in dynamically-linked libraries, not in terms of system calls.
There may well be other UN*Xes that work the same way. I have the impression that's how Windows works, as well. This allows the implementation of routines in those dynamically-linked libraries to change, as long as the binary interface remains the same.
Well, for one thing, a depressingly large number of Web sites don't use it "properly", in the sense that a user of the site would probably mean. I fear it's probably being used "properly", in the sense that a crappy Web designer would mean or in the sense that whoever's paying the Web designer means (i.e., for all I know, some of those sites are designed to suck at getting useful information, as the purpose is to, for example, bamboozle you into buying a product, not to give you enough information to decide whether to buy the product or not or to decide which particular product to buy).
What browser is written in PHP? (Note: "browser" and "server" are two separate pieces of software. To lift a line from the original article, the server is like a sewage treatment plant - the average user should only notice it when something goes wrong. Unfortunately, we live in a world where your sewer line backs up several times a day. :-))
Yes, just as desktop publishing software enabled what Henry Spencer called "ransom-note typography", the Web has enabled the construction of huge numbers of crappily-designed Web sites (many of which are enabled by a not-quite-so-great plugin - one of the pieces of software mentioned in the original article, with a name that begins with the letter grade you'd like to give to a lot of the designers who use it, namely the grade for "fail", and ends with a verb describing what you'd like to do to said designers with a whip).
Most browsers don't. Did you mean "Web page editor" when you said "browser"?
Yes, such a disaster that most businesses and government organizations haven't bothered going online, and nobody's come up with any mechanism for searching the contents of Web sites.
The Web might be a disaster, but I, at least, still find it more convenient than the "lack of a Web" that we had before.
As that slide says, "Siblings, not identical twins", "Different personalities", and "Very different ISAs=> very different cores".
To be precise, it says "Multi-pass handling of special cases" and "Leverage millicode for complex operations"; that means "complex instructions trap to millicode", where "millicode" is similar to, for example, PALcode in Alpha processors - it's z/Architecture machine code plus some special millicode-mode-only instructions to, for example, manipulate internal status registers. See, for example, "Millicode in an IBM zSeries processor".
It's clear that, as the the third slide says, the Z6 "share[s] lots of DNA" with the Power6, i.e. it shares the fab technology, some low-level "design building blocks", large portions of some functional units, the pipeline design style, and many of the designers.
It's not at all clear, however, that it would belong to a family with "Power" in its name, given that it does not implement the Power ISA. If it's a sibling of the Power6, that makes it, in a sense, a member of a family that includes the Power6, but, given that its native instruction set is different from the Power instruction set, it makes no sense to give that family a name such as "Power6" or anything else involving "Power" - and it certainly makes no sense to assert that it's "sed on the POWER archictecture", as the person to whom I was responding asserted.
Mac Pros and top-of-the-line iMacs, as per the iMac technical specifications.
Not according to an IBM slide presentation on the Z6 microprocessor, which is the latest processor for the z/Architecture machines (the machines that are descendants of the System/360 mainframes).
The AS/400^WiSeries^WSystem i midrange machines do use PowerPC processors, but they're different from the z/Architecture machines.
Yes.
People were aware that the notion of a directory being a sequence of entries, with each entry having a position such that you can get the position of an entry and later seek to that position and have the next read return that entry even if changes were made to the directory in the interim, was wrong.
That doesn't mean that they were just trying to avoid having the standard imply that particular bug was fixed - it means that they were trying to avoid making a promise that some reasonable implementations of directories can't keep even if those implementations have no bugs.
...and the replacements on {fill in your non-OS X UN*X here} for any other Mac OS X-specific APIs used by the game.
According to RFC 921, the host table was to be decommissioned in September 1984, although it notes that hadn't been done yet. I don't think they were off by much, however, so that was a long time before the WWW.
Or perhaps by "the internet" you meant the Matrix (Quarterman coined the term long before the movie...)? At that point, the ARPANET and Internet were mainly for academic institutions and large technology companies; most other organizations and individuals had UUCP connections for e-mail and netnews. In the late 1980's Internet connections started being offered to a wider set of users, but I think there was still a period between that point and the point at which consumer ISPs started appearing.
Or perhaps not, if, instead, Internet2 remains as a dedicated network and the technologies developed for it filter down to the mainstream Internet.
I already mentioned the performance benefits in the post to which you were replying. Are there any functionality benefits, such that a 64-bit application on a 32-bit kernel simply can't do stuff that the same application could do on a 64-bit kernel? Yes, you can have bigger kernel memory pools with a 64-bit kernel address space, and can have more page tables etc. to back more physical memory, but do any current Macs have enough memory for that to matter? And what do you mean by "virtualization tracking"? (You clearly saying that you need a 64-bit kernel to run 64-bit OSes on virtual machines, as I do that all the time on my Core 2-based MacBook Pro with its boring old 32-bit kernel.)
Presumably you're not referring to DMA transfers, as they can be 64-bit even on Boring Old 32-Bit kernels.
Where did Apple say Leopard was the "first 64-bit OS", with no qualifications? They do describe it as "the first mainstream OS to completely and seamlessly support both 64-bit and 32-bit applications on the same platform, making use of all your existing devices" on the "UNIX" page, but that's a rather qualified statement - if "mainstream" refers to OSes that most people are likely to use, that arguably rules out what might have been one of the first, if not the first, 64-bit OS (Digital UNIX), and "making use of all your existing devices" presumably refers to third-party drivers.
I.e., that you can't call up menu items from the keyboard? (OS X's UI isn't completely mouse-driven; see, for example, the "Full keyboard access" item in the "Keyboard & Mouse" pane in System Preferences.)
What part of the Apple Human Interface Guidelines come from the CUA Basic Interface Design Guide and other Microsoft and/or IBM guidelines without Microsoft and/or IBM having, in turn, gotten them from earlier Macintosh guidelines?
Leopard's idea of 64-bit is providing 64-bit versions of most frameworks and libraries for application development. The one big exception is Carbon, and, yes, that's a big exception, but it's not as if there's not much you can do in 64-bit mode (as was the case in Tiger).
Yes, as I said in the posting to which you're replying. I also said, however, "64-bit userland code can talk to 32-bit kernel code just fine." There might be performance boosts from running in 64-bit mode in the kernel, but it's not as if you'd gain much in the way of application functionality, as opposed to application performance, from having a 64-bit kernel.
Define "throughout the OS". In Leopard, almost all the libraries come in 32-bit and 64-bit forms; it's just the kernel and a lot of executables that come with the OS that are 32-bit only. 64-bit userland code can talk to 32-bit kernel code just fine.
-1, Redundant (and the original was better).