OSX has been compiled for x86. Apple apparently keeps a x86 branch going. I suspect that was originally just in case IBM dropped the ball on the G5 chips. But while the G5 chips aren't quite as fast as Mac zealots were hoping, they definitely are competitive with x86 offerings. And IBM's now released compilers will definitely help matters and shows IBM's commitment. (Although to be fair Motorola is releasing Codewarrior 9 soon and more main applications are developed in CW than gcc)
I should add that Darwin is available for x86. I'm not sure why someone would use it since Linux and FreeBSD are far more mature. But it is there. It is basically OSX minus all the Aqua stuff. (i.e. the stuff most people love about OSX)
As for the reason Apple won't release a x86 version of OSX, that's been discussed extensively. All the existing OSX and Sys9 software wouldn't run. You could write an emulator but it would be dog slow since going PPC -> x86 is much harder than the opposite for various reasons (registers, chip tricks, etc.) Also all the optimizations for existing Apple hardware wouldn't work. Most significantly Apple is a hardware company and there is no sign they want clones. So even if they did go x86 it would still be in closed proprietary systems.
However Applescript is different. REXX is a more general scripting language that has, over time, become more like Javascript or the like, but which has a Fortan/Basic like syntax. (At least in my opinion. Others may disagree). Applescript makes use of dictionaries each application provides which provides objects and actions on objects. So it is intrinsically object oriented even if its syntax doesn't make good use of it. (The language syntax itself sucks, IMO, but the idea is so fantastic that it makes up for the language's limitations)
So iTunes has selections, playlists and other objects each with various attributes. It has actions you can do with and to these objects. You ought to google for some examples. Until you see what you can do with it, especially when combining applications, you just don't understand. The simplest way to think about it is the old idea of Unix of small programs that work together. Now conceive of all applications defining objects which can be utilized with that kind of mindset. All applications from word processors to graphics programs to spreadsheets to MP3 players to calendars. It really is quite amazing.
The only limitation is that a few applications are half-hearted in support. (Mainly a few Adobe Apps and Apple's own mail program) Apple also hasn't evangelized it quite enough.
Just to add to the above, if you use MacPython, they you do get more Applescript-like functionality. i.e. for controlling other Applications. There is some confusion on this since Apple supports the standard Python. MacPython, while using the same language, is technically a different beast. A lot of the language extensions work in MacPython but not the command line Python (and not the variant Python that you may have installed with Fink). Confusing? Yes. But MacPython includes a nice IDE so is useful for many reasons anyway.
Python and Perl are great, but you end up typically just embedding Applescripts in them. You can create objects for some AppleEvents, but you then end up writing modules for the Applications you script. It can be done but rarely is worth the effort.
Javascript, as the parent post mentioned, would be great. Unfortunately it doesn't really work well as a OSA in practice. Especially when trying to get objects in other Applications. (Perhaps other peoples milage varies - but I was excited about the Javascript OSA when I found it but found in practice that it wasn't that useful) If Apple made Javascript OSA a full player then I think we'd be more productive. And of course both Acrobat and Safari make extensive use of Javascript.
Of course given the resources at Apple I don't expect it to happen. As I mentioned elsewhere, they haven't even added recordability to their applications and many applications have a very limited object model.
Still one can't say Applescript is the ugly stepsister at Apple. The Applescript GUIscripting extensions from last year are very powerful. Likewise Applescript Studio, while limited, is one of those hidden gems most people don't realize.
When done right Applescript can really extend an Application's power. iTunes is the obvious example. It's probably my most scripted application. Here's a great resource for scripts:
Even better are putting icons in your Finder window for common actions. This is a little known feature that Apple provides that really makes the Finder more powerful.
In addition to Safari, Camino, IE, Mozilla, and then a few other smaller projects, there are also all the X11 browsers that Fink installs. Beyond Lynx as someone else mentioned we have the X11 Mozilla, Dillo, Konquerer and many others.
Dillo in particular is amazingly fast basic browser that supports graphics unlike Lynx. Even Mozilla running under X11 is surprisingly fast. Must faster than any Aqua based browser I've used. (Mainly due to no AA and other such considerations)
I use Safari 99% of the time because I like all those Aqua frills and because I think its tab handling is the best on the market. But one shouldn't neglect the rest.
Actually the syntax of Applescript is its greatest weakness. It is one of those "incredibly easy to read, a pain to write" languages. This was less of an issue back when most applications were recordable. You'd hit record and it would generate an Applescript to do what you just did. Then you could modify it. Right now though only a small handful of Applications support recordability and none of them are the main productivity applications. So it is sadly of little use.
Applescript is an application scripting language. I sure there is YACC/LEX code floating around for the language. So in theory it wouldn't be that hard to port.
Python, Perl and to a lesser extent Javascript aren't designed for this. (I say lesser extent Javascript, since there actually is a version of Javascript that compiles to the same format Applescript uses and works in the same way)
I agree that in general one would be better off using an other scripting language. But Applescript is useful -- especially for small tasks. (I think the majority of my scripts are less than 25 lines long)
I've not tried using the more robust OSA features in Python. Ususally I just call applescripts. I plan on doing more of this during the upcoming weeks.
Unfortunately as I alluded in my other post, Applescript Studio doesn't really support OSA languages other than Applescript. (OSA is from a programmer's perspective something like the VM for Java - it lets you use other languages)
I 100% agree that having a good general scripting book for OSX would be a great idea. It would have to be very practical. Here's hoping.
Bochs would be way too slow. Virtual PC does a lot of things to get even the speed it does. The reason it doesn't work on the G5 is because it was the sole program to use a little known feature of PPC chips to help it emulate x86 code. (Basically dealing with endian issues - the x86 and PPC store their numbers in different ways) This feature was dropped by IBM with the G5.
Writing an emulator is a non-obvious problem if you want reasonable performance.
I wonder if Apple would be wise to adopt Sun's SunPCi PC-on-a-PCI-card strategy.
Apple actually did this at one time. They had a DOS card I believe for one of the Quadra models. (I think it was an early 486)
Today though I don't think that would be too wise a move. After all Apple wants people to port software. If people can run the software without the port, then Apple loses. Also one can effectively do this right now through the ethernet card using Microsoft's remote PC services. I have an old PIII I'm using as a server which I control from my Mac when I need the occasional PC program.
Anyone who would ever have a reason to type "export PATH=foo" would not be confused that easily...
That's not entirely true. Some applications require these sorts of things. (I think Maple might, for instance) A lot of people want to run the application without necessarily knowing anything about Unix.
Further there are lots of tips on doing things in OSX that people type in without understanding. I know that seems alien to the Unix mindset. But regular users want results, not understanding. There are numerous hints in OSXHints that do this.
Debugging is hardly mentioned (3/4 of one lesson), and debugging is not exactly trivial in AppleScript. I also found no mention of my pet demon with AppleScript; its incredibly strong typing and problems with having data in the wrong type; this is a classic problem with files and file names. In reality, this book teaches you the language without really getting down to teach you how to program in the language.
This is a very damning problem. One could argue that the O'Reilly book was primarily a reference book. (A reference book dealing primarily with Sys9 and with only a few bits about 10.0 OSX features) But learning Applescript really ought to deal with how to code Applescript.
It is sad that there are not really good books on Applescript. While the language itself is pretty poor (IMO) the concept is excellent. Applescript Studio, while flawed, is a great tool. Most significant, with OSX, you can mix scripting languages to do very powerful things. i.e. most of my scripts are combination shell scrips and Applescripts. I also have a lot of Python/Applescripts. With Apple's GUIScripting additions to Applescript it is an amazingly powerful tool.
The only downside in Apple's toolkit are fairly weak scripting support in some important applications. (cough) Mail (cough). The other downside is debugging, which is surprisingly weak.
If I had a wish, it would be for something like Applescript studio, but with solid debugging and support for shell scripts, Applescripts, Perl scripts, Python scripts and maybe even TCL/TK. It would really be a killer feature for Unix types.
There were always a lot of questioning about whether they could legally even do what they were attempting to do. I believe they had sold the rights to the code some time earlier. That they could go from an old Sys8 era emulator to a OSX quality emulator in a few months seemed...too good to be true.
This is true. However Linux is considerably harder to setup and configure when you need to do anything out of the ordinary. As good as distros like Redhat are, you still often have to edit configuration files. Typically they are unnecessarily complex and easy to screwup, even with the purchase of an O'Reilly book for every service you configure. (Sendmail, Samba, etc.)
It is very easy to miss something and screw up security. I've seen this happen many times. The fact that things typically aren't straightforward in Linux means that many people think they are more secure than they are. Say what you will about Windows, but at least there people know it isn't secure unless they are careful. In Linux it is very easy to get a false sense of security. (And let's not even go into some of the horribly written CGI scripts that run in Linux - yeah poor administration, but easy to do)
Probably I'm posting too late to have anyone read this.
However on NPR the other day they had a fascinating interview with this engineer who was developing cheap, sustainable light sources for 3rd world nations. Effectively he has solar panels hooked up to LEDs. They don't burn out like incandescent ones do and use very little energy. Further they are focused such that the light is more useful.
He's apparently been developing these kits and then sending them to many regions of the world where people don't have light. If you think about it, a lot of studying and education take place in the off hours when you aren't working. In these places if it is dark, this limits how people can improve their condition. Thus this is a fantastic way to really affect quality of life in these places at very little cost.
Ideally these LED sources could provide sustainable light in many places, such as rest stops, with far less maintenance and the like. The "white" light LEDs have only been out a while but already are really revolutionizing a lot. When they go mainstream for regular lighting, then as the article points out, it will really be a very good thing. It'll be cheaper and use less energy. Already most cities are converting their traffic lights over.
I started using LEDs for light when the climbing lights from places like Black Diamond came out with them. Much superior to traditional head lamps. I knew then that it was just a matter of time. So I'd really encourage people to convert. The downside right now are adaptors and then nice cheap reading lamps at places like Walmart. But it is just a matter of time. (I hate how hot my reading lamps are - I'm always afraid of falling asleep and bumping them and causing a fire -- LEDs really avoid this problem. I'd buy them if they were readily available)
Units do matter if they aren't purely scalable. Kelvin is. Centigrade aren't. So if you have, say -10C and +20C then 20- -10 / -10 obviously is going to give the wrong number.
I have the same problem, but it is due to people mailing me dumb lists like "top 10 reasons beer is better than women" or other things that get forwarded by everyone to everyone else.
The next biggest problem is ads for viagra. Trust me, viagra is the worst sexually oriented virus there is. I'm pretty secure about not having to worry about HIV, Herpes or all the others. But viagra spam...
Take the key combos, for example. In every other Macintosh program holding the Command key and hitting the left or right arrow will take you to the start or end of the line. But in Word, this just takes you back or forward one word. Very annoying
You can change those though. I believe MS kept the same bindings, where possible, with the Windows version of Office. I should say I prefer this. Some things on the Mac are very frustrating. i.e. why on earth do Home and End take you to the beginning and end of the document rather than the line. Does anyone really use that?!?
Everyone I know uses AIM, simply because it got their first.
Funny. Everyone I know uses MSN IM for the same reason. I honestly don't know a single person who uses AIM. Which sucks as it means I've yet to use iChat on my Mac.
Right now Hotmail works fine. But there are lots of web sites that still only work under IE, which Microsoft doesn't support on the Mac much. (And the version out last week is the last)
More than likely the day will come when MS adds some custom feature that will require some ActiveX on the PC and some custom version browser on the Mac. Then you can use only their MSN browser (basically their next generation browser for the Mac - but it only runs if you subscribe to MSN)
While I like OSX a lot, I'm not sure I fully agree.
There is a lot of custom software for Windows that doesn't run under OSX. Yeah, that is more a "software" than "OSX" issue. But I think a lot of issues come down to that.
Further OSX supports far less hardware. Yes I know the reasons for it. But it is still true. I think Linux would do a lot more poorly were it only to run on Dells, for instance. So I do see that as an OS issue. For instance I complained about BeOS back in the early days for that reason. (Later versions ran on more hardware)
I'd also add that for all its problems with SPAM and viruses, Outlook still does many, many things that mail clients in OSX can't achieve.
Finally there are many business programs that don't run in OSX. Oracle is in beta, but there is no SAP, no DB Server, etc.
I think there are subtler reasons as well, such as development tools. But I'll not go into that..
There are some serious design differences as well that appear to only be getting more pronounced in Longarm as well. Windows is more task oriented. Macintosh ideally heads for a more "do things the way I want." In Windows you generally have tasks and go through a process. There are then wizards that help you with that. In comparison to both, Linux follows the workflow model more influenced by traditional Unix philosophy. There is a definite "programmer" mindset to the OS, even in KDE or Gnome. (Although Ximian is more Windows like and admittedly KDE has become more Windows-like)
Slashdot Mirror
No. Non-fanboys use the term "zealot." As in Maczealot or Maclot sometimes for short. There's also Winzealot and a whole bunch of other variations.
I should add that Darwin is available for x86. I'm not sure why someone would use it since Linux and FreeBSD are far more mature. But it is there. It is basically OSX minus all the Aqua stuff. (i.e. the stuff most people love about OSX)
As for the reason Apple won't release a x86 version of OSX, that's been discussed extensively. All the existing OSX and Sys9 software wouldn't run. You could write an emulator but it would be dog slow since going PPC -> x86 is much harder than the opposite for various reasons (registers, chip tricks, etc.) Also all the optimizations for existing Apple hardware wouldn't work. Most significantly Apple is a hardware company and there is no sign they want clones. So even if they did go x86 it would still be in closed proprietary systems.
Why is that lame? Consider the speed difference between letting the CPU handle it versus handling conversions yourself. It adds up.
Regina Rexx for OSX
However Applescript is different. REXX is a more general scripting language that has, over time, become more like Javascript or the like, but which has a Fortan/Basic like syntax. (At least in my opinion. Others may disagree). Applescript makes use of dictionaries each application provides which provides objects and actions on objects. So it is intrinsically object oriented even if its syntax doesn't make good use of it. (The language syntax itself sucks, IMO, but the idea is so fantastic that it makes up for the language's limitations)
So iTunes has selections, playlists and other objects each with various attributes. It has actions you can do with and to these objects. You ought to google for some examples. Until you see what you can do with it, especially when combining applications, you just don't understand. The simplest way to think about it is the old idea of Unix of small programs that work together. Now conceive of all applications defining objects which can be utilized with that kind of mindset. All applications from word processors to graphics programs to spreadsheets to MP3 players to calendars. It really is quite amazing.
The only limitation is that a few applications are half-hearted in support. (Mainly a few Adobe Apps and Apple's own mail program) Apple also hasn't evangelized it quite enough.
MacPython
Javascript, as the parent post mentioned, would be great. Unfortunately it doesn't really work well as a OSA in practice. Especially when trying to get objects in other Applications. (Perhaps other peoples milage varies - but I was excited about the Javascript OSA when I found it but found in practice that it wasn't that useful) If Apple made Javascript OSA a full player then I think we'd be more productive. And of course both Acrobat and Safari make extensive use of Javascript.
Of course given the resources at Apple I don't expect it to happen. As I mentioned elsewhere, they haven't even added recordability to their applications and many applications have a very limited object model.
Still one can't say Applescript is the ugly stepsister at Apple. The Applescript GUIscripting extensions from last year are very powerful. Likewise Applescript Studio, while limited, is one of those hidden gems most people don't realize.
When done right Applescript can really extend an Application's power. iTunes is the obvious example. It's probably my most scripted application. Here's a great resource for scripts:
Doug's Applescripts for iTunes
Even better are putting icons in your Finder window for common actions. This is a little known feature that Apple provides that really makes the Finder more powerful.Finder Toolbar Scripts
Dillo in particular is amazingly fast basic browser that supports graphics unlike Lynx. Even Mozilla running under X11 is surprisingly fast. Must faster than any Aqua based browser I've used. (Mainly due to no AA and other such considerations)
I use Safari 99% of the time because I like all those Aqua frills and because I think its tab handling is the best on the market. But one shouldn't neglect the rest.
Just allow remote access on your XP box and then type in its IP addres in RDC on the Mac.
Actually the syntax of Applescript is its greatest weakness. It is one of those "incredibly easy to read, a pain to write" languages. This was less of an issue back when most applications were recordable. You'd hit record and it would generate an Applescript to do what you just did. Then you could modify it. Right now though only a small handful of Applications support recordability and none of them are the main productivity applications. So it is sadly of little use.
Python, Perl and to a lesser extent Javascript aren't designed for this. (I say lesser extent Javascript, since there actually is a version of Javascript that compiles to the same format Applescript uses and works in the same way)
Javascript OSA
One must also point out that there are glue modules for Perl that allow it to do most Applescripting.
Applescript Module
Applescript Glue for Perl
I agree that in general one would be better off using an other scripting language. But Applescript is useful -- especially for small tasks. (I think the majority of my scripts are less than 25 lines long)
I've not tried using the more robust OSA features in Python. Ususally I just call applescripts. I plan on doing more of this during the upcoming weeks.
Python OSA Applescript
Unfortunately as I alluded in my other post, Applescript Studio doesn't really support OSA languages other than Applescript. (OSA is from a programmer's perspective something like the VM for Java - it lets you use other languages)
I 100% agree that having a good general scripting book for OSX would be a great idea. It would have to be very practical. Here's hoping.
Writing an emulator is a non-obvious problem if you want reasonable performance.
Apple actually did this at one time. They had a DOS card I believe for one of the Quadra models. (I think it was an early 486)
Today though I don't think that would be too wise a move. After all Apple wants people to port software. If people can run the software without the port, then Apple loses. Also one can effectively do this right now through the ethernet card using Microsoft's remote PC services. I have an old PIII I'm using as a server which I control from my Mac when I need the occasional PC program.
That's not entirely true. Some applications require these sorts of things. (I think Maple might, for instance) A lot of people want to run the application without necessarily knowing anything about Unix.
Further there are lots of tips on doing things in OSX that people type in without understanding. I know that seems alien to the Unix mindset. But regular users want results, not understanding. There are numerous hints in OSXHints that do this.
This is a very damning problem. One could argue that the O'Reilly book was primarily a reference book. (A reference book dealing primarily with Sys9 and with only a few bits about 10.0 OSX features) But learning Applescript really ought to deal with how to code Applescript.
It is sad that there are not really good books on Applescript. While the language itself is pretty poor (IMO) the concept is excellent. Applescript Studio, while flawed, is a great tool. Most significant, with OSX, you can mix scripting languages to do very powerful things. i.e. most of my scripts are combination shell scrips and Applescripts. I also have a lot of Python/Applescripts. With Apple's GUIScripting additions to Applescript it is an amazingly powerful tool.
The only downside in Apple's toolkit are fairly weak scripting support in some important applications. (cough) Mail (cough). The other downside is debugging, which is surprisingly weak.
If I had a wish, it would be for something like Applescript studio, but with solid debugging and support for shell scripts, Applescripts, Perl scripts, Python scripts and maybe even TCL/TK. It would really be a killer feature for Unix types.
There were always a lot of questioning about whether they could legally even do what they were attempting to do. I believe they had sold the rights to the code some time earlier. That they could go from an old Sys8 era emulator to a OSX quality emulator in a few months seemed...too good to be true.
On the other hand now all the OSX tip sites will be wrong for the same reasons: the assume tcsh rather than bash.
It is very easy to miss something and screw up security. I've seen this happen many times. The fact that things typically aren't straightforward in Linux means that many people think they are more secure than they are. Say what you will about Windows, but at least there people know it isn't secure unless they are careful. In Linux it is very easy to get a false sense of security. (And let's not even go into some of the horribly written CGI scripts that run in Linux - yeah poor administration, but easy to do)
However on NPR the other day they had a fascinating interview with this engineer who was developing cheap, sustainable light sources for 3rd world nations. Effectively he has solar panels hooked up to LEDs. They don't burn out like incandescent ones do and use very little energy. Further they are focused such that the light is more useful.
He's apparently been developing these kits and then sending them to many regions of the world where people don't have light. If you think about it, a lot of studying and education take place in the off hours when you aren't working. In these places if it is dark, this limits how people can improve their condition. Thus this is a fantastic way to really affect quality of life in these places at very little cost.
Ideally these LED sources could provide sustainable light in many places, such as rest stops, with far less maintenance and the like. The "white" light LEDs have only been out a while but already are really revolutionizing a lot. When they go mainstream for regular lighting, then as the article points out, it will really be a very good thing. It'll be cheaper and use less energy. Already most cities are converting their traffic lights over.
I started using LEDs for light when the climbing lights from places like Black Diamond came out with them. Much superior to traditional head lamps. I knew then that it was just a matter of time. So I'd really encourage people to convert. The downside right now are adaptors and then nice cheap reading lamps at places like Walmart. But it is just a matter of time. (I hate how hot my reading lamps are - I'm always afraid of falling asleep and bumping them and causing a fire -- LEDs really avoid this problem. I'd buy them if they were readily available)
Units do matter if they aren't purely scalable. Kelvin is. Centigrade aren't. So if you have, say -10C and +20C then 20- -10 / -10 obviously is going to give the wrong number.
The next biggest problem is ads for viagra. Trust me, viagra is the worst sexually oriented virus there is. I'm pretty secure about not having to worry about HIV, Herpes or all the others. But viagra spam...
You can change those though. I believe MS kept the same bindings, where possible, with the Windows version of Office. I should say I prefer this. Some things on the Mac are very frustrating. i.e. why on earth do Home and End take you to the beginning and end of the document rather than the line. Does anyone really use that?!?
Native KDE Info
Funny. Everyone I know uses MSN IM for the same reason. I honestly don't know a single person who uses AIM. Which sucks as it means I've yet to use iChat on my Mac.
More than likely the day will come when MS adds some custom feature that will require some ActiveX on the PC and some custom version browser on the Mac. Then you can use only their MSN browser (basically their next generation browser for the Mac - but it only runs if you subscribe to MSN)
There is a lot of custom software for Windows that doesn't run under OSX. Yeah, that is more a "software" than "OSX" issue. But I think a lot of issues come down to that.
Further OSX supports far less hardware. Yes I know the reasons for it. But it is still true. I think Linux would do a lot more poorly were it only to run on Dells, for instance. So I do see that as an OS issue. For instance I complained about BeOS back in the early days for that reason. (Later versions ran on more hardware)
I'd also add that for all its problems with SPAM and viruses, Outlook still does many, many things that mail clients in OSX can't achieve.
Finally there are many business programs that don't run in OSX. Oracle is in beta, but there is no SAP, no DB Server, etc.
I think there are subtler reasons as well, such as development tools. But I'll not go into that..
There are some serious design differences as well that appear to only be getting more pronounced in Longarm as well. Windows is more task oriented. Macintosh ideally heads for a more "do things the way I want." In Windows you generally have tasks and go through a process. There are then wizards that help you with that. In comparison to both, Linux follows the workflow model more influenced by traditional Unix philosophy. There is a definite "programmer" mindset to the OS, even in KDE or Gnome. (Although Ximian is more Windows like and admittedly KDE has become more Windows-like)