Forgot your password?
typodupeerror
The Internet Unix Linux

Meet Uzbl — a Web Browser With the Unix Philosophy 318

Posted by timothy
from the simple-if-you-know-how dept.
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."
This discussion has been archived. No new comments can be posted.

Meet Uzbl — a Web Browser With the Unix Philosophy

Comments Filter:
  • Really fun browser (Score:3, Interesting)

    by Minozake (1227554) <ltdonny@gmail.com> on Saturday September 05, 2009 @04:54PM (#29326709) Journal
    This is a really fun web browser to tinker with. However, I'd recommend people should use a backup browser until they get it up and functioning to their specific needs. I'm still trying to work around with the cookies scripts, myself.
    • I'm still trying to work around with the cookies scripts, myself.

      So, it really doesn't work "very well" yet.

      • by Bigjeff5 (1143585) on Saturday September 05, 2009 @10:28PM (#29328667)

        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.

        • by Jared555 (874152)

          All it takes is having someone release a program dedicated to bookmark management, etc. If the browser gets more popular it is likely you will not have to write your own scripts.

        • by Kjella (173770) on Sunday September 06, 2009 @12:07AM (#29329133) Homepage

          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.

  • by wampus (1932) on Saturday September 05, 2009 @04:57PM (#29326719)

    Worse is better!

    • by Brian Gordon (987471) on Saturday September 05, 2009 @05:12PM (#29326819)

      Even if few people use it, the world's always better when someone writes an interesting app.

    • Re: (Score:3, Insightful)

      by wizardforce (1005805)

      how is designing software to do more things badly superior to focusing on creating software thatdoes its one and only job better? The more things software is asked to do the higher the chance that it will do at least some of those things poorly.

      • focusing on creating software thatdoes its one and only job better

        I think you agree more with the Unix philosophy than you realize. From the summary:

        Unix Philosophy: 'Write programs that do one thing and do it well...'

      • Re: (Score:3, Insightful)

        by Abcd1234 (188840)

        Dude, we're in a world of shitty phones that are also shitty music players, shitty still cameras, shitty video cameras, and shitty PDAs. And you're surprised that people don't understand the idea of a well-designed, single-function device?

        • A single executable that forms part of a UNIX application doesn't take nearly as much physical space as a dedicated device. It takes more pockets to carry a dedicated phone, a Nintendo DS, an MP3 player, etc.
          • by Abcd1234 (188840)

            And that's great if your goal is to experience shitty phone calls, shitty pictures, shitty video quality, and shitty audio quality. But if your goal is to perform one of those tasks well (like, say, web browsing), then it makes sense to sacrifice convenience for quality.

            'course, that isn't most people's goal. But, again, given that, one shouldn't be surprised when someone doesn't understand a philosophy where it is.

      • Re: (Score:3, Insightful)

        by Blakey Rat (99501)

        how is designing software to do more things badly superior to focusing on creating software thatdoes its one and only job better?

        And what's the "one thing" a web browser is doing, exactly? In the last week, I've used a web browser to:
        * RSVP to a event invite
        * Send/receive email
        * Watch TV shows
        * Share photos with relatives

        A "do one thing and one thing only" philosophy is fundamentally incompatible with the web. Unless you define your "one thing" as "view the web," which is so all-encompassing as to be useles

        • Text and hyperlinks man! Anything that goes beyond the functionality of Lynx is too far!
        • by A beautiful mind (821714) on Saturday September 05, 2009 @08:26PM (#29328055)
          You are thinking on the wrong abstraction level.

          A browser should implement HTML4/5, various XHTML versions, Javascript, support various multimedia protocols and that's it. Everything else can be integrated as a plugin.

          The Unix philosophy would demand separation of the code that implements all of this from the actual UI.
          • Re: (Score:2, Insightful)

            by Anonymous Coward

            Why should the rendering engine have to implement JavaScript or a multimedia protocol? A real Unixish browser would be composed of one component that only renders HTML, another one that fetches files and caches them, plug-ins to implement scripting languages and multimedia, and a shell that wraps everything in a GUI to manage bookmarks/history.

            In other words, it would be implemented like IE.

            dom

      • by hairyfeet (841228)

        Because you are dependent on what some designer decides that "one job" should look and behave like? Most of us don't have time to rewrite major portions of the browser, the place where many of us spend a large portion of our time, just to get it to work in a way that is comfortable to us.

        That is why even though I still keep Kmeleon and Seamonkey for specific tasks (older machines and banking) and am constantly trying the "new thing" like Safari and Chrome I always come back to Firefox and use it for my day

      • Worse is better!

        how is designing software to do more things badly superior...

        Whoosh [jwz.org]

      • by Jurily (900488)

        The more things software is asked to do the higher the chance that it will do at least some of those things poorly.

        Interestingly, this browser also demonstrates this. Vim-like key bindings? Really? Show me one person who uses the keyboard for browsing and doesn't expect F5 to reload the page.

        They quite clearly broke the Rule of Least Surprise.

    • by Draek (916851)

      Close, but not quite. It's "less is more", and if you knew anything about software development you'd know how productive such a philosophy is.

  • by DiamondGeezer (872237) on Saturday September 05, 2009 @05:02PM (#29326747) Homepage
    I suggest NUZBL.
  • Web Browser? (Score:3, Insightful)

    by RalphSleigh (899929) on Saturday September 05, 2009 @05:02PM (#29326749) Homepage

    So it's not a web browser, but rather a HTML rendering widget you can use to write a web browser, or use in other programs? I think .NET has one of those based on the I.E engine...

    • Re:Web Browser? (Score:4, Insightful)

      by Trepidity (597) <delirium-slashdot@@@hackish...org> on Saturday September 05, 2009 @05:19PM (#29326887)

      It's somewhat in between, like most Unix-style tools. It's usable as-is as a basic web browser (you can browse the web in it). It's also usable as a tool to build other things out of, but in the "app that other apps can talk to" sense, not the .NET or Java "a class library that you can link your apps to" sense.

      It's partly a philosophy of general- versus special-purpose end-user programming, monolithic vs. interlocking-parts design, etc. No real right answers, but I see a space for this. In particular, those of us who like a particular window-manager approach, and heavily use its scripting, have long complained that the web is sort of a black box out of our reach--- either you make do with what you can do with wget or links or something, or you've got to relinquish control to Firefox. Sometimes you really do just want a one-window X11 app that renders a modern web page.

    • by ceoyoyo (59147)

      WebKit is one of those (and it's cross platform). And this thing is based on WebKit.

  • Novel ideas usually don't live on by themselves unless they become useful. The worst thing the developers did (besides the name) was create a "steep learning curve" for the common web browser. The best thing the developers could do is work with an existing product that already has market share and works great like Chrome (also based on Webkit) and make their additions to it in support of better key bindings.
    • by Goaway (82658)

      I think it's pretty clear the creators are not much into this "common sense" thing when they decided to make "a web browser with the Unix philosophy".

    • by Brian Gordon (987471) on Saturday September 05, 2009 @05:15PM (#29326847)

      The goal isn't to gain popular market share.

      • by Sir_Lewk (967686)

        Mod +1 informative. Why do people seem to think the only reason developers create something is to get market share? Seems about as sensible as bashing an artist's work because "it will never become as famous as the Mona Lisa"

      • by icepick72 (834363)
        However popular market share often brings other side-effects and benefits like project longevity, involvement and significance. I wouldn't mind running Uzbl's awesome features on any platform that (for example) Chrome runs on, and I likely won't use two browsers at the same time to get both sets of features.
        • Well, Arch [archlinux.org] has a very active developer/user group of exactly the type of people who would use this browser. I think they have a majority of a very solid niche market.
    • by retchdog (1319261) on Saturday September 05, 2009 @05:16PM (#29326855) Journal

      I don't think they're looking for standard users, and kind of the whole point was to create a learning curve. This implies that it's targeted at powerusers and developers. With the script-integration, this could be useful for quickly churning out a limited-use kiosk with a few helper apps or something (e.g. a novelty photo booth with web integration).

      Anyway, the price is right.

    • by gbjbaanb (229885)

      Yes, but you could say the same about the Chrome developers - the best thing they could have done is work with an existing product that already had market share and works great like Firefox.

      and I guess we could say the same about Firefox..

      No, if this has some additional features that makes it better, like being as tiny as you can get, drivable through a text stream API, being able to fit it into windows so you can have your web browsing embedded into your desktop window manager, then it might yet become a

      • by icepick72 (834363)
        ...with the exception that Chrome and Firefox are similar browsers whereas Uzbl is comparatively obtuse. I'd suggest Uzbl work with an existing "normal" (may I use that word?) browser because it seems they provide an addition/enhancement/supplement to the rendered browsing experience. Firefox and Chrome were meant to compete not enhance.
      • by s4m7 (519684) on Saturday September 05, 2009 @05:33PM (#29327005) Homepage

        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.

    • by causality (777677) on Saturday September 05, 2009 @05:24PM (#29326937)

      Novel ideas usually don't live on by themselves unless they become useful. The worst thing the developers did (besides the name) was create a "steep learning curve" for the common web browser. The best thing the developers could do is work with an existing product that already has market share and works great like Chrome (also based on Webkit) and make their additions to it in support of better key bindings.

      That depends on whether the goal is to obtain the largest possible marketshare. If that is the goal, or if that is your sole definition of "useful," then what you say does apply. If they don't give a damn about competing head-on with the likes of IE or Firefox then what you say is completely irrelevant. What I don't understand is the (usually) unstated assumption that marketshare numbers are the only reason why anyone creates any piece of software. While it's important in terms of attracting developers and, in the case of browsers, for putting pressure on Microsoft to make IE more standards-compliant, there are many reasons why someone might write a browser and this includes reasons that wouldn't personally motivate you.

      I see the same sentiment shown when some people discuss Linux as though its only purpose is to compete with Windows. They then act like Linux is a complete and utter failure if it doesn't bust up the Windows desktop monopoly. I disagree with this; Linux just "is." If it happens to displace Windows, that's great. If it doesn't, that's fine with me too. Though I have happily introduced folks to Linux who showed an interest in it, I'm not out to win converts; I just want something that works for me. There are those of us for whom Linux is a good solution, who have no dependency on any Microsoft products, and who are able to do our computing completely aloof from Microsoft, unaffected by any decision Microsoft makes. It's abundantly possible that this is intended to be a niche browser, designed for the relatively small number of users who are technically inclined and willing to tinker with something like a Web browser and its supporting scripts.

    • by Trepidity (597)

      The issue isn't better key bindings, but the external controllability and API. Some proportion of us don't like the monolithic black-box approach, where the web browser is this big thing that does everything internally, and if you want to automate or customize anything, you have to do it via the browser's own internal scripting or customization hooks. Some of us like the idea of doing things at the WM and CLI scripting levels.

      This is admittedly a sort of radical approach to that. It's possible there are in-

      • by icepick72 (834363)
        But wouldn't it be nice to have the full-featured and expected GUI browser experience with these additions? With Uzbl the choice it using it for advanced features, a second browser for ease-of-use (full GUI) but most users will choose one and not bother running both. Personally I'd like to see the Uzbl features made available as advancements to existing browsers instead of creating a new one which has inherent GUI limitations. Regular users won't ever see this programmable browser and yet we as developers w
        • by ultrabot (200914)

          Personally I'd like to see the Uzbl features made available as advancements to existing browsers instead of creating a new one which has inherent GUI limitations.

          This is written in python. If they bolted the functionality on ff/chrome, they would have needed to deal with js and c++. I guess it was just easier this way.

    • The worst thing the developers did (besides the name) was create a "steep learning curve" for the common web browser.

      Except this fits into the whole unix philosophy bit: unix tools tend to have a steep learning curve but be extremely easy and fast to use once you know a certain number of arbitrary assignments. I know "steep learning curve" isn't part of the philosophy, it just tends to be part of how things play out. Examples: vi, sed, hell even the switches for something like ls.

  • They really really need a new name. There's no way that thing is going to be marketed successfully. Not even if the software itself was able to power web4.0 apps, skipping web3.0 alltogether.

    • by Gonoff (88518)
      Like everyone else is saying. maybe they don't want to market it at all.
      It sounds like 'blue sky' development. I imagine someone wondering "What if I just..."
      The more of that happens, the more things are tried out and the advantage od OSS is that everyone can find out how it is done and nobody can stop others from improving on it - apart from by saying it's a stupid idea.
      Of course, it could also be the result of using mind altering chemicals - which is also not always a bad thing
    • by Draek (916851)

      If you care about the name, you're not part of their target market.

    • Re: (Score:2, Interesting)

      by techprophet (1281752)
      It's not being marketed. At all. STFU and go back to Firefox. This isnt for the masses. It's for us geeks who like slender forms.
  • vi? (Score:5, Funny)

    by clang_jangle (975789) on Saturday September 05, 2009 @05:12PM (#29326821) Journal
    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.
    • Re:vi? (Score:5, Informative)

      by clang_jangle (975789) on Saturday September 05, 2009 @05:23PM (#29326919) Journal
      Oh wow, now I've gone and looked at it and it's really cool! It's a collection of python scripts, so it should run on pretty much anything. And yes, keybndings (and most everything else) are easily reconfigured -- if you know python.
      • Re: (Score:3, Informative)

        by Anonymous Coward

        There's no constraint that says you need to use python. You can you /any/ programming language that can read/write text files.

  • About damn time (Score:2, Interesting)

    by the_kanzure (1100087)
    About damn time, I say. For the past few years I have browsed the web with hundreds of tabs at a time. Firefox tends to crash after 50 tabs. Opera tends to crash at about 450 tabs. Some of this varies with RAM, but we're all familiar with the firefox single-thread issues, which really puts a downer on things. Let the window manager do its job: tabbing is for losers. Also what's with the insistence on keeping all tabs in RAM anyway?

    I've been working on some scripts to use with uzbl .. in particular, I hat
    • 50 tabs? (Score:3, Funny)

      by ArchieBunker (132337)

      What are you doing that requires 450 or even 50 tabs for that matter? You sound like an RMS nutjob.

    • by Abcd1234 (188840)

      For the past few years I have browsed the web with hundreds of tabs at a time. Firefox tends to crash after 50 tabs. Opera tends to crash at about 450 tabs.

      No offense, but that's truly idiotic. Seriously. As the doctor once said, if it hurts to do that, *don't do that*.

      Honestly, let me introduce you to two concepts: Bookmarks, and Read It Later [readitlaterlist.com].

    • Let the window manager do its job: tabbing is for losers.

      Firefox became popular back when Windows 98 was still supported. In Windows 98, there was a concept of "System Resources", involving two 65,536-byte heaps called "user" and "gdi". A new window took a lot more out of each heap than a new tab.

  • Yes, but (Score:2, Interesting)

    by mujadaddy (1238164)
    Does it run on Windows?
  • by 93 Escort Wagon (326346) on Saturday September 05, 2009 @05:21PM (#29326903)

    The learning curve is a bit steep...

    Yup, say no more - that's the Unix philosophy in spades.

    • by DigDuality (918867) on Saturday September 05, 2009 @05:29PM (#29326973)
      it has been my experience that everything regarding steep learning curves in *nix, ends up revealing benefits those who never try will never know of. Try explaining to the average windows user how vim is better than notepad vs watching someone learn vim and having their face light up everytime they figure out they can do something very quickly that's impossible in a standard text editor
      • Notepad is, and was designed to be, an extremely basic text editor. It doesn't have lots of features not because those would necessarily make it hard to use, but because they'd take resources to develop. It is just a simple program to display a text file, little more.

        Now compare Vim to something like UltraEdit. Here you have a tons of features. Maybe even more than Vim has. However it is still simple to use the basics. You can fire it up and open up a file and edit it with no more effort than notepad. It is

        • by Trepidity (597) <delirium-slashdot@@@hackish...org> on Saturday September 05, 2009 @07:42PM (#29327791)

          I challenged him to show me something it could do that UltraEdit couldn't.

          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. =]

          • Re: (Score:3, Insightful)

            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?

            You make requests in a way that predetermines the answer. For example, what's a "usable macro language"? And, obviously, there's no Notepad (or UltraEdit) on Android, but a clone could be easily written, and yes, it could also work over ssh - there's nothing specific about Vim design that enables it to work better over ssh than any other text-mode editor.

            At the same time, any decent editor these days lets you do fairly complex things without using mouse. Even though for a large number of such things, using

        • by Al Dimond (792444) on Saturday September 05, 2009 @08:40PM (#29328133) Journal

          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.

        • by Draek (916851) on Saturday September 05, 2009 @09:04PM (#29328241)

          The real challenge to good software is to make things as easy as possible, and make it so the complicated doesn't interfere with the simple.

          When they're designed for ease of use. When they're designed for *efficiency*, however, as ViM is, the challenge is to keep the complex possible while making the simple as fast as you can. How easy it is to learn never enters into the equation.

          The editor designed for *power* is Emacs, whose LISP interpreter can't be beat in that department.

          • Re: (Score:3, Insightful)

            When they're designed for *efficiency*, however, as ViM is ...

            Vim commands weren't designed for efficiency; like traditional Unix command names, they were designed for terseness [wikipedia.org] to remain usable over slow (think 300 baud) terminal connections.

        • by juuri (7678)

          everyone has their favourite tool. vi is incredibly powerful and comes standard on dozens of unix variants, the place it has, it has earned.

          your challenge is a bit off though, i can think of many things you can do in vi that you can also do in ultraedit or boxer or XXX, the difference being with vi, my hands never left the keyboard.

        • by petrus4 (213815)

          Our Solaris guy had to show me how it worked. He, like you, seemed to assume I'd love it once I learned about it because of its power. I challenged him to show me something it could do that UltraEdit couldn't. He wasn't able to come up with anything.

          You're correct. Vi(m)'s modal interface is a major design flaw, and it presumably does present a major stumbling block for the number of new users. Is Emacs possibly available for Solaris? It is not modal, and although I haven't delved deeply into it, seemed quite easy to use. There is also GNU Nano, if you want an open source editor. It is quite basic, but can still serve.

          The way I see it, for some of us, Vi(m) does have a few good points, however.

          - Nvi (that is, BSD vi) has an executable size of 300

  • Nitpicks (Score:5, Interesting)

    by SanityInAnarchy (655584) <ninja@slaphack.com> on Saturday September 05, 2009 @05:34PM (#29327013) Journal

    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.

    • Oh, and probably the strangest one: Suggesting a proxy-based adblocker.

      Ok, I get that it's practical, for now. However, they seem to be saying this would be preferable to an adblocker built in to the browser, which makes no sense. Being able to right-click on an ad and figure out how to block it is not going to be replaced by editing some obscure config file in privoxy.

      • Re: (Score:3, Insightful)

        It *is* preferable to have a separate ad-blocker, that should be a no-brainer within the unix philosophy. What you're thinking of is a client/server model where right clicking the ad in the UI (which UI? Maybe there could be several to choose from) should initiate a conversation with the ad-blocker daemon.
        • It *is* preferable to have a separate ad-blocker, that should be a no-brainer within the unix philosophy.

          Granted. But there are two large problems with it, in practice:

          Firstly, while it's not entirely in line with the Unix philosophy, my browser already parsed the page. Why should my proxy have to, also?

          And probably more importantly: Maybe this has changed, or maybe I just used the wrong proxy, but I remember using Polipo for a lot of things. I also remember finding out that it would cause certain pages to fail (even when I was just using it as a cache), and that, perversely, it'd often slow down my browsing.

          • Yeah, polipo has a few problems, but I'm surprised you find it actually slows things down? Perhaps you should increase the standard config settings, ie allow it to use a lot more RAM, in case you want to try it again. IIRC the default object sizes are too small for the average bloated^H^H^Hmodern webpage. One thing it does though is pull down complete images and other media pretty aggressively so if you like to hop from page to page really fast, I could see how it wouldn't keep up.
      • by k8to (9046)

        It is preferable in some ways. It works on all your browsers and can be updated independently. It can offer caching for free. It can block things that your browser doesn't recognize as ads.

        But as you point out, it's harder to make a good user interface for it. I used a proxy based ad blocker for many years, but have switched over to browser-based ones recently.

    • by pbaer (833011)
      Especially since if you don't like the config files being in the home directory you can just write some symbolic links, and you're good to go. At least that way, it's fairly obvious where they are the first time you look for them.
  • dupe! (Score:4, Interesting)

    by CODiNE (27417) on Saturday September 05, 2009 @05:50PM (#29327105) Homepage

    http://slashdot.org/article.pl?sid=98/02/24/114700 [slashdot.org]

    11 year old dupe article.

    Hmmm... as an aside... wonder why no posts there.

    • Re: (Score:3, Informative)

      by armanox (826486)
      Because the discussion system didn't exist back then on Slashdot?
      • Re:dupe! (Score:5, Informative)

        by Trepidity (597) <delirium-slashdot@@@hackish...org> on Saturday September 05, 2009 @07:57PM (#29327879)

        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 [archive.org].

        • by armanox (826486)
          Ah, was not aware. I started reading slashdot in 2001-2002, and think that I registered as a user in 2003-2004.
  • It's Webkit (Score:5, Informative)

    by PhunkySchtuff (208108) <{ua.moc.acitamotua} {ta} {iak}> on Saturday September 05, 2009 @06:10PM (#29327221) Homepage

    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.

    • Re: (Score:2, Informative)

      by petrus4 (213815)

      As mentioned above, Webkit isn't the most unix-like unix software being a big, monolithic program written in C++ .

      I was starting to think that I was the only person left who still cared about UNIX design philosophy, anywayz. Ubuntu's developers are all convinced they know better, and the single reason why is because the distro's end users never, for one single second, stop screaming about wanting system complexity to be entirely on the implementation, rather than interface side.

      So the interface for Ubuntu which the end-user immediately sees is really slick, sure; but going even a few milimeters under that exterior, ex

      • by Rennt (582550)
        Of course it's not just Ubuntu doing it. It all started when they decided everyone needed Desktop Environments instead of Window Managers, and its basically gone downhill from there.
  • wget? (Score:3, Interesting)

    by Joe Mucchiello (1030) on Saturday September 05, 2009 @07:02PM (#29327539) Homepage

    If it does more than wget, doesn't that mean it already has too many features?

  • Little programs connected by pipes, right. Back in 1978, that was kind of cool. Anyone remember when you got multiple columns from ls by writing ls | mc ? "ls" originally just produced a one entry per line list; if you wanted multiple columns, you used the "mc" filter to create them. Now, the feature list of "ls" is huge.

    Actually, UNIX and Linux are way behind in inter-program communication. Using pipes for message passing is like hammering a screw. Windows at least has a standard way for programs t

  • by Hurricane78 (562437) <deleted@slashd[ ]org ['ot.' in gap]> on Sunday September 06, 2009 @02:29AM (#29329605)

    On a more serious note:

    Why is it, that all the GUI desktops abandoned Unix's philosophies completely and instead went the Windows way (which of course actually is the MacOS/Xerox/$otherProductItGotTakenFrom way)?

    I mean, imagine how great it would be, if we had all the tools of Gimp, Openoffice, Firefox Add-ons, etc, as separate entities, only bound to a document / data trough its mime type. You could mash up and reconnect everything at will. Pipe stuff trough that wizard, and then trough that.
    Or connect a OOo tool and a Gimp tool trough pipes, and then draw with them, etc.

    Imagine it like this:
    - A global toolbox with all the
        - tools (something you "draw" with),
        - wizards (something that you apply to the selection/document) and
        - views (a view and controller for the model [file]).
    - A window for every view of a file.
    - A location bar, showing the current position/selection as an XPath.
    - A properties box, showing all the properties of the current element/selection.
    - The things in the toolbox would itself be normal files -- scripts or libraries implemented in every language with an API for it to be exact -- that you could show in views, edit with the properties box, apply wizards and tools to, etc.
    (Yes I got to this ideas a long time ago. I just got no time or money to implement it. If you do, please tell me. )

    You could build your own tools like with shell scripts. And because that would make it much easier to create new apps by slowly growing them, we would get much more innovation.
    Also it would pose no problem for those noobs who dislike the shell for no reason. :)

The major difference between bonds and bond traders is that the bonds will eventually mature.

Working...