Interview with Tim Bray
No history book on the Internet would be complete without a chapter on Tim Bray. Not only was Tim a co-editor of the XML 1.0 specification, but he also created the first parser software for XML documents and has been co-driving the development of Atom. Today, fulfilling a dual role as tireless Netizen-evangelist and Director of Web Technologies for Sun Microsystems, Tim continues to build on his early work by advocating for a more elegant, platform-independent and user-friendly Internet. Linux Journal recently checked in with Tim Bray to get an update on where he is channeling his creative energies these days.
LJ: You have been Director of Web Technologies for Sun Microsystems for just more than two years now. Can you tell us what kinds of projects you've been pursuing in that role?
TB: The most important project is helping return Sun to the position it should be in: profitable and growing. At Sun, I've been a generalist, which is good for someone with adult-ADD. I did a lot of work on launching the employee blogging (see blogs.sun.com). I've been an evangelist in favor of Sun embracing alternatives to Java—both running languages like PHP and Ruby on the Java platform, and embracing those languages in their native form as perfectly viable options for developers. I've been a vocal skeptic of the WS-* project, preferring simpler, more lightweight alternatives based on proven Web technologies. And I've been doing a ton of work on the Atom technology, both co-chairing the IETF working group and evangelizing it to developers. I've also done some work on disk I/O performance (I'm the original author of the venerable “Bonnie” benchmark). Finally, I've been whittling away at a skunkworks named Sigrid for a couple of years now, but <blush> have yet to release anything.
LJ: Does the position at Sun give you an effective “bully pulpit” from which to effect positive change on issues important to you?
TB: No change comes easy, and no single individual has a fulcrum placed in such a way that he or she can move the earth. I've put my weight behind a few ideas and efforts that have moved forward in a way that pleased me, and I've failed to make much progress in some other areas. I think the degree to which I'm listened to has more to do with what I say—whether it makes sense and is interesting—than who I work for.
LJ: What issues and trends are you currently most passionate about, and what form is your advocacy taking?
TB: I think Atom, both the format and the protocol, are going to be pervasive technologies that will have highly visible consequences. Based on my XML experience, I'm now too smart to try to predict exactly what those consequences will be. But I'm evangelizing it everywhere I get a chance, most recently from the stage at OSCON. Enough others have taken up the task of questioning WS-* that I no longer feel compelled to speak up quite so often. Second, I am a very small part of the groundswell of developers heading in the direction of dynamically typed languages. I am personally quite passionately convinced that almost all DRM technologies are technically broken and bad for business, but this has little to do with my day job.
For all the things I care about, I find my blog (www.tbray.org/ongoing) the most effective way to share my views with the world; mostly because it's a conversation, not a bully pulpit.
LJ: As you say, you have been devoting a great deal of energy to Atom. What is your specific role in it, and what are your thoughts on where it is headed?
TB: I'm the co-chair of the IETF Working Group, and one of the loudest Atom evangelists. Both the Atom data format and the Atom Publishing Protocol (APP) are going to be big. The data format will be used in some places where RSS is now, but it turns out that there is a demand for a general-purpose “collection” format—something XML has never had, and Atom suits that bill. The APP provides a low-friction, simple, standardized way to post anything (words, pictures, movies) to the Web, to update it, and to delete it. There's an excellent chance that it will be included in a high proportion of the future's cell phones, not to mention e-mail and Web and news and office-productivity clients, which will thus be able to post to any Web-publishing service that plays by the rules.
LJ: You were one of the three editors of the original XML 1.0 specification. What are your thoughts on the results eight years later?
TB: I'm horribly unsatisfied and keenly aware of all the ways in which XML could have been better, mostly by being smaller and simpler. XML addressed a huge, painful problem (standardized machine-independent data format) at the right time, and it didn't suck just enough, so it became the default solution. That aside, I'm happy that the world has bought into the notion of sending data around in a way that is thoroughly internationalized and radically independent of any programming language or operating system or hardware.
LJ: From what I understand, XML grew out of the unwieldy SGML and a project to put the Oxford English Dictionary (OED) on-line, is that correct?
TB: Not quite. XML grew out of SGML, which was used in a lot of high-end publishing systems, but not the New OED project, which I managed. The electronic OED, at the time I was there, used a markup system that was an awful lot like what we now call XML; as a side effect of working with it, and then of founding a company, Open Text, to take our inventions to market, I became familiar with SGML. In 1996, when Jon Bosak was getting the XML Project launched, there were maybe a dozen people in the world who were familiar with both SGML and with the Web, and I was one of them.
LJ: How do you think things stand regarding XML as a document format, post controversy with the State of Massachusetts regarding the Open Document Format?
TB: The fight is basically over; the public sector has noticed the risk reduction and flexibility you get from storing long-lived documents in an XML-based format and has started a move in that direction that will become pervasive, world-wide. After years of trying to convince them that proprietary formats for public data were okay, Microsoft has shifted gears and is frantically trying to apply a thin coat of “standards” paint to its own Office XML formats; the spec is thousands of pages in length and will never be fully implemented by anything but Microsoft Office, which kind of misses the point. I'm pretty confident that the public-sector policy-makers will see through this pathetic ruse. The private sector, which typically has a shorter temporal horizon, is less far along the road to taking good care of its information resources, but it'll get there too.
LJ: Can you tell us more of your thoughts on the state of Web Services?
TB: It depends what you mean by “Web Services”. There are two core ideas, taken from the Web (hence the name). First, instead of trying to define APIs across networks, you specify the messages that are exchanged, and second, that XML is a decent data format for the messages. I personally believe both, and this is the only sane way to integrate applications in a heterogeneous environment. Unfortunately, the attempt to standardize this excellent idea, under the WS-* label, has gone off the rails. It is insanely complex, baroque and abstracted, and implementing it requires reading hundreds of pages of poorly written, unstable specs and dealing with ferocious inter-vendor politics. Fortunately for the future, there is a rock-solid base of proven, efficient, scalable, standardized technology: HTTP, XML and so on, and some very clear guidance on how to do things: REST. So, I expect WS-* to fall far short of expectations, but Web Services, done more simply, to be the default way of doing things in the future.
LJ: What is your take on the Java/OSS debate?
TB: I'm not 100% convinced that an OSS license for Java will bring that much engineering benefit. One of the biggest benefits of open source is that bugs are caught and fixed more quickly. But “Java” is defined as “a binary that passes the TCK”, and that's worked well; the Java community likes it, and that's how it's going to stay. So I'm not sure that it's reasonable to expect the open-source “release early, release often” culture to come to Java. On the other hand, Java's licensing has been a cultural obstacle to a lot of people, especially in the Linux space. One result is that things like GNOME and KDE are still substantially written in C++, blecch. So I'm optimistic that a real open-source license will eventually empower the developers of the non-Microsoft desktop.
LJ: You are a big fan of Ruby and Ruby on Rails. What is it about them that interests you?
TB: In fact, I'm a fan of dynamic languages in general—my own Weblogging system is written mostly in Perl. To my eye, Ruby and Python stand out from the crowd of such languages in that they seem useful for building large, ambitious software projects as well as the quick one-offs that “scripting” languages have traditionally been used for. Speaking personally, I find Ruby a bit more pleasing than Python, but the margin is at best 55/45; there are areas where Python is more attractive. I don't think either is going to wipe out the other. Rails seems special; in its sweet spot, maintainable Web apps with a low barrier to entry, it seems like it's set a new standard.
LJ: What is your take on the state of PHP?
TB: Aesthetically speaking, I don't like PHP. I am told that its top-level namespace has 5,000 functions, which is sort of mind-boggling. On the other hand, I've seen how it's empowered legions of people, many without a lot of formal training, to get very usable Web apps on the air quickly. And its scaling story is impressive: anything that runs the infrastructure for Yahoo! Finance deserves respect. Still, whenever I'm asked to look at actual PHP code, chances are it'll be an unmaintainable mess: spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML. I think that what we'd like, ideally, is something that has PHP's ease-of-use and scaling advantages, but is more effective at separation of concerns and maintainability. Something like Rails or Django. And, Java EE is moving in that direction fast with release 5.
LJ: The Weblog you mentioned above at www.tbray.org/ongoing—what is your mission with it?
TB: No mission whatsoever. I like being able to talk to the world, and even more, I like having the world talk back to me. I'm naturally a fast writer with lots of strong opinions, and it turns out that (for the last couple of years anyhow) a lot of other people are interested in the same things I am. It also gives me a place to post my pictures and talk about politics and music and books and so on. I'll confess that there have been a few occasions when I've deliberately tried to write something to appeal to a big audience or make an impact, and it never works. I totally can't predict which of my pieces will get Slashdotted and which will sink without a trace. So I just write about what I care about. Sometimes people ask me to write about something—sometimes people at Sun, sometimes from elsewhere; sometimes I say yes, sometimes no, based on whether it's interesting or not.
LJ: The potential for everyone to participate in the Internet experience seems to be an important issue for you. In fact, you've written that “The Net itself is a contribution, by humanity to humanity, the engine of future contribution and experience.” What do you think it will take to make your vision of a truly accessible and egalitarian Internet into reality?
TB: I'm 100% in favor of making the Net “accessible”, but I don't think either the Net or the world are particularly egalitarian. The only equality you can hope for, really, is equality of opportunity. Take blogging for example. Not everyone likes writing, not everyone writes well and not everyone writes quickly. Having said all that, I think that a lot more people could be participating than are right now, and the biggest barrier to entry is the lousy quality of the tools. I think that to improve the quality of the creative experience, we need to get some standard protocols in place, which is why I'm so enthused about the APP.
LJ: All right, since this is Linux Journal, we need to ask at least have one pure Linux question before we close, okay? What is your favorite Linux distribution?
TB: My favorite distro is Ubuntu, although the server/firewall box in my basement is basic Debian, and I'm happy with that too.
LJ: Thank you for your great insights, Tim!
James Gray is Products Editor for Linux Journal.
James Gray is Products Editor for Linux Journal.
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!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
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