What font and size combination do you use in BBEdit? I've been at the default Monaco-9 for a long time, but decided it's killing my eyes to use such a small size. So I got crazy and switched to Monaco-11. I've tried both smoothed and non-smoothed, but neither one is making me happy as of yet.
What is the perfect combination? Enlighten me all ye who code in large quantities.
P.S. and is there a way I can force BBEdit to always open a file in Monaco-11? I can't seem to find a way...
Update: I'm really liking ProFont 9. It's just slightly better than Monaco in my opinion. I'm going to try it out for a few days and see how it goes. Thanks John for the tip on the font settings help. Not sure how I missed that.
Nice writeup, Rosyna! Sorry for the new post, I wrote too much to fit comfortably into a comment.
I second the suggestion not to ever enable root. I've managed to go through four Macs without needing it - 'sudo' is perfectly sufficient for all uses I've encountered, and much safer.
I think the virus issue is fairly simple - it's harder to write an OS X virus than a Windows virus because of the respective operating systems were designed. It is definitely NOT impossible to write an OS X virus, it's just more difficult. One will appear eventually - hopefully it continues to be a slow process and we can continue our current virus-less nirvana.
Part of the reason, I think, is that OS X has occasional isolated security holes. Windows has occasional classes of security holes. Each class of problems can cause one, many or an infinite number of potential attack vectors. Classes of vulnerabilities are much more difficult to fix than isolated incidents, especially because there tends to be an inclination to fix specific isolated attack vectors that have been exploited rather than the underlying class of vulnerabilities (ActiveX, I'm looking at you!).
To the best of my knowledge, OS X has thus far had only one class of security holes (see Paranoid Android). Apple fixed it moderately quickly, thus closing all of the possible attack vectors associated with it.
Translating to a jargonless analogy, Windows has a lot more loose windows and cheap locks for a thief to jiggle.
Spyware is another matter - it would be as easy or easier to write successful spyware for OS X. I'll exclude a password sniffer here, as OS X provides technical means to make password sniffing difficult. But writing something that, for example, tracks your website surfing habits and reports back to the mothership would be trivial to write and to embed into a seemingly innocuous Trojan application. I don't know why such a thing hasn't already appeared (but I'm obviously damned glad it hasn't!).
People are way too paranoid these days. Especially mac users. They're going completely insane lately. You've got Symantec claiming that Mac OS X is at risk for malware. Despite the fact that in 4 years since OS X's release (Happy Belated Birthday, Mac OS X!) there hasn't been one virus or "valid" trojan. Downloading an under 200k file off a peer to peer network that claims to be Microsoft Word (one of the most bloated apps on the mac) is not valid. Nor are concepts. Then you've got that silly root kit called John the Ripper. The problem with root kits is that they're only really useful if you already have access to the machine. In the case of John the Ripper/Opener you had to have already had administrator access to install the thing. So chances are the guy that had it installed on his computer had let someone use his computer that he shouldn't have.
Now Symantec has vested interest in making mac users paranoid and scared. The more paranoid or scared their customers are, the happier Symantec is since they sell anti-virus software. The funniest thing about them trying to say that OS X is a malware target is the fact that just a few months ago a vulnerability was found in Symantec's file scanning libraries. So their antivirus software could be used as a vector to spread viruses. Go figure. My point is that even if viruses on the mac increased two thousand percent, that'd still mean zero viruses on the mac.
What's worse is that people always try to claim OS X has nothing because it is such a small target. That claim doesn't work. We have a virus for mobile phones and a virus for a firewall that less than a hundred thousand people use (which I can't seem to find right now). These things are much, much smaller targets than OS X yet they have viruses written for them. Why is it so hard to believe that there are no viruses for OS X just because OS X is better engineered? Most of the things I see now days exploit buffer overflows. And you see security fixes for such overflows on OS X all the time. The issue here is it is much harder to run executable code from a buffer overflow on the PowerPC than it is from an x86 chip. On the x86 basically any memory is executable. On the PPC you have to make sure it goes into the two separate caches (data and instruction) in a very specific manner. Depending on the program, such an exploit may only run executable code 16% of the time. The rest of the time, it will just crash. People much smarter than I have explained this much better than I am capable of. See Harvard architecture for more information.
The entire point of my putting together these random assortment of sentences is due to a recent posting to MacInTouch. This posting has got to be the most paranoid thing I've read in a while. People are assuming that just because a specific command shows results that their computer must be the target of a hacking attempt. Someone is definitely out to get them. It can't possibly be a problem that lies between the keyboard and chair, can it? The command given is:
sudo grep "failed to auth" /var/log/secure.log \
| sed 's/^.*user \(.*\) for.*$/\1/' | sort | uniq -c
And based on the result of this command, people are totally freaking out. News flash: the results mostly mean nothing. /var/log/ecure.log logs every failed authentication attempt. This includes when the user types in a bad password or a bad username in an authorization dialog. For example, if I open /System/Library/ in the finder and try to delete the "Fonts" folder, the Finder will show me an authorization dialog. If I type in "Silly Monkey Banana" and any random password, it gets logged to secure.log. As such:
[aluminum-stability:~] rosyna% sudo grep "failed to auth" /var/log/secure.log | sed 's/^.*user \(.*\) for.*$/\1/' | sort | uniq -c | grep -i monkey
1 Silly Monkey Banana
See, this does not mean someone one the internets was trying to attack my computer. It just means that I'm an idiot and typed a name that couldn't possibly exist on my machine. Same thing that goes for the guy that said: I just tried the tip which suggests this unix command: as a way of checking if someone's trying to break in. I was extremely disturbed to see, in the list, my actual password, in cleartext! Is this a huge security flaw, or what? Please advise! No, no one is trying to break into his computer. He's just typed his password into the username field of an authorization dialog. Who hasn't at least once?
The only valid output from this is how often root is listed. The majority (if not all) of the others are due to user error. The other accounts listed such as mysql, nobody, whatever don't even have shell accounts. On my G5 root is listed 8358 times which likely means there is a scanner out there searching for computers with SSH open, root accounts, and weak passwords. Since OS X ships with the root account disabled, there is no reason for me to worry. Furthermore, the root account on OS X should never be enabled. There is no reason for it and there is a huge security risk. I've got these 4 years without ever enabling root. Being root assumes you know exactly what you're doing and making typos could mean the death of your computer. It also won't bother to check if a file is in use or not before allowing you to delete it. If you need to do anything as superuser, use sudo, You can even launch individual applications with sudo. And because of the huge security (and accident) risk involved with being root, we've designed APE to not even run under root. And if the root account isn't enabled, dictionary attacks against it can't possibly work.
Please see the bottom of this entry to find out how you, the reader of this blog entry, can help us increase the size of the testing pool.
People often complain about some hardware/software Apple just released and how "everyone" is experiencing the same problems and how dare they have such horribly horrible Quality Assurance. It isn't an issue of having or not having a bad QA period. It's more of a problem of having a very limited amount of testers for the stuff. Often the tester pool consists of developers and pro users with very specific (and often common) setups.
For software, often the case is the testers are either upgrading from a previous beta release, or upgrading from a "stock" previous release that is very gently used. This doesn't apply to all testers of course, some will have backups of their genuinely used configurations and revert to those then upgrade on each seed. But either way, there is only so much software that such a person can also possibly have installed alongside the software to be tested. And only so many actions (in so many permutations) they are ever likely to perform because they are pro users. They know what they're doing. And once they test a certain set of actions that isn't plainly obvious and it has no problems, they are unlikely to ever check it again. Even though some fix in the future to another part of the program may break that unlikely action. Then there's also the chance that every single one of these people have the same preference set and something only breaks when it is unset or vice-versa.
Then when the software actually gets released to the public, people (en masse) find out that a specific action doesn't work in some bizarre circumstances (often circumstances that they think are common) and blame the testers. Even when there was no way that any tester would have ever been in similar circumstances. Evar! Or even though testers might have seen the problem, they might have attributed it to another component that was also distributed with the software or some other thing they were testing (also very possible, especially if the other component really does make the problem worse).
For hardware, it's a different issue altogether. Hardware testers (as far as I know) are an even smaller group of an even more "professional" user. Note: In both contexts, pro does not equal intelligent, it means the user has a lot of things set up and knows how to do anything they wish to get done on the computer, even if the methods they use are just plain stupid. Often hardware testers will get hardware in a prototype fashion. Some things may not be screwed as tightly as they would be in the final stages. The hardware may be assembled locally instead of a normal full service assembly or production plant (like in China). The final design might not be ready. Some components may be in different locations than in the final build. Things like that. And although the testers may test for every possible permutation during the design, they can't test for things that change in the production build.
To make up some examples... In the prototype phase of a PowerBook, the Airport chips might be on the left of the Bluetooth chips with no problem. In the production build they might be reversed (say they're on free standing PCBs of their own and are connected to the motherboard via a cable so changing positions doesn't require a recircuiting) and might not cause any problem unless the speakers were at full volume, you were playing a network game, used Salling Clicker for your Bluetooth phone, and just happen to get a message via AOL's official AIM client and the sound from it wipes out the all network activity. Even this behaviour may be very uncommon via testing, but extremely common once the PowerBook is released to the public. Alternatively, the people that make the PowerBook prototypes "on site" might not completely screw in everything all the way either because a machine does it and has an automatic stopping point (so it doesn't strip the screw), because the human just isn't all that strong, or just because the componets change so often it's a waste of time. So users testing the prototype might never see white spots on their laptop just because there was never enough pressure put on the sides to keep the LCD attached to the case. But when it gets to China and their super strong humans or machines that don't stop as soon as the on site ones do people immediately complain about white spots, color variations along the edge, or other symptoms of a case putting too much pressure on an LCD.
Testers also have an issue with testing items that come up after so many months in a certain temperature. Like the Panasonic AG-DV2000's FireWire port would fail, without exception, after about a year's of usage in a high temperature environment. The chip would just burn out. The high school (in Phoenix) I went to had about 12 of the units, in use at least 4 hours a day (up to 8 hours on some days). And more than once the Air Conditioner had to be turned off in the "winter" and the doors shut closed because the mics we used would pick up the loud noise from the A/C and the "boiler" room was right outside the door. All the AG-DV2000s we had failed and had to be exchanged via the warranty. They eventually just gave us a direct number to call after 3 or so such failures. I can't blame the testers for this failure. I just don't think they could have ever been in these specific circumstances since, IIRC, Final Cut Pro had just been released and there was little reason for testers to beat on the FW port as much as we had.
The point of all this is that you just cannot fairly blame the QA period, the testers, or the developers for all the problems that software or hardware may experience. Many times it's just that there is no way they would have ever, "in a million years", have had the same circumstances that caused a problem "everyone" has. Also remember that people with no problem often don't state as such, so you only read about those that are complaining about the issue.
Now, about Xounds and FruitMenu. They both suffered from such a problem. The Xounds daemon would crash if a particular key was not available in the preferences, relaunch, then crash again causing really bizarre problems such as receiving a -1 error when emptying the trash, some weird "unable to save library" messages in iTunes (these will not lead to corruption of the files or file system), and some crashiness in Office applications. The problem with these was that testers would immediately check out the new widget in the Xounds preference pane and that would immediately create the missing key. So testers would never have this crash.
FruitMenu has some more deep down issues. The main one being that it wouldn't work on 10.2.8. Apple likes to use constant string exports for some APIs and sometimes, although the value would work on 10.2.8, it just isn't available as a constant symbol. This was reported during the testing phase and was fixed. However, somewhere along the way it broke again. Since I don't believe any testers run 10.2.8, we had to test it in house and Apple doesn't exactly make it easy to test software against multiple OS X versions without a huge number of machines. The other huge issue with FM was that due to the number one complaint about FM being that it slowed down application launches, 3.3 would defer building of the Apple menu until some event occurred. Problem was, the event that caused the build in most cases was the first key press during the launch of an application. For applications without normal key input, it'd occur when an application was quit using the Command Q keyboard shortcut. On my G5, the delay was negligible because I don't have very many items in my Apple Menu and didn't have the hotkey prescan depth set high. Both of these meant it took no time at all to build the Apple menu. Conversely, on my AlBook the delay was HUGE but since I was testing a "future version of OS X", I just attributed it to that and the huge memory usage of Safari. I thought it was doing it because when I was quitting, the host application would have to page in huge amounts of memory that Safari forced to get paged out. I know that was a silly excuse now.
So I present you with the following FM and Xounds betas. As far as I know, aside from the version numbers, these things are good. They are not to be posted to any update service such as Version Tracker or MacUpdate. However, if you have a friend/lover/child (or one that's all 3) that is experiencing these problems, please feel free to point them here.
We do apologize for any inconvenience/problems/psychotic episodes Xounds or FM may have caused. We take full responsibility (not like we can blame someone else for this one even if we were like that) and we hope you'll forgive and forget about this recent bugginess (especially the Xounds one).
- Addressed an issue that prevented FruitMenu from loading on 10.2.8
- Fixed a problem with not being able to save icon level changes in the preference pane.
- The lag observed when pressing a key on the keyboard for the first time in an application is now much, much shorter (it now takes only a couple hundred nanoseconds versus the previous couple seconds). However, this does mean that the lag is now deferred to the first time the Apple menu is opened.
- Now shows an icon for preference panes if the option is enabled even if the preference pane doesn't have a custom icon.
- Fixed a problem preventing contextual menu items to be programatically enabled or disabled. Thanks to the people at Yummy Software for pointing this out.
- Fixed a problem when pressing the 'i' key on the keyboard while a file/folder was highlighted in an FM enhanced menu would cause it two open two info windows, one for the selection and one for the first item starting with the letter "I".
- Might fix some crashes when opening the contextual menu in some applications.
- Fixed a problem that prevented the show icon option to be changed in the preference pane.
- Fixed a crash in the xounds daemon that could prevent emptying the crash, launching Microsoft Office applications, or just general bizarre behaviour.
Please test these on 10.2.8 if you have it!
I should note that the only time I support public betas is when the software is extremely close to release and is mostly feature complete (like before adding features that may make it difficult to test the other new things). I don't like public betas that are done with a castrated version of the software or software that's just released to figure out the features that people would want in the software. Version updates are for the implementation of features people request in the original release of the software.
This post has the potential to create a lot of flames. Please try to keep your flames of either side to a minimum.
On Wednesday my "friend", Saint, forced me to go to a live showing of Al Fraken's show in downtown Phoenix at The Phoenix Theater. I really don't like downtown Phoenix that much. No reason, really. The worst part is that the local Air America affiliate's "headquarters" is right down from where I live (in the cool part of Phoenix).
Anywho, the show was really good and really funny. Something that differentiates Al Franken from Bill O'Reilly, Bill Mahr, and Michael Moore is that Al Franken is 1. a good comedian, 2. lets his guests speak (unlike the two Bills), and 3. actually tries to make what he says as accurate and as "special cased" as possible. Case in point, he was complaining about an article in The Wall Street Journal and made sure to say multiple times that his criticism only applied to the editorial page and that otherwise The WSJ is a good rag.
And yes, I did actually just put Bill Mahr, Bill O'Reilly, and Michael Moore in the same group. They're all the same. With Bill O'Reilly and Michael Moore being nearly identical. They'll omit facts that make the other side look less "evil", they'll make their interviewees "shut up" if the conversation isn't going how they want it to, or they'll just flat out edit out parts of interviews that make some of their interviewees look like decent people. On the other hand, some of the things said at the live showing didn't quite make Al Franken's arguments stand up as well as he intended, yet he didn't tell the other person to shut the hell up and get out of his studio.
Although one thing I really didn't like about Al Franken was his willingness to use the terms "liberal" and "progressive" so easily. I believe labels like that unfairly pre-categorize people as sheep. I don't like sheep. Being called "liberal" and only "liberal" implies the person/entity always goes along with that side of thinking and that they'll always agree with whatever any other liberal says. Call me what you will, just don't call me liberal or conservative. I might have beliefs that form a union with the set of ideas in one side, but that doesn't mean I don't have ideas/ideals/beliefs that aren't shared with that side.
OK, the title has to do with the fact that my "friend" brought a metallic Sharpie with him so Al Franken could easily sign his shirt. Yes, I implied Franken would have such a pen already, and yes, I was wrong. After Franken had signed Saint's shirt with Saint's pen, Al Franken asked if he could use it to sign the next person's shirt, then reminded Saint to not forget it. As soon as he was done signing, Al Franken asked if he could keep the pen. And yes, he kept it.
Below is a photo of Saint and Al Franken. Please note that Saint is on the left and is five and a half feet tall.
The rumor sites are reporting that Apple is developing a two-button mouse. Those who've been around here for a long time may remember my dislike for the lack of what I consider a decent mouse from Apple.
So if and when Apple does announce a two-button mouse, I expect you'll see something other than a "jaws will drop" reaction from me. My jaw will move in a not-so-subtle way that says "About Freaking Time!".
For Unix Geeks only:
gateway# crontab -l
0 12 * * 1-5 /sbin/ipfw add 666 deny tcp from any to any 3724
0 20 * * 1-5 /sbin/ipfw delete 666
If you don't understand, I am so glad for you. Seriously.
If you absolutely must know, here's a spoiler (select the white text to the right of this phrase): World of Warcraft uses the TCP protocol on port 3724.
When new developers are looking to write APE modules for OS X, I see a common problem that I didn't even know existed. They often have no idea whatsoever how to debug them without using gdb in the terminal. It never occurred to me that this might be an issue. We don't seem to mention it in the APE SDK even though we most obviously should. Well, it's a really easy task to do and I'll describe the two different methods required to debug APEs (and other plugins) from within Xcode. This stuff also works with Preference Panes if you set the System Preferences as your executable.
First, make sure your APE project is open. Then choose "New Custom Executable" from the "Project" menu. If the host application is simply a Mach-O packaged application (Carbon or Cocoa), just click the choose button and choose the application that will be the Plugin's host.
However, if it is a Carbon CFM application (Packaged or non-Packaged), the procedure is a little bit more difficult. Again, start out by choosing "New Custom Executable" from the "Project" menu in Xcode. Set the Executable name to what you want to be executable and choose the executable using the Choose button.
Now, this is where it gets a teensy bit more difficult. In the project window, double-click on the new "Word 2004" executable to open the settings window for that executable.
It will show the below settings window. You need to copy the executable path from the text box that labeled "Executable Path" and then replace it with /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp (this is the thing that launches CFM applications, after all).
After you edit the Executable path, you need to move to "Arguments" tab in the executable settings window.
Click the little "+" (plus) button underneath the arguments list and then paste in the path you had previously copied. In this example, "/Applications/Microsoft Office 2004/Microsoft Word". If the executable contains spaces or anything else out of the ordinary, you must enclose it in quotes or else you will get an executable not found error when debugging or trying to otherwise launch the executable from Xcode.
If you have a packaged CFM application (like Illustrator), you must enter the full path to the actual executable such as "/Applications/Adobe Illustrator CS/Illustrator CS.app/Contents/MacOSClassic/Illustrator CS". You might notice the lack of quotes in the arguments for Illustrator CS in the window below. That's because I got the path by dragging the application to the terminal which properly escapes the characters the default shell doesn't like.
After you've set up all the host applications in Xcode, you can debug your Plugins in Xcode by just running the application in debug mode (Choose "Debug Executable" from the "Debug" menu in Xcode). Any breakpoints you set up in Xcode will work assuming you have debug symbols turned on the in the Plugin. Only the settings for your plugin matter, debugging does not depend on the settings used to build the host application.
As a bonus, if you are debugging two plugins and have both projects open in Xcode, Xcode will break on the breakpoints set up in either plugin. Very good for when you are writing two plugins and think they are interfering with each other. Even if it does cure your canker sores.
Always turn off ZeroLink when using Xcode. Especially when writing full applications. It just sucks and is the number one cause of newbie confusion. It has its purposes, but should not be on by default.
We are almost ready for a FruitMenu update. The only thing missing is a new, refined icon. We had an excellent designer, Jasper Hauser, prepare us a few icons but we cannot decide which one we like best.
So it would be extra sweet if you would vote on the icon variant you like most. Just put a letter "A" to "E" in the comments to this entry (and optionally explain why, but the latter isn't needed). Once we have a winning icon, we'll use it, wrap up FruitMenu 3.3 and release it. ;)
Tell your friends, too -- the more votes we get, the better representation of opinions we'll have.
And thanks!
Variant A
Variant B
Variant C
Variant D
Variant E