Point/Counterpoint - Sane Defaults vs. Configurability
Kyle: Hey Bill, I thought you might be interested to know that in honor of the Command-Line issue my Hack and / column talks about how to set up mutt for the very first time.
Bill: Mutt, eh? That's cool...if you like a bunch of things to configure and stuff. I still don't get that. Mutt may be powerful, but there's this huge barrier to getting it running—so much so, you need an entire article on it. No one writes an article on filling out the new account wizard in Thunderbird.
Kyle: I guess that's true, but without rehashing our mutt vs. Thunderbird debate, you don't need an article talking about Thunderbird options, because there are just so few options you can configure. Although it's true that mutt has a lot of options, that's a feature for me, not a bug.
Bill: Exactly. I guess it comes down to what our Point/Counterpoint is this month: sane defaults vs. configurability.
Kyle: So at SCaLE this past year, I actually met the creator of mutt (I know, right? I was speechless). After the fanboy in me went away and I was able to talk again, I found out that his .muttrc file actually is pretty small. You know why? Because he wrote mutt's default for what he wanted. The fact that there are so many complicated .muttrc files out there tells me that what were sane defaults for him, obviously weren't sane for everyone else.
Bill: I remember that. You were nearly apoplectic. It was amazing to see the fanboy in action.
Kyle: So, I'm not even sure there is such a thing as sane defaults. I think no matter what, you are going to pick a default someone hates. That's why, to me, being able to configure as much as possible is a huge benefit.
Bill: I don't know, the GNOME folks seem to do a pretty good job of finding that middle ground. I don't mind configurability, but I think you should have the defaults ready to go. A piece of software shouldn't be a blank slate without you digging in a configuration file; it should come up and mostly work right out of the box.
Kyle: I think that middle ground shifted recently when Ubuntu decided the sane default button placement was on the left. As bad as the flame wars over that were, imagine if that weren't a configurable option!
Bill: I didn't mind the button placement on the left, coincidentally. I wonder why that is....But yeah, things like that should be configurable. Sane defaults mean exactly that, things that make sense—or perhaps failing sane defaults, maybe a startup wizard of some kind.
Kyle: Okay, I do agree with you to a point there. An application should try to start up in as usable a state as it can. My problem is less what defaults an application chooses and more whether developers think their defaults are the gold standard and don't let you change them. Honestly, I don't care where the window buttons are either; I usually have keybindings do those actions.
Bill: It all depends on the application, I imagine. I can see why there are good reasons for not changing things on an Android phone, for instance.
Kyle: I don't know though, when you look at all the custom cases, plastic covers, stickers and so on that people put on their computers and phones, it tells me that people like to customize their things. While trying to please everyone, some applications choose defaults that please no one, and what's worse, they don't allow you to change them. I guess I'm just weird enough that what does end up pleasing the majority of users ends up not working for me, so it's very important that if it doesn't work for me, I can change it.
Bill: I agree, you are weird. But I don't advocate just configurability in lieu of sane defaults. Sane defaults by definition mean they should please the majority of users. You can't just offer all these configurable knobs and dials and then not have them set to something that makes sense out of the box.
Kyle: Well, these days, “sane defaults” often mean they are aimed at some non-existent “Joe User” beginner that the developer made up, so what we end up with are lowest-common-denominator design decisions and defaults that usually leave “power users” out in the cold.
Bill: The thinking is that power users can tweak the knobs themselves, right?
Kyle: If the developer creates the knobs to begin with. I think this month we are actually closer to an agreement than in past months.
Bill: Say it isn't so! I think we're losing our touch.
Kyle: It seems the real contention is not so much that applications should allow the user to tweak settings (I think we more or less agree that's a good thing). The real contention seems to be about sane defaults themselves. I'm not so sure there is such a thing as a sane default. While there are definitely some options you can set for the majority of users, I'd argue there are many options that no matter what you set them to, they won't please even a majority of users.
Bill: I'd argue that they don't need to please the majority, but they should work. The application should be reachable to the newbie while allowing power users to do their thing.
Kyle: Unfortunately, that is such a difficult balance to make, most programs just go to one or the other extreme. Either they strip out all the options in the name of simplicity and some enlightened design, when it's really that they don't want to code in the configurability, or the program assumes you are a power user to begin with and waits for you to climb the learning curve. At least, in my experience, the latter programs tend to reward you if you do climb up the curve.
Bill: GIMP developers finally got that through their heads, I think. However, Blender (the 3-D modeling program) is just plain obtuse and hard to use, though configurable and powerful it may be.
Kyle: Whoa, did you just channel Yoda in that last comment?
Bill: I think I did.
Kyle: Configurable and powerful Blender is. Yes.
Bill: Use the Source, you must.
Kyle: See, Yoda is a good example. Skywalker was like a user who just wants sane defaults for everything and doesn't want to complete his training and look what happened to him.
Bill: Or, you could say Vader was trying to enforce his idea of sane defaults by backing the Emperor's version of “order”....But down that way of reasoning lies madness.
Kyle: Yeah, before you know it we'll equate some program to Jar Jar Binks and get all sorts of hate mail.
Bill: Would you rather have a car analogy? I'm good at those.
Kyle: No! I hate car analogies, but at least in your case, you know about cars.
Bill: Thank you for acknowledging in this column that I know about something, at least.
Kyle: I'm feeling generous today. Either that or I feel bad about all the times I've dinged you on the Linux Journal Insider podcast.
Bill: Maybe both. Perhaps you're developing a conscience.
Kyle: Over years and years of tweaking and tuning, yes, perhaps I am.
Bill: See, my conscience mostly worked out of the box.
Kyle: Really the bottom line for me is that while I want programs to work well, I don't expect my preferences to match either the preferences of the majority of users or of the developer. I want programs that allow me to tweak and tune the settings until the application fits me like a finely tailored suit.
Bill: And for me, I expect to fire up a program and have it work with at least 75% functionality almost right away. I don't want to have to read a bunch of man pages, or worse, have to read an article that someone's written on something like a mail client.
Kyle: First, open-source software, then Star Wars, now we are venturing into Philosophy. I can't wait for the e-mail to pour in.
Bill: Whatever works.
Kyle Rankin is a Systems Architect in the San Francisco Bay Area and the author of a number of books, including The Official Ubuntu Server Book, Knoppix Hacks and Ubuntu Hacks. He is currently the president of the North Bay Linux Users' Group.
Bill Childers is an IT Manager in Silicon Valley, where he lives with his wife and two children. He enjoys Linux far too much, and he probably should get more sun from time to time. In his spare time, he does work with the Gilroy Garlic Festival, but he does not smell like garlic.
Kyle Rankin is a VP of engineering operations at Final, Inc., the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal. Follow him @kylerankin.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide