Slashdot Mirror


Apple's Unix Porting Guide

hysterion writes "Just came across the nice Unix Porting Guide (pdf) posted by Apple earlier this month. Topics include NetInfo, using Project Builder with gnumake, autoconf, XFree86, Tcl/Tk, Qt ... it is a bit short on scripting languages, and they speak as if KDE were already ported, but other than that I found it an informative read." They also didn't mention fink, and they put "Unix" in all caps. However, they were honest about the shell scripting limitations of AppleScript, although they didn't mention that AppleScript -- especially via osascript -- is pretty buggy in Mac OS X right now (this is my annoyance of the week, so allow me to indulge myself).

27 comments

  1. "As if KDE was already ported"? by Anonymous Coward · · Score: 3, Informative
    1. Re:"As if KDE was already ported"? by Ranger+Rick · · Score: 4, Informative

      Yeah, it's not 100% but we've got things mostly working. I've got screenshots (including KDE in rootless mode, very nice =) up at my web page.

      --

      WWJD? JWRTFM!!!

    2. Re:"As if KDE was already ported"? by jeffehobbs · · Score: 3, Insightful

      Aaaah! My eyes! The goggles, they do nothing!

      I'm sorry, but compared to OS X, KDE is just soooo ugly and out of place. I appreciate that there might... possibly... be... functionality one could get with KDE ported apps, but X11-based apps still look like they took second place in an ugly contest.

      ~jeff

  2. Of course they do by Clue4All · · Score: 3, Informative

    The operating system is UNIX, not Unix, though admittedly at this point it's more of a paradigm than an OS.

    --

    Is your browser retarded?
    1. Re:Of course they do by Anonymous Coward · · Score: 0

      I believe you're correct. Also see what is UNIX?

    2. Re:Of course they do by Da+Schmiz · · Score: 2
      The AC's right: the trademark is spelled in all caps. But see the Jargon File:
      Some people are confused over whether this word is appropriately `UNIX' or `Unix'; both forms are common, and used interchangeably. Dennis Ritchie says that the `UNIX' spelling originally happened in CACM's 1974 paper "The UNIX Time-Sharing System" because "we had a new typesetter and troff had just been invented and we were intoxicated by being able to produce small caps." Later, dmr tried to get the spelling changed to `Unix' in a couple of Bell Labs papers, on the grounds that the word is not acronymic. He failed, and eventually (his words) "wimped out" on the issue. So, while the trademark today is `UNIX', both capitalizations are grounded in ancient usage; the Jargon File uses `Unix' in deference to dmr's wishes.
      --

      "Anything is better than IE, and you can quote me on that." -- Wil Wheaton.

    3. Re:Of course they do by Lars+T. · · Score: 2

      That is somewhat silly, since Unix originally was called UNICS, which was a take on MULTICS, which was an acronym. So the only reason to declare Unix a "word" as opposed to an acronym is that Ritchie became more serious with the project.

      --

      Lars T.

      To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

  3. A Good "Where-To", "What's That" Guide by Spencerian · · Score: 2, Interesting

    I'm not a developer, but this appears to have answered a great many questions for those developers teetering on the edge of Mac OS X development. My primary questions were answered pretty well from this document.

    The nice thing about this document is how it tacitly implies that writing an OS X app can be done in such a way that it can be deployed just about anywhere with practically any imaging model and with many new or common IDEs. OS X, from a programmer's perspective, must seem extremely flexible.

    --
    Vos teneo officium eram periculosus ut vos recipero is.
  4. Java porting guide by pmorelli · · Score: 4, Informative

    Here's a link on porting Java apps to Mac OS X, eg, menu bar issues, tweaks that don't break cross-platform compatibility but help the Mac experience. Pretty good.

  5. Re:Deeply Disappointed in the Apple McIntosh by Anonymous Coward · · Score: 0

    I saw no references to eggs in that post.

  6. Re:Deeply Disappointed in the Apple McIntosh by Anonymous Coward · · Score: 0

    Good luck compiling all that "linux code" on XP...jackass...

  7. Re:Deeply Disappointed in the Apple McIntosh by dtfarmer · · Score: 2, Insightful

    Good luck compiling all that "linux code" on XP...jackass...

    It's too bad some people don't have a sense of humor, can't laugh at themselves - I found the parent post to be sarcastically funny - it's obviously not a true story - and it's actually a pretty good troll....

  8. Re:Deeply Disappointed in the Apple McIntosh by Anonymous Coward · · Score: 0

    I've seen better attempts at trolling made by kindergarteners calling one another "poopy pants" in an attempt to get a rise out of someone.

  9. Re:Deeply Disappointed in the Apple McIntosh by Steve+Cowan · · Score: 3, Funny

    You forgot to mention the ADB caps lock key issue!

  10. As for Fink.... by zhiwenchong · · Score: 3, Informative

    This is from Fink's FAQ:

    Q2.3: What is your relation with Apple?
    A: Apple is aware of Fink and has given us some support as part of their Open Source relations efforts. In the summer and fall of 2001, they provided us with pre-release seeds of new Mac OS X versions in the hope that Fink packages can be adapted in time for the release. Quote: "Hopefully it underscores the commitment that many suspect we're not willing to provide. We'll get better at the open source game over time." Thanks Apple!

  11. KDE + Darwin? by feldsteins · · Score: 3, Interesting

    I had no idea that this had occured. It's exciting!

    I'm given to wonder, however, why someone with a full OS X installation would wish to use KDE. Perhaps there are a dozen reasons I can't think off off-hand, but the real prize would be to run KDE on top of Darwin! Is this possible yet?

    Darwin core + good GUI = another no-cost operating system on the loose. It would no doubt have far lower system requirements than OS X, too. The idea has me drooling already.

    --
    You like your Macintosh better than me, don't you Dave? Dave? Can you hear me Dave?
    1. Re:KDE + Darwin? by Ranger+Rick · · Score: 4, Informative

      Yes it is possible, one of the other guys on our porting team has gotten it running, we're now working on incorporating those bits so it's reproducable. :)

      That's one of the reasons we moved things over to OpenDarwin rather than keeping it just in Fink, is so the Darwin folks can take advantage of it as well...

      --

      WWJD? JWRTFM!!!

  12. Interactive Terminal Support for Applescript by Anonymous Coward · · Score: 2, Interesting

    is what they need. If you run a task that takes ~5-10 minutes to complete (update prebindings) your applescript will stall for that long of time. Trying to "backround" it by putting a & at the end doesnt help ether, still waits for the prossess to finnish. I'd be really nice if i could have a little applescript studio application work interactvly with huge perl programs i've already written.

    BTW: if anyone knows how to do this feel free to tell me :) bfc@mac.com

  13. Re:Deeply Disappointed in the Apple McIntosh by Anonymous Coward · · Score: 0

    Good luck compiling all that "linux code" on XP...jackass...

    Actually open source code usually compiles and runs well under WinNT. Very little open source code is linux specific.

  14. OSAScript ickiness by dr00g911 · · Score: 2, Informative

    OSAscript is pretty darned cool, but it's been my annoyance of the week as well. Been playing with it the past couple of days to write a nice-looking iTunes remote for our office jukebox -- controlled via a browser, not the shell (doing it from the shell is cake, even on remote machines.)

    As Pudge mentioned, it's VERY buggy though. A few things I've noticed:

    • For remote scripting, you've gotta hard-code user names and passwords into the script that's getting executed. They don't get saved in the keychain like you're led to believe... documentation is very light, but eppc://user:pass@192.168.1.1 works. Beats typing in a user name and password repeatedly (possibly on multiple machines) even if it's an ugly and non-portable solution.
    • You can't natively launch commands via a passthru(), system() or shell_exec() command through Apache, even if they're in an external, pre-compiled .acgi or Perl file. Fortunately, I stumbled upon ACGI Dispatcher tonight (after 3 days on and off trying to control iTunes and Photoshop through apache, getting condition expected errors like mad, when the same commands work fine from the shell). Dispatcher allows you to do all of that stuff easily, and includes a iTunes remote CGI (D'oh!). Hopefully Apple will add in some provisions to facilitate OSAScript more robustly, as I'd like to stick to PHP/Perl for the heavy lifting on this stuff, and automating Photoshop (a stock photographer's back-end is one of my gigs right now) via PHP one-liners triggering 'Shop actions would absolutely rule. GDLib and Imagemagick are cool and all, but... the image quality difference on imageresample (even bicubic) and a Photoshop image size command can't even be compared when you've got people as picky about their images as photographers.
    1. Re:OSAScript ickiness by green+pizza · · Score: 1

      after 3 days on and off trying to control iTunes and Photoshop through apache...

      Egads!

    2. Re:OSAScript ickiness by pudge · · Score: 1
      Some notes:
      1. I did get it to save the password in the Keychain. But it would disappear after awhile.
      2. I could not even get it to work with hardcoded username/password. AEServer kept dying and leaving zombies behind, and I think osascript was trying to talk to zombies, because I kept getting authentication denied errors, even with a hardcoded username/password.

      My current method is to run a background AppleScript in my login session that dumps the data I need, once a minute, to a file in /tmp, and then my cron job reads from that data, instead of calling an AppleScript directly with osascript. This doesn't work for controlling anything, and it doesn't work for immediate access to data, but all I am doing with it is putting a "Now Playing" on my home page.

      If I had the time, I would port the Mac:: perl modules, including Mac::AppleEvents and friends, to Mac OS X. Though, I am not sure if a program that executes raw Apple events has similar limitations to osascript; that is, I don't know whether these limitations are built in to osascript, or are built in to the AppleScript software. So that solution might not help me anyway. I still wish I had the time to do it, though.

    3. Re:OSAScript ickiness by dr00g911 · · Score: 2, Informative

      I've got a way to do live data from iTunes instead of the cron task way... (I read about the cron job on MacOShints, and it seemed a bit of a kludge). It requires the ACGI dispatcher I mentioned earlier.

      Many thanks to a pile of people that wrote code for me to pick apart to get this working in my case...

      My method of grabbing info like that is:

      (from a PHP or Perl script):

      if ($cmd == "status")
      {
      $itunesreadout = virtual('/cgi-bin/itunesstatus.acgi');
      }

      Then in the itunesstatus applescript:

      tell application "iTunes" of machine "eppc://user:pass@itunes.yourplace.com"
      set ThePlayerState = player state as string

      [do state checking, decide what to do if it's not playing]

      set ThisTrack to current track
      set TrackName to name of ThisTrack
      set TrackArtist to artist of ThisTrack
      set TrackAlbum to album of ThisTrack
      set TrackLength to time of ThisTrack
      set Length to duration of ThisTrack
      set Position to player position

      set ReturnInfo to "iTunes currently playing: " & TrackArtist & TrackName & " whatever else you want to include"

      return ReturnInfo

      end tell

      This stuff is from memory, but the process and flow are up and running on our network at the office.

      The first time it runs, it'll be a bit slow, but should return info instantly afterward