I have my satellite internet through a group called SkyCasters (http://skycasters.com), since they explicitly say they support non-windows platforms (Mac OS X in particular for me). I have a DW4020 stack - transmit unit, receive unit, and a simple cisco switch on my network. I just point my machines to it for routing. Support with them has been pretty good, even though if you're having problems with internet software (like IRC or AIM), they won't help you. I've never had more than a 5 minute wait when calling support. They're geared to supporting the business customer rather than the end-user PC rabble.
I haven't experienced any of the problems folks here have mentioned, like download throttling. I get the same download speeds at any time during the day, no matter how much I've downloaded up to that point. Connectivity tends to be pretty good. High-overcast days are the worst, since apparently that bounces around the transmit signal. Rainy days and snowy days generally aren't a problem (as long as I keep the dish swept off when it snows)
The latency sucks, of course. It's still overall faster than the dialup and ISDN I used to have (which the satellite has replaced). Once the data starts flowing, its great. Forget about online games, and ssh is hugely frustrating for more than a couple of minutes. I end up doing a lot of work locally, then uploading the results, rather than doing the work directly on the remote box.
Probably not. The actual cocoa / objective C stuff handled tends to be OS X specific (the rendezvous classes, AppKit stuff like threads and drawing, CFRunloop). The lower-level unix stuff (files, threads, sockets, libraries, CVS, gdb, etc) are useful across unix variants.
Indeed it is. We also used CVS to collaborate on the sgml files and the makefiles to drive the DocBook->PDF toolchain. I used emacs for my chapters, and Aaron used an in-house tool called DocBooker. The early version of DocBooker is presented in Aaron's Cocoa Programming for Mac OS X book. Many illustrations where done with OmniGraffle.
From what I saw at WWDC, only a couple minor points here and there will need to be updated (like the new exception mechanism in objective-C replacing the setjmp/longjmp one that currently exists). The tech addressed by this book is more at the plumbing level which doesn't change a whole lot release to release. We don't dwell a lot on the IDE, figuring that folks will know what they're doing in their IDE of choice. (I personally use emacs for my day-to-day work)
I spent several years fixing other programmer's problems in a multi-threaded webserver in a very high traffic shop. We supported all sorts of unixes (HP-UX, Irix, Linux, Solaris), and by far my favorite platform for diagnosing and fixing problems was Digital Unix (I don't know what Compaq calls it these days) and their tool ladebug. They also have a tool for monitoring threaded control structures (mutexes et al) and could sometimes detect race conditions and potential race conditions. very cool.
"Strategic Advisor" is AOL-speak for "put out to pasture", like many AOL old-timers that haven't been able to keep up with the technology but have enough political connections to stick around.
actually, "fastpath" has always been there - just not publically referred to that name until now. (the source file, fastpath.c, was called that because it was a highly optimized path for serving static pages.)
...seeing as how thumbadextrous the instrument is (9 keys for the left thumb, 4 or 5 for the right)
My experience wasn't quite so good
on
Quickies a go-go
·
· Score: 1
I'm not too surprised at the difference. Open Sources is a book of essays of people's opinions, not necessarily of the facts:-) While I'd expect a technical editor to be able to thoughtfully correct and proofread I/O stream architecture, I'd imagine they wouldn't have a lot to offer to opinion essays.
Slashdot Mirror
I haven't experienced any of the problems folks here have mentioned, like download throttling. I get the same download speeds at any time during the day, no matter how much I've downloaded up to that point. Connectivity tends to be pretty good. High-overcast days are the worst, since apparently that bounces around the transmit signal. Rainy days and snowy days generally aren't a problem (as long as I keep the dish swept off when it snows)
The latency sucks, of course. It's still overall faster than the dialup and ISDN I used to have (which the satellite has replaced). Once the data starts flowing, its great. Forget about online games, and ssh is hugely frustrating for more than a couple of minutes. I end up doing a lot of work locally, then uploading the results, rather than doing the work directly on the remote box.
Probably not. The actual cocoa / objective C stuff handled tends to be OS X specific (the rendezvous classes, AppKit stuff like threads and drawing, CFRunloop). The lower-level unix stuff (files, threads, sockets, libraries, CVS, gdb, etc) are useful across unix variants.
Indeed it is. We also used CVS to collaborate on the sgml files and the makefiles to drive the DocBook->PDF toolchain. I used emacs for my chapters, and Aaron used an in-house tool called DocBooker. The early version of DocBooker is presented in Aaron's Cocoa Programming for Mac OS X book. Many illustrations where done with OmniGraffle.
From what I saw at WWDC, only a couple minor points here and there will need to be updated (like the new exception mechanism in objective-C replacing the setjmp/longjmp one that currently exists). The tech addressed by this book is more at the plumbing level which doesn't change a whole lot release to release. We don't dwell a lot on the IDE, figuring that folks will know what they're doing in their IDE of choice. (I personally use emacs for my day-to-day work)
The Keychain API shown in the book is the Security Framework version (SecKeychain*)
I spent several years fixing other programmer's problems in a multi-threaded webserver in a very high traffic shop. We supported all sorts of unixes (HP-UX, Irix, Linux, Solaris), and by far my favorite platform for diagnosing and fixing problems was Digital Unix (I don't know what Compaq calls it these days) and their tool ladebug. They also have a tool for monitoring threaded control structures (mutexes et al) and could sometimes detect race conditions and potential race conditions. very cool.
"Strategic Advisor" is AOL-speak for "put out to pasture", like many AOL old-timers that haven't been able to keep up with the technology but have enough political connections to stick around.
AOLserver handles about 28,000 web hits a second (many of them database-backed)
actually, "fastpath" has always been there - just not publically referred to that name until now. (the source file, fastpath.c, was called that because it was a highly optimized path for serving static pages.)
Yeah, those requirements are pretty out-to-lunch. That hi-res trailer was silky-smooth on an old G3/266 beigeMac and a 233 mhz powerbook.
The ABZ book is awesome. It's a gift I give to all my friends who are parents-to-be.
...seeing as how thumbadextrous the instrument is (9 keys for the left thumb, 4 or 5 for the right)
I'm not too surprised at the difference. Open Sources is a book of essays of people's opinions, not necessarily of the facts :-) While I'd expect a technical editor to be able to thoughtfully correct and proofread I/O stream architecture, I'd imagine they wouldn't have a lot to offer to opinion essays.
AOLserver (the freely available web server) has been available on Linux for a couple of years now.