Re: [dev] stali and static surf binary

From: Ersin Akinci <>
Date: Sat, 15 May 2010 21:09:09 -0400

You're correct, my intentions are quite different and have nothing at all to
do with performance concerns. I'm trying to manifest a certain aesthetic
vision: I like the act of downloading static binaries and deleting them
without worrying about dependencies, complicated directory structures, etc.
stali's web page also implies that the goal isn't just completely focused on
performance, especially when you read the proposed directory structure
(i.e., "/proc: linux stuff").

Heh, yeah dillo would work, but really dillo isn't a solution. It's
admirable for what it is, but I need a full-featured, statically linked
browser. I figured that if anyone would know how to do that it would be the
stali dev(s). No idea if it's being actively maintained or not.

On Sat, May 15, 2010 at 8:08 PM, anonymous <> wrote:

> On Sat, May 15, 2010 at 05:11:48PM -0400, Ersin Akinci wrote:
> > Thus, dynamic libraries would still be used, but at least they would
> > be duplicated, independent, and isolated for each program that needed it.
> What problem you are trying to solve? You want to make binaries
> independent from environment so you can get your directory with
> program and it's libraries and run on every Linux machine? I think
> main goal of stali is to get rid of complex dynamic library loader and
> make loading faster. Looks like you are trying to use static linking
> for different purpose.
> If it is too hard to compile these complex web browser engines, it is
> possible to switch to Netsurf or Dillo. Dillo uses FLTK, it is
> developed for static linking from the start. Browser engine is
> internal so there is no problem. These browsers are not so functional
> as WebKit-based browsers like surf but they are more simple in fact.
> BTW there are no commits to stali repository recently, it is developed
> privately or it is not developed now?

What Digital Revolution? --
Thinking critically about digital worlds.
Received on Sun May 16 2010 - 01:09:09 UTC

This archive was generated by hypermail 2.2.0 : Sun May 16 2010 - 01:12:01 UTC