|
|
|
|
|
|
A while back, John Gruber asked us to reprint a section about Input Managers from MDJ and MWJ 2007.12.03 on this site so that more people could read it. We present it here, slightly updated for today's circumstances.
The discussion at the time was David Watanabe's Inquisitor 3, the free Input Manager that patches Safari so that the search field returns results instantly in a Spotlight-style dark window as you type. Its release was new at the time, and the product was mostly unchanged but “repackaged” for Mac OS X 10.5 since Input Managers need to have specific root permissions to work under the new OS for security reasons.
With yesterday's release of Safari 3.1, and yet another round of broken Input Managers, there's once again an opportunity to point out a real problem in how the Mac press is covering programs like Inquisitor that work by patching the system or other applications. Traditionally, the name for code that runs without support in another process’s address space is a hack, or if you’re being nice, a patch. The purpose of such code is to intercept either an application or the system as it tries to perform a specified task, so the patch code can supplement or replace that task with its own action, and then return control to the original code.
Such code obviously entails security risks, and it’s not necessarily easy to create. Unsanity created a well-documented system for patching applications under Mac OS X, called Application Enhancer, but they call APE and its modules “haxies,” which makes most of the Mac press drip with disdain. Inquisitor, on the other hand, uses the Input Manager facility in Cocoa that was originally part of NEXTSTEP to allow third-party modules to intercept keyboard input and transform it as necessary to support complex languages. Long ago, developers figured out that since all Cocoa applications load Input Managers, they’re a great way to load patches into any Cocoa application. That’s what Inquisitor does.
(Input Managers also load into any application that uses the Cocoa text system, including Carbon applications that use the Font Panel, WebKit, or any other AppKit-provided view with text input options. Increasingly, especially since there’s no 64-bit version of Carbon, Input Managers load in every application.)
What’s the problem? Sites like The Unofficial Apple Weblog, in its coverage of Inquisitor 3, insist on calling these Input Manager hacks “plug-ins,” implying a level of architectural and technical support that simply does not exist. This has become nearly standard usage on the Mac web: this Mac OS X Hints instruction for using Inquisitor on Leopard calls it “David Watanabe’s great auto-complete Web search plug-in.” Christina Warren of TUAW wrote an entire article about Input Manager hacks for Safari and a utility to load them under Leopard while calling them “plug-ins” every single time, never once noting that the entire “architecture” of these things is not a supported method for patching Safari. Warren equated them to Firefox plug-ins, which are designed expressly to load in that browser, and Input Managers are no such thing. They are hacks.
This is hardly limited to TUAW, although it seems that other authors on the site are determined to call Input Managers “plug-ins” when they’re aimed at Safari. On the MacUser blog, Derik DeLong called Input Managers “plug-ins” as well, saying they “enhanced” browsers to “usable states,” and applauded Apple for keeping them in Leopard because they’re “such a powerful API.” (DeLong also cheered undocumented and unsupported ways to make Mail load unsupported bundles in Leopard, calling those patches “plug-ins” as well.) The developer of PlugSuit, mentioned in Warren’s TUAW article, says his program “allows Input Manager and SIMBL plug-ins under Leopard and Tiger.” This is ridiculous on its face: SIMBL is Mike Solomon’s Input Manager that handles the tricky work of being an Input Manager so that programs like PithHelmet can more directly patch applications without having to implement the overhead of the actual Input Manager code. (It was recently updated to version 0.8.2 to add Leopard compatibility.) The name is an acronym for “Smart Input Manager Bundle Loader.” These are not plug-ins.
Tuesday's release of Safari 3.1, and yet another round of broken Input Managers, has not changed TUAW's positioning in the slightest, as you can read for yourself:
Whenever a new browser version rolls out, the engineers responsible for plugins and enhancements turn on the espresso machines for the coming all-nighters as they rejigger their products for the latest and greatest.
One site, in a reference we can’t locate right now, even lamented that Safari “doesn’t have a plug-in architecture.” This is surely news to developers like Adobe, Real Networks, Flip4Mac, and Apple, whose code can all be found in your “/Library/Internet Plug-Ins/” folder. Those plug-ins are for browser content, though, not browser behavior. Most applications don’t support generic plug-in architectures to let third-party modules completely customize the human interface. Firefox doesn’t come nearly as close as the hacks Input Managers can apply to Safari.
The problem is that the Mac press has decided, by unwritten fiat, to call Input Manager hacks “plug-ins” and confer an aura of legitimacy on them, while continuing to call other forms of patches “hacks” and caution you against installing them. That’s both misleading and unfair. The fact that Input Managers work through a Cocoa method does not make them better or worse than APE “haxies” that load through low-level Mach messages, or than any other way that third-party code loads without support into any application’s address space.
You can’t call the hacks you like “plug-ins” and the ones you don’t like “hacks” and simultaneously pretend you’re actually informing readers. This is not to say that you can’t choose to install whatever patches you want, as long as you’re aware of the risks in security, the dangers in updating, and the general facts behind putting someone else’s code in an application’s address space. You just shouldn’t be misled by the press into thinking one kind of hack is implicitly “better” than another kind.
# - Posted by MacJournals News on 3/19/08; 4:44:50 PM to In The News
|
|
|
|
|
Among the many, many, many upgrades we've suffered through in the past few weeks (including the production machine, production software, hard drives, machine repairs, even light fixtures and internet access hardware) have been server changes. While we're shuffling some things around, we figured it was time to make the changes announced last year permanent.
So, effective as of now, the original https://secure.macjournals.com/ RSS feeds for MDJ and MWJ subscribers now get HTTP redirects to the newer feeds introduced last July, and those feeds are no longer "beta." (Ironically, we may need to rewrite the software that makes those feeds, since it turns out the database behind them is really quite stupendously horribly designed [our fault]), but the URLs will remain the same.)
Your newsreader should easily and permanently replace your old URLs with the new ones the next time you refresh. If it doesn't, we heartily recommend the now-free NetNewsWire 3.1, which handles this with aplomb and is, as mentioned, now free. Hence the adjective.
We had no idea how much stuff needed maintenance until we started fixing a few of the more broken things. It was kind of like fixing a broken drawer and discovering that the entire cabinet was riddled with termites, and then that the carpet needed repair, and on and on. We had about a 10-day stretch in February where something new, but minor, broke every single day. They were all manageable and fixed in a few hours, but when they come 10-15 per week for 2-3 weeks in a row, it makes you want to do something self-destructive, like enter politics or speculate about iPhone carrier agreements.
Almost everything is upgraded and fixed, including a few things MDJ and MWJ readers have wanted for nearly two years, with testing to resume this week (cross your fingers). Almost every single thing between the editors and the internet that we use to produce MDJ and MWJ has been upgraded or replaced since the last issue, and that almost included the very Ethernet cables connecting the machines. It still may—LAN transfers are slower than they ought to be in some cases but not others—but it's been quite the makeover. We're just glad it's done. Hauling G5/Mac Pro cases around and copying 300GB hard drives over and over is something we're happy to leave for special occasions. We'll have more upgrading to do in the second half of 2008, but we're just about done for now.
# - Posted by Matt Deatherage on 3/9/08; 3:36:17 AM to Administrivia, MDJ, MWJ
|
|
|
|
|
A note from the publisher
So, this week the Mac press paid tribute to John Moltz, who got the kind of eulogies normally reserved for people who have actually accomplished things, like George Ou and Rob Enderle, without going through the inconvenience and mess of actually dying. Or even sobering up. Or even sobering near. Hell, pick a preposition and put it near "sober," and Moltz won't be anywhere in the vicinity.
Moltz had 18 great months of biting Apple-related humor at his aptly-named "Crazy Apple Rumors Site." Sadly, those 18 months were spread out over six years, ending on Friday when Moltz moved the site to "indefinite hiatus"—the same famed location where you'll find Studio 60 on the Sunset Strip and Newsradio. And Asteroid.
The Ou-Enderle mention above (and let's face it, doesn't everyone who thinks of Rob say, quietly, "Ow! Enderle!") is the second of two times I or MDJ were borrowed to bestow legitimacy upon CARS without permission. The first was six months earlier, when Moltz had me as an eyewitness reporter when an Apple TV unit "cemented its own legendary status by pulling a 3-year-old Oklahoma girl from a well over the weekend."
(By the way, that Apple TV never arrived, Moltz. Get your pal Schiller to send over a few dozen.)
I especially liked the reference to MDJ as "a frequently published analytical journal" less than a year after my heart failure diagnosis. Thanks, bud. That's why I'm so eager to repay the favor by pointing out that in your final entry, you don't know how to spell Gassée, in a story that makes a plot point out of how to spell "Don Crabb."
Just like on Monday, when you didn't know how to spell hot tub. Or you added an "e" on purpose, and none of us are buying your story that you'd have to imagine what a hot tube is. (No compensation is required for this public service on your behalf. Except those Apple TV units. And some low-sodium waffles.)
It could be difficult to imagine how the Mac community will get along without the beloved lies, distortions, inaccuracies, incompetence, misspellings, drunken streaking, goat misplacing, interdimensional train wrecks, voter fraud, and culinary nightmares that have made CARS what it was yesterday, since what it is today is "yesterday's news." It could be very difficult. It won't be, but it could be.
But as time passes, as sites fade away, as Moltz's blood alcohol level plummets to around 0.36, CARS shall not fade from the Mac consciousness for a single two-word reason: Artie MacStrawman.
The least clued in among the business and technology press (Ow! Enderle!) has, for decades, clinged (clung? clanged? clunked? mojitoed?) to the fallacy that "Mac users" act in ways the writers only imagine, something you can easily detect because they could only back up those assertions with one or fewer factual examples.
CARS didn't just debunk the problem for the gazillionth time: it gave the fictional Mac user a name, and in doing so, breathed life into the bogeyman. From that point on, instead of wondering who these Mac users were that kept bugging everyone, we knew. It was Artie! The scourge of a generation, the anonymous source for tens of thousands of Mac-bashing articles was dragged into the sunlight, where he was clearly seen as no menace at all.
For this reason, and if for no other, CARS has become Beloved of Seekers of Mac Truth. Its name shall remain spoken throughout the virtual lands. Steve Jobs himself named a Pixar movie after the site. (Oh, yeah? Prove me wrong, smart guys.)
So, Johnny, on the off-chance there is some actual difference between "being drunk and writing CARS" and "being drunk and playing World of Warcraft," enjoy your time off. Come up with a few months' worth of new material that you can stretch into the next six-year run. By then, there'll be a whole new crop of writers you can name-check to get yourself free publicity, a tactic that's both more effective and much cheaper than "advertising" or "quality."
Or just sleep it off, since Artie has secured your place in Valhalla. Either way, send the damn Apple TV units. This writer's strike is killing me.
(I only figured out on Saturday that I was having a rather serious adverse reaction to some new prescription medications, so I was increasingly useless through Saturday night. Both MDJ and MWJ should be out soon. This is why we normally don't publish specific plans—I'm feeling a lot better, but the days of bad sleep and the remaining soreness are still causing me problems. It's like I spent Wednesday through Friday soaking in a large tub full of arthritis.)
# - Posted by Matt Deatherage on 2/2/08; 4:23:51 AM to In The News
|
|
|
|
|
It was about a week ago that we noted that our production machine had stopped working.
At the time, we did not know that the local Apple Store's "diagnosis in 24-48 hours" would take five days—and end with "we can't find anything else wrong so it must be the logic board; please mortgage all your property to buy a new one."
We're investigating other options, including last week's new machines. (Even if we'd purchased AppleCare on the sytem, it would have expired six months ago.) We started limping along on a secondary machine by Thursday morning, and as of Sunday night, we're fully up and running on it, although as usual we have to re-enter a bunch of serial numbers, fix some aliases, and so forth.
Since we purchased our production Power Mac G5 in late 2004, we've had no need to replace it, so the temporary machine we'll be using marks the first time that MDJ and MWJ shall be produced on Intel machines. It also marks the first production under Leopard, and the first production using Microsoft Word 2008. We haven't seen much of Word yet, since our first and primary task was to convert the handful of Visual Basic macros we use in production to AppleScripts, and some very subtle changes made that more complicated than we'd thought. We'll talk more about that, either here or in MDJ and MWJ, later in the week.
We'd prefer to tear through a ton of material and publish around 8:00 AM CST, but unfortunately, the publisher is bugging out because he has an important doctor's appointment at noon today that was scheduled months ago (and has been drafted to run other important errands as long as he's out). We did take the first week of the year off, instead of Christmas week, because that's just how it worked out for us. We were busy at work a week ago, until the machine died. Now we're back on a smaller machine, an Intel iMac. It seems to work fine, but with some Rosetta programs still in our production flow, we wish it had a bit more RAM.
We had been working on some philosophical articles about issues that have been raised online in the past few weeks as if each was some kind of crisis, but in fact, none of them were any kind of crisis. Ironically, one of those was about obtaining repairs, so we're a bit more up-to-date on that one now.
Those are not time-critical, so we'll likely put them on hold and go straight into all the news from the Expo, and provide our pre-keynote gloss on some of the more prevalent rumors. If there's not much news on Monday (hey, it could happen, right after President Gore cuts all funding to the EPA), we'll finish up the stuff in the pipeline.
Either way, the plan is to publish that Tuesday morning, and take that plus the previous "Think Secret" coverage and put it in MWJ for Tuesday morning, then head straight into whatever happens at Moscone Center on Tuesday afternoon (our time). If the doctors find something wrong or there's nuclear war or something, the schedule may get pushed out again, in which case we'll likely go straight to keynote coverage to get that out Wednesday morning.
We had also planned to spend time last week on Apple's Q4 FY2006 financial results, which happened before the publisher got his strength back. We'll now postpone that until the coming weekend or early next week, to try to get all the financial news contained in a couple of issues for those of you who prefer to skip it (and to keep it isolated for those of you who pore over it in great detail).
That's the current set of plans, since a few of you asked how the machine is doing. The machine is not doing well at all, but we're now managing with a substitute while eagerly awaiting something bigger to run all our tools at once. It's really quite astonishing how much RAM and disk space all these things take. Why, we remember when code segments couldn't be larger than 32KB, and the whole system and applications loaded in 512KB, and…
OK, we'll stop now. We're old.
# - Posted by MacJournals News on 1/14/08; 2:05:08 AM to MDJ, MWJ
|
|
|
|
|
Our production machine is still out of commission, so we're doing this by hand; please forgive any typos or formatting errors.
More than two months after we were compelled to call out MacFixIt's despicable fear-mongering, the site has continued to fight back by picking even the most ludicrous and remote justifications for its ridiculous rituals and passing them off as "evidence" that everyone who knows how Mac OS X works is wrong, and only MacFixIt's "do it this way or suffer the consequences" advice can keep you from certain doom.
As before, the true sentiments seem hidden in the RSS summaries rather than presented on the main page. Such is the case with Tuesday's entry, "Cannot copy and paste in Leopard: repair permissions." The RSS summary for this item is just two words:
Voodoo works.
Well, no, it doesn't. Here's the text in question:
If repairing permissions with Disk Utility (located in /Applications/Utilities) is a useless ritual, don't tell the group of users who have been able to reverse an inability to cut/copy and paste under Mac OS X 10.5.x (Leopard) via the process.
For some users, installation of the software for Logitech's Harmony universal remote has broken the ability to cut/copy and paste under Leopard. Repairing permissions resoles [sic] the issue.
Guess what? Repairing permissions is a "useless ritual" when it's a ritual. We have pointed out repeatedly in MDJ and MWJ that repairing permissions is a completely valid troubleshooting technique. These people had trouble, they wanted to fix it, and they tried an easy troubleshooting step that resolved the problem. Hooray! The system works!
What's "useless" is to repair permissions as if it were some form of necessary system maintenance. It's not, or Apple would have set up the daily, weekly, or monthly automatic launchd tasks to do it for you. In fact, Panther and Tiger both had to add extra code to undo the damage caused by people repairing permissions frequently for no reason at all. Nothing in the Mac OS X rules required that installer receipts have the correct and final permissions for all files installed—a post-installation script could have, and sometimes did, set permissions depending on the configuration of your system. But if you "repair permissions" every day (or hourly) "just to be safe," you undo that work and leave permissions incorrect. Apple had to add mechanisms in the Installer and Disk Utility to work around this unanticipated problem.
No one, except maybe Artie MacStrawman, argued that you should never repair disk permissions. If you're having trouble, especially if you suspect it's permissions related, you should by all means repair permissions and see if that fixes the problem. You just shouldn't imagine that performing this task at other times is doing you any good, because it's not.
You do not need to repair permissions regularly.
You do not need to avoid repairing permissions if you're troubleshooting.
What a happy day it will be for us, and for all the Mac users in the land, when whoever is writing MacFixIt these days stops trying to mend a bruised ego by repeatedly misconstruing the words of critics. Since being called out for fear-mongering, the site seems obsessed with proving the criticisms wrong, no matter how many facts it has to twist in the process.
Another egregious example: when the site discovered that using Mac OS X 10.4's "repair permissions" functionality causes problems on Mac OS X 10.5 startup disks (because the installer receipts are stored in a different way on Leopard than on Tiger), MacFixIt twisted the story to imply that Alsoft, makers of DiskWarrior, had somehow hidden this from customers.
The clearer version of the article? "Repairing permissions when started from Mac OS X 10.4 causes problems on Mac OS X 10.5 startup disks, even if you boot 10.4 from something like the DiskWarrior CD, and even though that's exactly what Alsoft just said, we're going to pretend otherwise so we can pretend that our October fear-mongering about DiskWarrior 4, whose main 'rebuild directory' functions does absolutely no damage to Leopard disks, is somehow dangerous because we said so and everyone who says otherwise is a poopy-head."
To the MacFixIt writers:
You were wrong, and you libeled a long-time and dedicated Mac developer in the process. Now, rather than admitting it, apologizing, and moving on, you're bound and determined to flush your entire site down the crapper by pretending that your obvious mistakes were somehow correct. Stop it. Apologize and move on. You can do important work if you'll get your bruised egos out of the way and focus on troubleshooting, and supporting every word you write with solid factual evidence. Not "a reader saw it so we think it works this way," not "it worked for us so it probably works for everyone," but facts.
If you don't understand what's going on with a particular issue, say so. Say what you know and what you don't know clearly and precisely. Stop guessing. Last month, you said that when people see a QuickTime logo with a question mark in it instead of a Flash movie in a Web browser window:
In most cases the issue has to do with a conflict between QuickTime Player attempting to playback Flash content, and Adobe's own Flash plug-in attempting to playback the same content.
This is not true. This was never true. More than one browser plug-in can register for the same MIME type, but the browser only calls on one of them to play it. It makes absolutely no sense for a browser to call upon multiple plug-ins to draw the same content, and that's why no browser has ever done that. The problem is that QuickTime is attempting to play Flash content and it's not very good at it. The "note" on your "Fix #1":
(Note: Before going through the process below, try simply deleting the file ~/Library/com.apple.quicktime.plugin.preferences.plist then restarting your browser).
…would be the simplest correct solution if you had gotten the pathname right. It's ~/Library/Preferences/com.apple.quicktime.plugin.preferences.plist. You have this habit of leaving Preferences/ out of that path in lots of articles.
The point is, you said something that could not possibly be true. You didn't know the true cause of the conflict so you guessed at it. Stop doing that. Stop trying to rehabilitate your mistakes. Stop writing for your egos. If you get something wrong, fix it and move on. Write what you're sure of, and let people know what you don't know.
You don't have to try to scare people into following your superstitions. Make MacFixIt a must-read again: don't write a single word you can't support with documentation. When you don't know, say "we don't know." Be honest and the world will be patient. You do lots of good work, and coordinate lots of information, and yet none of that's going to matter. Keep making stuff up to salve your egos and your days are numbered, and we're not talking triple-digit numbers. Focus on the facts and the good work and you'll have a devoted audience for as long as you want them, without even trying.
We're just sayin'. You're MacFixIt, for cryin' out loud. Fix it.
# - Posted by MacJournals News on 1/9/08; 2:43:42 AM to In The News
|
|
|
|
|
In an unwanted display of irony, our production machine (a dual-2.5GHz Power Mac G5) has gone dark in the midst of our preparation of an article about how to best take in your Macintosh for service. (Don't worry—we removed the internal hard drive before taking it in for service, and verified with the local Apple Store that this was fine.)
We even stopped by a going-out-of-business CompUSA store to pick up an external Serial ATA drive enclosure, in the hopes of getting the drive up and running on another computer and continuing at less than full speed. Alas, when the drive enclosure box said "cables included," they meant the USB cables to connect it to the computer—not the cables you need to connect the drive to the enclosure. Those are not included, and we don't have any, since in most Macintosh models, they're rather firmly attached to the case or logic board at several places. It's now long past closing time at any store that might have them, and most of them are a good 45 minutes away, anyway.
This is why no one liked CompUSA and why they're going out of business.
So while we're without the main machine or main storage drive for a day or so, we'll be out of commission—we're here, but without the properly licensed installations of all our tools. E-mail responses will therefore be delayed as well. And it's still better that it happened this week instead of next week.
Just in case you worried, we're still here. We hope to be back at full speed within a day or two, and certainly by the end of the week.
# - Posted by MacJournals News on 1/7/08; 9:39:28 PM to Administrivia
|
|
|
|
|
All the versions of MDJ 2007.12.20 that were just released are signed properly. (Tables like "Table 1" still take way too much time; it delayed yesterday's issue by several hours.)
Unfortunately, they're all digitally signed with a masthead that says "Previous issue: 2007.12.02". It was MDJ 2007.12.03, of course. Lots of things that used to be more automated currently are not, but we're working on it.
# - Posted by Matt Deatherage on 12/21/07; 4:25:28 AM to MDJ
|
|
|
|
|
A note from the publisher
Over at Macworld, editorial director Jason Snell has a blog post up about opinions on the "Best Mac Ever:"
I tried an experiment: I asked the assorted mass of people who are following me on Twitter could find some vague consensus about the best Mac model ever.
A vague consensus? Maybe, maybe not. But I sure got a lot of fascinating answers. Among them:
Matt Deatherage of MacJournals said “they all sucked in their own ways.”
So I need to have a little conversation with Jason about what "private Twitter feed" means.
It's not the kind of thing I'd say publicly because it cries out for explanation. After all, many Mac models are quite good. But when I heard the question, my rephrasing thought was "Is there some Mac design from the past that I wish I could still buy today," and the answer, quite frankly, is "no."
It's a given that all older machines are slow and small compared to today's behemoths. Lots of people liked the SE/30, but it seems almost laughable to note that the machine had a 16MHz (yes, megahertz) 68030 processor and a maximum of 8MB (yes again, megabytes) of RAM. That changed to 32MB later on when the logic board was able to handle the newer 4MB SIMMs, but that was huge at the time. (You can view the specifications here.)
Commenters at Macworld have mentioned the Macintosh IIfx, the "wicked fast" six-NuBus-slot behemoth with a 40MHz 68030 and numeric coprocessor that redefined "speed" back in 1990. It was a cool and important machine, but it was very expensive even for the performance. Seriously: read the original press release. With 4MB of RAM and a 160MB (again, megabytes) hard drive, the Macintosh IIfx retailed for US$10,989. That price did not include a monitor or graphics card, by the way.
Staffer John C. Welch voted for the Power Macintosh 8600, another machine we had around here. It was indeed a good machine, but I think I still have some scars on my fingers from the cuts that the chassis inflicted when trying to change the RAM configuration—and that design was much better than the previous ones.
Our next production machine was a 450MHz Power Macintosh G3, which was again a good machine, but we got ours just months before the Power Macintosh G4 was announced, so it always seemed a bit slow to us. (Ours came with a build-to-order 36GB hard drive that, frustratingly, failed less than a week after delivery, and that may have colored our expeirences. So might the color of the machine, which seems quaint less than a decade later.)
After that, a dual-800MHz Power Macintosh G4, still in use as a server, and another one that eventually had mysterious hard drive problems. It was a good machine (you can tell because we still use it), and we never thought ill of it while using it, but after a few years of using a dual-2.5GHz Power Mac G5, I'm not enthusiastic about the plastic enclosures. (Apple seems to have moved on as well in this year's aluminum iMac designs.) Then again, the Power Mac G5/Mac Pro enclosure is really pretty darn big, and that's less than perfect, too.
The G5 and Intel-based iMacs are really sharp designs, but your choice of displays is obviously limited. Andy Ihnatko likes the G4-based iMacs, but they only had one user-servicable RAM slot (and no way to replace the hard drive without official service). The aluminum MacBook Pro/PowerBook G4 design is very nice, but far too many people complain about the poor AirPort reception inside the metal case.
The Mac Mini is still a thing to behold, I think, but I wish a good model cost US$400 instead of US$800. The IIci was a ground-breaker in its day, but I still remember it being as finger-scarring as the Power Mac 8600 for some reason. The original iMac was quite nice and very important when it was released nine and a half years ago (can you believe it's been that long?), but compared to later models it seems big and comical.
On and on it goes. They're all fine machines, and we loved all of them when they were new, but I'm not anxious to go back to any of the older models.
Commenter Burda said, "The best Mac ever is whatever is next." Jason responded that this was "A perfectly reasonable answer, though a less fun one."
I don't know that the next one will be the best ever, but I know that I want them to keep getting better, just like I want movies to tell new stories, for TV to break new ground, for athletes to achieve more than their predecessors did. All the previous Macs I've used on a daily basis were great, but what I really want to know is "what's next?"
Whatever it is, I'm sure it'll suck in its own way—and be great in a lot of other ways.
# - Posted by Matt Deatherage on 12/11/07; 5:47:24 PM to In The News
|
|
|
|
|
Oops - it's hard to get back in the saddle, and we simply forgot to digitally sign the setext version of MDJ 2007.12.03 that was sent in E-mail this morning.
The version in the MDJ RSS feed is indeed properly digitally signed, if you want it for your collection.
# - Posted by MacJournals News on 12/3/07; 4:50:37 PM to Administrivia, MDJ
|
|
|
|
|
When Alan Oppenheimer, co-inventor of AppleTalk, says something is an urgent security need, you're well advised to listen to him. From Open Door Networks' "ISFYM" blog:
We're usually not alarmists here, but right now we need to be. Unless we're proven wrong (and we'll certainly admit it if we are), do not use Leopard's new "Back to My Mac" feature. It contains a serious security hole, which allows anyone who can access your .Mac account to easily take full remote control of your Mac, without having to enter your Mac's password.
In essence, "Back to My Mac" puts your .Mac-registered computers in the "Sharing" section of the Finder sidebar on every other computer also using your .Mac account, so that you can enter your .Mac credentials in another location (like an Internet café or at work) and find your primary machine in the Finder's "Sharing" sidebar. Unfortunately, when you click on that machine in the sidebar, you have full access to it just from your .Mac credentials—you do not need to enter a user account name and password or otherwise log in.
Open Door is correct in that this essentially makes your .Mac password a second, "backdoor" password to controlling your machine from anywhere on the Internet. If your .Mac password is also your iTunes Apple ID, and you've shared it with some other people to share purchased music, those people may now have full access to your Leopard machines if they can enter your .Mac password in System Preferences. That's unacceptable unless you choose to take that risk.
So, for now, in System Preferences > .Mac, disable "Back to My Mac" sharing, which in non-Apple fashion is on by default.
And, for those keeping score, note the difference between this and fear-mongering: Open Door explains exactly why it's a problem, what the risks are, and what to do about it. If you're relatively confident in the security of your .Mac password, you may choose to keep "Back to My Mac" enabled—but it's a choice you need to make being aware of the issues. Kudos to Open Door for the discovery and the clear, calm, and rational description.
# - Posted by MacJournals News on 10/27/07; 11:49:11 AM to In The News
|
|
|
|
|
This Page was last updated: Wednesday, March 19, 2008 at 5:53:37 PM
Copyright 2008, GCSF, Incorporated. All rights reserved.
|
