>>They won't let anyone else build Mac-compatible machines anymore.
Anyone can build a mac-compatible machine if they so desire... If they want to sell it with the OS however, they have to pay shelf prices and apple has no obligation to provide advance notice of hard ware changes that they (Apple) are making. >>They won't let anyone else sell Macs online unlessthe store arranges for customers who already own a Mac to setup a password/account/etc
The retailing control was a direct backlash against the absolutely *terrible* retail situation of a few years ago. The local "bit barn" would have three broken down quadras in the back and no one on payroll who could find the apple menu on screen. The result, a terrible image presented to consumers because the retailers were stuck in a winders mindframe. You think you're frustrated by the lack of Linux knowledge at the local CompUSA? Try buying a mac circa 97...
>>If they had their way, nobody but Apple owners would have been able to use a graphical interface. (Bogus lawsuits, copyrights, patents on GUIs)
They haven't initiated a GUI lawsuit in, uh, 14 years? Apple got a 2 hour tour of PARC, gave them a handsome number of pre-IPO shares (10 million I think..) and walked away with nothing more than an idea that PARC didn't want. MS got 4 fully working proto-Macs with source code so they could port their software, gave Apple no shares or money and 2 years later released a remarkably similar product. I'd have sued them too....
FireWire® - registering a trademarked name for an IEEE standard. Only they can use the name if they so choose!
Oh gosh you're right! I'm gonna run out an make my own Linux distro and call it Red Hat!
Actually, differentiating a Yikes!(Yosemite board, G4) from a Sawtooth is easy.
a) if it's 350 mhz it's a Yikes! b) if it's a 400 and there's only one firewire port it's a Yikes! c) All others are Sawtooth.
The whole point of the Yikes! config was to get a cheap G4 out the door. It was a stop gap measure. If you own one, I'd suggest painting it blue and telling everyone you have a "Yosemite SE"
There's a site called accelerateyourmac... you can find the link of www.macsurfer.com. They have benchmarks et al. Sure, MS Office runs faster on a Winders machine, but, really, is speed a big issue when you're word processing? Photoshop, on the other hand is insanely resource intensive. I remember in the (not so) good old days, putting off certain filter combos until lunch time. I haven't had to bring a magazine to work since I got the G4...
>Could you elaborate on what Applescript does better than Perl?
Well,first off, let's look at what exactly perl is on the mac. All mac-based scripting languages utilize the open scripting architecture (OSA, that's why AppleScript extentions are called OSAX) which in turn manipulates the raw event handler to make, read events. This includes both Perl and AppleScript (as well as Frontier, if you care...)
So the bottom line is that once you get past the syntax and command script, it's all the same stuff. I, for one, find Perl's syntax unnecesarily cryptic and it's command list not mac-centric enough for my work. So it's AppleScript.
The beutiful thing about AS, of course, is it's ability to manipulate server-side apps. I wrote a cgi in AS once that allowed student journalists to log on to a web site, fill out a form with a story, provide a picture (either by url or specifying the name of a ftp'd file), the script would then insert their text and photos in the alloted spaces in Quark, size the photos, set the headlines, deal with copy overruns and then, at a specified time, print the whole thing out in time for me to waltz into the office on Monday morning. I was the "hero" of the office... for a week anyway.
Of course there are bad things about AS. First, it is slow (but Perl's no faster). Native PPC has helped a lot, but an AS cgi can crawl if over used. OS X is really going to clean that up, Apple is promising a dramatic speed increase with OS X, so start saving carbonized versions of your scripts now!
The second problem is that, by nature, AS handles cgi on a FILO (first in last out) nature. This can be a serious drag if you have a heavily used cgi. Some unlucky users can get stuck in the queue and never get out! The solution to this is to develop with FaceSpan. They claim to support FIFO/LILO processing. A big imporvement. I honestly don't know where Perl stands on this.
Lastly, AS's biggest strength is OSAX. There's a gajillion (10 followed by a jillion zeros) OSAXen out there that allow you to write just about anything in AS you might want. Mango Tree offers an OSAX that let's you write a telnet client. There's even an HTTP server written in AppleScript. It's just a show-off really, but kinda cool.
If you're realy considering AS, I'd suggest perusing bbs.applescript.net They have a pretty exhaustive list of OSAX (80% free) and the bbs is mostly full of people who know what they're talking about.
------->Frymast
Moderate down for calling Perl "too cryptic". thanks.
I happen to know an actual honest-to-god "end user": my Dad.
My Dad is not a dumb guy and he's not afraid of technology (his VCR actually displays the correct time!) however his response to the open source concept is one of distrust...
His theory is: in the open market people are motivated to provide the best service/product possible by motivation to make money. People who are willing to give away their product are not motivated by profit. Therefore they are not motivated to develop the best product. The traditional car metaphor works well here. The tinkerer down the street may be a brilliant backyard mechanic and he may have a wicked, souped up Datsun that does 200mph and get 75 mpg... but my dad isn't going to buy a car from him. He's going to buy it from Ford because ford will give him power windows and ABS and lights on the mirror underneath the sunvisor. The backyard mechanic may make a better, more efficient, faster car but he doesn't include all those " extras". The tinkerer doesn't care about vanity mirror lights (he's a mechanic!) but my dad *does* care about them. So he'll buy Ford.
Okay, I admit it's a grand idea... but why have they specified a mandatory language if they insist that entries contain no code? I realize that ultimately, winning proposals will necessitate the writing of code... but since winners are chosen on functionality/interface and not on implementation details why does the language matter? A good flowchart should be equally applicable to all languages and the language should be chosen for reasons of pure implementation expediency.
Assembly GUI? I must admit I didn't crack open a copy of Inside Macintosh until 92 or 93, but pretty much the whole series is dedicated to the toolbox calls to build the gui, run the event loop, file i/o yatta yatta.... (and all the examples were in Pascal!) Furthermore, developing gui widgets was/is still mostly a matter of resource fork editing (with resedit, rez etc.) and while the naming an numbering conventions for resources was a bit byzantine it was almost RAD-like back then with actual point-n-click designing of windows... a big time saver. My biggest complaint was the event handling... when you get up to 900 lines for your even loop, you start to suspect something could be done better...
Well, if you want to compare NuBus to ISA, sure, I'd take a NuBus any day. The big difficulty was with Apple's absolutely *terrible* sense of timing on their hardware development path. They make the move from 68k to PPc and then, like, 18 months later move to PCI. From '94 to '96 it seemed that every piece of hardware I bough became obsolete before I got it out of the static bag. I think that qualifies as a "crappy decision"
Don't get me wrong: I'm not an "Apple Basher". I've got 4 macs at home (including one of the afformentioned LC630's) and I admin a network of 200 macs ranging from Quadra 610s to G4/450's. I like the hardware, I like the software... I just think that the "hardware revolution" of the mid-nineties was not as smooth as it could have been and it caused a lot of unneccessary (sp?) grief.
For the record, all x100 series PPC's are NuBus (ie, 6100, 7100, 8100) NuBus seemed like a good idea at the time, but in retrospect as one of those bad decisions that apple feels it needs to make to balance those good decisions... MkLinux will run on NuBus machines btw.
The important thing to note here, though, is that the 601e was really just a toe-wetter by AIM and when you get right down to it, it's performance vs. the MC68040 is nothing to email home about. You can get a comparable pre-PPC Mac with a 68040 for a lot less money and only a little less power.... Mind you, if Linux is your goal you'll be up the creek. The solution there is to move to Open BSD, which claims to support "all" the MC680x0 family of processors. That's a wee bit of a lie, though, since the MC680LC0 is not only unsupported but fully un-functional. You'll only find that chip in "higher end" LC macs (ie the LC630).
If you want the good on older Macs, you should check out lowendmac.com Don't trust me to get the URL right, that's what google is there for.
iCab is a German-made, mac-only, pay-for-it browser (a strange combination to be sure). The real feature of this browser, though, is it's "rate-HTML" function... a little happy/sad face in the top right corner that gives a detailed (and depressingly long) list of HTML "errors and warnings". If you thought you were writing lean mark-up (or though Dreamweaver was doing a good enough job with "just a little tweaking") this browser will scare the pants off of you.
BTW, the "preview" version is still free... and it doesn't do javascript.
Slashdot Mirror
Anyone can build a mac-compatible machine if they so desire... If they want to sell it with the OS however, they have to pay shelf prices and apple has no obligation to provide advance notice of hard ware changes that they (Apple) are making. >>They won't let anyone else sell Macs online unlessthe store arranges for customers who already own a Mac to setup a password/account/etc
The retailing control was a direct backlash against the absolutely *terrible* retail situation of a few years ago. The local "bit barn" would have three broken down quadras in the back and no one on payroll who could find the apple menu on screen. The result, a terrible image presented to consumers because the retailers were stuck in a winders mindframe. You think you're frustrated by the lack of Linux knowledge at the local CompUSA? Try buying a mac circa 97...
>>If they had their way, nobody but Apple owners would have been able to use a graphical interface. (Bogus lawsuits, copyrights, patents on GUIs)
They haven't initiated a GUI lawsuit in, uh, 14 years? Apple got a 2 hour tour of PARC, gave them a handsome number of pre-IPO shares (10 million I think..) and walked away with nothing more than an idea that PARC didn't want. MS got 4 fully working proto-Macs with source code so they could port their software, gave Apple no shares or money and 2 years later released a remarkably similar product. I'd have sued them too....
FireWire® - registering a trademarked name for an IEEE standard. Only they can use the name if they so choose!
Oh gosh you're right! I'm gonna run out an make my own Linux distro and call it Red Hat!
add Minix to the list...
a) if it's 350 mhz it's a Yikes!
b) if it's a 400 and there's only one firewire port it's a Yikes!
c) All others are Sawtooth.
The whole point of the Yikes! config was to get a cheap G4 out the door. It was a stop gap measure. If you own one, I'd suggest painting it blue and telling everyone you have a "Yosemite SE"
There's a site called accelerateyourmac... you can find the link of www.macsurfer.com. They have benchmarks et al. Sure, MS Office runs faster on a Winders machine, but, really, is speed a big issue when you're word processing? Photoshop, on the other hand is insanely resource intensive. I remember in the (not so) good old days, putting off certain filter combos until lunch time. I haven't had to bring a magazine to work since I got the G4...
Well,first off, let's look at what exactly perl is on the mac. All mac-based scripting languages utilize the open scripting architecture (OSA, that's why AppleScript extentions are called OSAX) which in turn manipulates the raw event handler to make, read events. This includes both Perl and AppleScript (as well as Frontier, if you care...)
So the bottom line is that once you get past the syntax and command script, it's all the same stuff. I, for one, find Perl's syntax unnecesarily cryptic and it's command list not mac-centric enough for my work. So it's AppleScript.
The beutiful thing about AS, of course, is it's ability to manipulate server-side apps. I wrote a cgi in AS once that allowed student journalists to log on to a web site, fill out a form with a story, provide a picture (either by url or specifying the name of a ftp'd file), the script would then insert their text and photos in the alloted spaces in Quark, size the photos, set the headlines, deal with copy overruns and then, at a specified time, print the whole thing out in time for me to waltz into the office on Monday morning. I was the "hero" of the office... for a week anyway.
Of course there are bad things about AS. First, it is slow (but Perl's no faster). Native PPC has helped a lot, but an AS cgi can crawl if over used. OS X is really going to clean that up, Apple is promising a dramatic speed increase with OS X, so start saving carbonized versions of your scripts now!
The second problem is that, by nature, AS handles cgi on a FILO (first in last out) nature. This can be a serious drag if you have a heavily used cgi. Some unlucky users can get stuck in the queue and never get out! The solution to this is to develop with FaceSpan. They claim to support FIFO/LILO processing. A big imporvement. I honestly don't know where Perl stands on this.
Lastly, AS's biggest strength is OSAX. There's a gajillion (10 followed by a jillion zeros) OSAXen out there that allow you to write just about anything in AS you might want. Mango Tree offers an OSAX that let's you write a telnet client. There's even an HTTP server written in AppleScript. It's just a show-off really, but kinda cool.
If you're realy considering AS, I'd suggest perusing bbs.applescript.net They have a pretty exhaustive list of OSAX (80% free) and the bbs is mostly full of people who know what they're talking about.
------->Frymast
Moderate down for calling Perl "too cryptic". thanks.
My Dad is not a dumb guy and he's not afraid of technology (his VCR actually displays the correct time!) however his response to the open source concept is one of distrust...
His theory is: in the open market people are motivated to provide the best service/product possible by motivation to make money. People who are willing to give away their product are not motivated by profit. Therefore they are not motivated to develop the best product. The traditional car metaphor works well here. The tinkerer down the street may be a brilliant backyard mechanic and he may have a wicked, souped up Datsun that does 200mph and get 75 mpg... but my dad isn't going to buy a car from him. He's going to buy it from Ford because ford will give him power windows and ABS and lights on the mirror underneath the sunvisor. The backyard mechanic may make a better, more efficient, faster car but he doesn't include all those " extras". The tinkerer doesn't care about vanity mirror lights (he's a mechanic!) but my dad *does* care about them. So he'll buy Ford.
and Microsoft.
Okay, I admit it's a grand idea... but why have they specified a mandatory language if they insist that entries contain no code? I realize that ultimately, winning proposals will necessitate the writing of code... but since winners are chosen on functionality/interface and not on implementation details why does the language matter? A good flowchart should be equally applicable to all languages and the language should be chosen for reasons of pure implementation expediency.
Assembly GUI? I must admit I didn't crack open a copy of Inside Macintosh until 92 or 93, but pretty much the whole series is dedicated to the toolbox calls to build the gui, run the event loop, file i/o yatta yatta.... (and all the examples were in Pascal!) Furthermore, developing gui widgets was/is still mostly a matter of resource fork editing (with resedit, rez etc.) and while the naming an numbering conventions for resources was a bit byzantine it was almost RAD-like back then with actual point-n-click designing of windows... a big time saver. My biggest complaint was the event handling... when you get up to 900 lines for your even loop, you start to suspect something could be done better...
Well, if you want to compare NuBus to ISA, sure, I'd take a NuBus any day. The big difficulty was with Apple's absolutely *terrible* sense of timing on their hardware development path. They make the move from 68k to PPc and then, like, 18 months later move to PCI. From '94 to '96 it seemed that every piece of hardware I bough became obsolete before I got it out of the static bag. I think that qualifies as a "crappy decision"
Don't get me wrong: I'm not an "Apple Basher". I've got 4 macs at home (including one of the afformentioned LC630's) and I admin a network of 200 macs ranging from Quadra 610s to G4/450's. I like the hardware, I like the software... I just think that the "hardware revolution" of the mid-nineties was not as smooth as it could have been and it caused a lot of unneccessary (sp?) grief.
For the record, all x100 series PPC's are NuBus (ie, 6100, 7100, 8100) NuBus seemed like a good idea at the time, but in retrospect as one of those bad decisions that apple feels it needs to make to balance those good decisions... MkLinux will run on NuBus machines btw.
The important thing to note here, though, is that the 601e was really just a toe-wetter by AIM and when you get right down to it, it's performance vs. the MC68040 is nothing to email home about. You can get a comparable pre-PPC Mac with a 68040 for a lot less money and only a little less power.... Mind you, if Linux is your goal you'll be up the creek. The solution there is to move to Open BSD, which claims to support "all" the MC680x0 family of processors. That's a wee bit of a lie, though, since the MC680LC0 is not only unsupported but fully un-functional. You'll only find that chip in "higher end" LC macs (ie the LC630).
If you want the good on older Macs, you should check out lowendmac.com Don't trust me to get the URL right, that's what google is there for.
iCab is a German-made, mac-only, pay-for-it browser (a strange combination to be sure). The real feature of this browser, though, is it's "rate-HTML" function... a little happy/sad face in the top right corner that gives a detailed (and depressingly long) list of HTML "errors and warnings". If you thought you were writing lean mark-up (or though Dreamweaver was doing a good enough job with "just a little tweaking") this browser will scare the pants off of you.
BTW, the "preview" version is still free... and it doesn't do javascript.