macosxhints - How to cleanly shut down when things go wrong
1. reboot
2. Kill coredservicesd
3. shutdown then reboot
Friday, September 10, 2004
Canon releases iP6000D and iP8500 PIXMA printers in the US
Canon USA Consumer Products - Printers
Figures. I gave up 2 days ago and ordered the IP4000. Now the iP6000D, iP5000, iP4000R and iP8500 are out. The iP6000D replaces the i960. It's a "six" (five really) color system. The ip8500 it's an "eight" (seven really) color system.
The product naming and sequencing is very confusing.
I think the iP6000D may be a "pure" photo printer, whereas the iP4000, iP4000R and iP5000 clearly print both photos and documents. The iP4000R has integrated 802.11G support, the iP5000 is faster than the rest. The best photos in this $140-$200 group come from the iP6000D. For our family purposes the iP4000 may suffice.
The iP8500 is in a different category. It exceeds the photo printing of the iP6000D while still doing document printing; and it's faster than the iP5000 for similar resolutions. It's also almost twice as much.
Maybe I won't return the iP4000 after all. It may be about right -- I can replace it with next October's models ...
Figures. I gave up 2 days ago and ordered the IP4000. Now the iP6000D, iP5000, iP4000R and iP8500 are out. The iP6000D replaces the i960. It's a "six" (five really) color system. The ip8500 it's an "eight" (seven really) color system.
The product naming and sequencing is very confusing.
I think the iP6000D may be a "pure" photo printer, whereas the iP4000, iP4000R and iP5000 clearly print both photos and documents. The iP4000R has integrated 802.11G support, the iP5000 is faster than the rest. The best photos in this $140-$200 group come from the iP6000D. For our family purposes the iP4000 may suffice.
The iP8500 is in a different category. It exceeds the photo printing of the iP6000D while still doing document printing; and it's faster than the iP5000 for similar resolutions. It's also almost twice as much.
Maybe I won't return the iP4000 after all. It may be about right -- I can replace it with next October's models ...
Gmail runs on Apple xServe boxes?
PBS | I, Cringely . Archived Column
Cute of Cringely to just toss that one out. Apple hasn't said anything about this. I think most folks assumed GMail ran on Intel/Linux boxes.
Gmail, itself, runs on Apple xServe 1u boxes.
Cute of Cringely to just toss that one out. Apple hasn't said anything about this. I think most folks assumed GMail ran on Intel/Linux boxes.
The beauty of Symlink and SymbolicLinker - OS X
SymbolicLinker
Now that I had my big external drive, the next step was to download and install the OS X development tools. Tons of utilities, documentation, AppleScript studio -- you name it.
So I try the install -- and discover it wants to install on my boot disk! Sigh. The original Mac didn't have these problems -- but OS X is more like Windows. Paths matter. Not all progress is linear. Losing the innate indirection design of Mac Classic is quite sad.
But the documentation mentioned "symlinks". This is a Unix thing, too "advanced" even for my O'Reilly OS X Unix book!
Symlinks come in two forms. One is like a Microsoft Windows shortcut/alias. That's a "soft link". Main limitation is it holds a hard coded path. Move the destination and it breaks. Just like Windows.
Other form is a "hard link". BAD. DANGEROUS. Stay away. Ask no more.
There is risk even to a softlink. Some non-Apple deletion tools get confused by a soft symlink and delete the originals. The trashcan knows better.
Symlinks are created via the terminal. It's probably not too hard, but SymbolicLinker 1.1 is freeware and is very safe and convenient. I downloaded and installed it. Lovely, thank you Nick.
So I moved the "Developer" folder I'd started with to my new external drive, and used SymbolicLikner to create a symlink. It created an item with the name "Developer symlink". I can't change the name. I moved it to my boot disk. Then I continued the install. Worked perfectly.
These look like handy ways to get around a number of odd things that require installation on the boot disk. Symlinks exist at the BSD level, so they're transparent to most Cocoa applications.
Now that I had my big external drive, the next step was to download and install the OS X development tools. Tons of utilities, documentation, AppleScript studio -- you name it.
So I try the install -- and discover it wants to install on my boot disk! Sigh. The original Mac didn't have these problems -- but OS X is more like Windows. Paths matter. Not all progress is linear. Losing the innate indirection design of Mac Classic is quite sad.
But the documentation mentioned "symlinks". This is a Unix thing, too "advanced" even for my O'Reilly OS X Unix book!
Symlinks come in two forms. One is like a Microsoft Windows shortcut/alias. That's a "soft link". Main limitation is it holds a hard coded path. Move the destination and it breaks. Just like Windows.
Other form is a "hard link". BAD. DANGEROUS. Stay away. Ask no more.
There is risk even to a softlink. Some non-Apple deletion tools get confused by a soft symlink and delete the originals. The trashcan knows better.
Symlinks are created via the terminal. It's probably not too hard, but SymbolicLinker 1.1 is freeware and is very safe and convenient. I downloaded and installed it. Lovely, thank you Nick.
So I moved the "Developer" folder I'd started with to my new external drive, and used SymbolicLikner to create a symlink. It created an item with the name "Developer symlink". I can't change the name. I moved it to my boot disk. Then I continued the install. Worked perfectly.
These look like handy ways to get around a number of odd things that require installation on the boot disk. Symlinks exist at the BSD level, so they're transparent to most Cocoa applications.
Thursday, September 09, 2004
Workplace OS. Pink. Taligent. Longhorn.
Scobleizer: Microsoft Geek Blogger
Workplace OS was IBM's fiasco. Pink was Apple's fiasco.Taligent was IBM AND Apple's fiasco. Longhorn is Microsoft's fiasco. Each of these projects was immensely complex, and each tried to tackle fundamental problems in the representation of data -- especially data about "people, places and things".
What's differnte about Longhorn is that it's also the first massive project to run ahead of Moore's Law. The graphics and WinFS layers assumed massive processing power -- the classic Microsoft approach to forcing hardware and software upgrades. The big mistake was assuming Moore's Law would continue to hold. Well, it's not holding when power availability is a constraining factor. Given sufficient power (one or more household outlets) one can handle the power needs and heat output (liquid cooling!) of a Longhorn system. Lacking a power cord, Longhorn won't fly.
Microsoft isn't going to just delay Longhorn for a year. Gates is going to kill it. They may claim to release "Longhorn" one day, but it will be a marketing illusion. They'll release WinXP SP3 and call it Longhorn.
If there's one thing Gates absolutely excels at, it's shooting a failing horse. He kills massive projects fast and efficiently, and without a shred of sentiment. It's a weird and unique talent. Don't be fooled by the internal Microsoft statements and the press releases. Unless Gates has undergone an unlikely transformation, Longhorn is utterly dead.
Want malware protection? Run Safari, OmniWeb, or Firefox on OS X. This is a nice get well gift for Steve Jobs.
As I, and other evangelists, showed off Longhorn to developers we kept hearing the same thing:
"This is cool."
"Oh, wait, it's Longhorn only?"
"Yep," I'd answer.
"Uh, call us after it ships and you get X marketshare." (X being a variable between 0% and 100%).
That's basically what Mozilla answered too, and they weren't alone.
Then there was Joel Spolsky's rant about how Microsoft was losing the API war. Out of all the developers who write blogs, his is the most influential in my mind -- one link from his blog recently sent 12,000 readers -- and his rant caused more conversations internally among the geeks (devs and testers) than anything I've seen written all year. I've been reading his new book this weekend, by the way, and it gives deep insights on Microsoft and software development and management culture.
Then there's the constant meetings with non-geek customers that I kept having. "Can you help me get my system back working? I keep getting these bizarre popups every few seconds..."
I got just that question again while traveling this weekend. Translation: non-geek customers are asking for better protection against malware, spyware, etc. They care about that a lot more than if they can do some cool new video or 3D trick on screen.
Another point of view? We were making the wrong bets based on where the industry is going. Sales of Tablet PCs has been going up lately. And notebooks are white hot.
One thing, what matters on Tablet PCs? Battery life, and low heat while giving decent performance. Now, what happens when you need a better graphics processor? Less battery life and more heat. Longhorn's Avalon was going to require a beefy graphic processor (look at all the demo machines, we barely could get the latest builds to run on a top-of-the-line Alienware machine).
Translation: Longhorn wasn't aimed at the sweet spot of the market anymore and our customers were telling us to go in a different direction.
Another point of view? Remember when a group of us tried to go off and build an app about two months ago with the product teams? That was a turning point for me. I saw that Avalon was pretty easy to work with (I even understood that). But WinFS was very difficult. Only the best teams actually got something done there. And we were working off of a script that basically told us where everything was.
That told me that WinFS needed more work. Plus, when I asked about certain scenarios (servers, networks, adding in weird devices, etc) the team didn't have strong answers that made me feel good...
Workplace OS was IBM's fiasco. Pink was Apple's fiasco.Taligent was IBM AND Apple's fiasco. Longhorn is Microsoft's fiasco. Each of these projects was immensely complex, and each tried to tackle fundamental problems in the representation of data -- especially data about "people, places and things".
What's differnte about Longhorn is that it's also the first massive project to run ahead of Moore's Law. The graphics and WinFS layers assumed massive processing power -- the classic Microsoft approach to forcing hardware and software upgrades. The big mistake was assuming Moore's Law would continue to hold. Well, it's not holding when power availability is a constraining factor. Given sufficient power (one or more household outlets) one can handle the power needs and heat output (liquid cooling!) of a Longhorn system. Lacking a power cord, Longhorn won't fly.
Microsoft isn't going to just delay Longhorn for a year. Gates is going to kill it. They may claim to release "Longhorn" one day, but it will be a marketing illusion. They'll release WinXP SP3 and call it Longhorn.
If there's one thing Gates absolutely excels at, it's shooting a failing horse. He kills massive projects fast and efficiently, and without a shred of sentiment. It's a weird and unique talent. Don't be fooled by the internal Microsoft statements and the press releases. Unless Gates has undergone an unlikely transformation, Longhorn is utterly dead.
Want malware protection? Run Safari, OmniWeb, or Firefox on OS X. This is a nice get well gift for Steve Jobs.
DivX for Mac - compress video to hard drive or server images
DivX for Mac: "Works with Your Favorite Video Software
The DivX codec is a plug-in designed to work within any QuickTime-enabled video application. With it installed, you can encode movies in one easy step or reduce the size of your current video files to store on your hard drive or on standard CD-Rs."
The DivX codec is a plug-in designed to work within any QuickTime-enabled video application. With it installed, you can encode movies in one easy step or reduce the size of your current video files to store on your hard drive or on standard CD-Rs."
iPod and OS X firewire problems
Macintouch iPod (Part 27)
Sigh. Yet another OS X firewire problem. Sounds like hubs don't work, but chains might. I do get the feeling Firewire may be on teh way out.
Slow Transfer Speeds
William Price
Edward Walters wrote "Has anyone experienced slow transfer speeds with a 40 GB 3G iPod while using an external Firewire drive?"
Definitely. This is almost certainly the same bug as this: "Syncing iPod over Firewire with iSight can cause your Mac to "freeze"".
It's still not fixed yet in 10.3.5. Unfortunately, this KB article leaves one with the impression that the problem is specific to the iSight when in fact the problem appears entirely generic. Having anything at all hooked up to Firewire at the same time as an iPod often results in extremely slow transfer speeds to the iPod. I've experienced this with scanners, external drives, and especially the iSight. I've only seen kernel panics and system freezes with the iSight, but the basic problem occurs with almost anything.
Also, the problem occurs with all incarnations of the iPod, and is not related to iSight firmware updates. I can only assume it's a generic Firewire driver bug.
Greg Weston
When I bought my G5 earlier this year, I ended up using a pair of drives to shuffle content around between that, my iBook and the Sawtooth that was being sold off. I noticed that if I had the drives chained to each other, transfers between them were blazingly fast, but if I had them both plugged directly into the G5 it was so slow that it was actually faster to copy from one of them to the internal SATA drive and then copy again to the other external.
Rob Worman
Until recently I had an extremely similar problem. Here was my setup:
-Stock G4/500 Cube
-bargain Firewire hub (powered...)
-160 GB drive in a bargain Firewire enclosure (also powered...)
-15GB 3G iPod
If I connected the iPod (or an iPod Mini) to this setup and tried to transfer data between it and the Firewire harddrive, the transfer would go along fast enough for about 30 MB, and then slow to a glacial pace that was almost too slow to measure. Searching online forums pointed to a lack of sufficient power on the Firewire bus, so the first component I tried replacing was the hub. No difference.
So I returned the hub and exchanged it for a new (Macally-branded) Firewire enclosure for that 160GB drive, and that made all the difference in the world! The problem is definitely gone.
Sigh. Yet another OS X firewire problem. Sounds like hubs don't work, but chains might. I do get the feeling Firewire may be on teh way out.
Subscribe to:
Posts (Atom)