Meet Uzbl — a Web Browser With the Unix Philosophy
DigDuality writes "Dieter@be over at Arch Linux forums, a release engineer for Arch Linux, got inspired by this post. The idea? To create a browser based on the Unix philosophy: 'Write programs that do one thing and do it well, programs that work well together, programs to handle text streams because that is a universal interface,' among other points. The result? A fast, low-resource browser named Uzbl, based on WebKit, which passes the Acid3 Test with a perfect score. The browser is controlled (by default) by vim-like keybindings, not too dissimilar to vimperator for Firefox. Things like URL changing, loading/saving of bookmarks, saving history, and downloads are handled through external scripts that you write (though the Uzbl software does come with some nice scripts for you to use). It fits great in a tiling window manager and plays extremely well with dmenu. The learning curve is a bit steep, but once you get used to it, it's smooth sailing. Not bad for alpha software. Though built for Arch, it has been reported to work on Ubuntu."
Worse is better!
I suggest NUZBL.
Tubby or not tubby. Fat is the question
I'm very tempted to try it, but it has those nauseating, voodoo-like vi keybindings. What's wrong with using the sweet and pure emacs keybindings? Well, I'm going to go take a look now and see if that's configurable.
MODERATOR HINT: I'm guilty of attempted humor, not flamebait.
Caveat Utilitor
The goal isn't to gain popular market share.
The learning curve is a bit steep...
Yup, say no more - that's the Unix philosophy in spades.
#DeleteChrome
but you could say the same about the Chrome developers
Ahem. Chrome was based on webkit which was derived from the Konqueror browser for KDE. Maybe not a huge market share but probably in the hundreds of thousands of users globally at the time.
and I guess we could say the same about Firefox..
Firefox was based on mozilla which was the open sourced version of the venerable and at one time market-dominating Netscape Navigator.
No, it doesn't matter if the browser has useful features to YOU. it matters if they are useful to someone. And apparently someone out there wanted a modular browser with vi keybindings out there bad enough to write the damn thing. If it's not for you? Don't use it.
This comment is fully compliant with RFC 527.
I like the idea, and I'd love to play with it a bit, but there are a few stupid design decisions:
Why don't you just use a reasonable config by default?
There really is no excuse for this. I mean, yes, I can understand where not everyone would want that "reasonable default", but that's why it's a default.
We don't want to store anything "automagically" in the users home. Some people prefer different file/directory layouts
Uhm... ~/.uzbl? How difficult is that? And if you don't like it, rm -rf ~/.uzbl!
Or just create an example script that sets up the default config, and put it in your FAQ.
We considered the option of having a global '/etc/uzbl' which user specific ones could override but that would overcomplicate things.
I'm sorry, but even mplayer is officially friendlier than uzbl. How the fuck is it "complicated" to read one config file, then another?
Uzbl itself doesn't use much gtk stuff (only the statusbar) so we could do without gtk. But Webkit needs a widget toolkit to create widgets (think javascript popups, html forms etc). Officially, it also supports QT and wxwigdets.
So, why doesn't uzbl also support these options? I'm using KDE, so Qt makes sense.
Uzbl.run( )
command is any uzbl command as defined above
return value: a string, either empty or containing the output of the command. Very few commands return their output currently, including js, script, and print.
They obviously realize that JS runs in a single thread. So the obvious implementation here would be to use a callback, not a return value, so you don't block the entire page while you run that script.
I mean, I want to like it, but that's a number of facepalms right off the bat, so I think I'll stick with Chrome until I have time to fix them.
Don't thank God, thank a doctor!
This browser is simply a wrapper around Webkit - so things like passing Acid3 with a 100/100 score is something that it inherits by default. It's not like the developers of this project did anything in particular, other than chose to use Webkit, to make it pass Acid3 or be standards compliant in other areas...
As mentioned above, Webkit isn't the most unix-like unix software being a big, monolithic program written in C++ .
All this project does is wrap a purposely obtuse front-end around a popular, open source browser engine.
Specialist Mac support for creative pros, Melbourne
How about use it to edit a remote file over ssh, from an Android phone? Or do complex things without using the damn mouse? Or write macros in a usable macro language?
More generally, with commonly used software, some of us just don't care about the learning curve. With the tools I use daily, I don't even remember what the first hour of using them was like, because it was so many thousands of hours ago. I even find it interesting to learn about new ways of doing things, so I don't resent an hour or two of getting up to speed, even if I don't end up using the tool. I could see if I had to learn a new tool an hour before a deadline I'd be annoyed, but the simple solution to that is not to schedule your new-tool experimentation an hour before a deadline. =]
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
It did--- Slashdot's had a discussion system since the beginning (or at least very close to it). Pre-account-system comments aren't archived, though, it seems. You originally just entered a name and a comment and posted it, the way most blog comment sections still work today. Impersonation of well-known users was getting too common, though, so they introduced an account system in mid-1998, requiring that you either post as Anonymous Coward, or register an account to post as anyone else. It seems that the old stories only archive comments made after that switch, so the pre-mid-1998 comment threads are mostly in the bitbucket, except to the extent that the Wayback Machine got them.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
OK. So Vim isn't the ideal editor today -- it was designed around limitations of earlier computers and when you remove those limitations you can get rid of stuff like modality that's not really necessary when you have a mouse. So lots of people get attached to modality and hjkl navigation because they spent time learning them, just like people get attached to the emacs OS, even though neither are, today, what anyone designing a new editor would make. They are historically notable -- both were more powerful and easy to use than what came before. I don't think either is very Unixy -- they're each platforms unto themselves at this point. Whatever the first Notepad-like editor was, that introduced the basic elements we consider to be standard text-editing controls today, is definitely historically notable also, and a great achievement -- it flattened the learning curve and (mostly) shattered modality.
Vim and Emacs don't have a lot to do with this browser project, despite the red herring of vi-like keybindings. This project is an experiment about building a browser that's really part of Unix, so as far as an analogous editor goes, perhaps Plan 9's acme, which also relied on external scripts for much functionality. The point isn't to be the greatest or most impressive anything, because... really, who cares? The point is to be a useful tool within the Unix system. If a more self-contained browser is easier to use in many cases that doesn't make it useless.
You missed the part about the Unix philosophy, which is "Do one thing, and do it well". It browses the web, apparently very very well. But storing cookies for later use isn't really browsing, now, is it? Neither are favorites or bookmarks or history and all that. If you want that stuff, you have to write scripts for it.
Neat idea, I'd never use it though. Too lazy.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
You missed the part about the Unix philosophy, which is "Do one thing, and do it well". It browses the web, apparently very very well. But storing cookies for later use isn't really browsing, now, is it? Neither are favorites or bookmarks or history and all that. If you want that stuff, you have to write scripts for it.
Until you want to implement something like a privacy button. It needs to clear the disk cache. It needs to clear the cookies. It needs to clear the autocomplete for the navigation bar. It has to delete the page history. But you don't want it to nuke your bookmark database, so you can't just make a "purge all". What's one thing for the user isn't one thing for the developer, which is why you end up building monolithical applications.
Live today, because you never know what tomorrow brings