On Fri, 29 Apr 2016, Christoph Lohmann <20h_AT_r-36.net> wrote:
> Greetings.
>
> On Fri, 29 Apr 2016 17:58:08 +0200 Jochen Sprickerhof <dwm_AT_jochen.sprickerhof.de> wrote:
>> Hi,
>>
>> just saw this commit:
>>
>> http://git.suckless.org/sites/commit/?id=6e3450a047c5f7eda300f68814f7b1dfd499119e
>>
>> Can someone (_AT_Christoph) please specify which version of Webkit and which
>> packaging is meant and what are the symptoms of hell?
>
> The pure insane size of the webkit source and compile system makes it
> uninteresting for an average user to compile webkit on his/her own. This
> stalls any try to patch, extend or strip down webkit.
>
> This basic fact forces users into binary packaging, which – especially
> for webkit1 –, is bad and tends to have a dependency on all Open Source
> projects out there.
>
> The symptoms of hell (They can be applied to other projects too.):
>
> * Crashing without an easy way to debug it
> * You need to download hundreds of megabyte of source for webkit and
> of course compile it, for debugging it.
> * This leads to no motivation in fixing.
> * The bigger the project, the more »magic thinking« happens.
> * Magic only leads to Arch Linux help forum content.
> * Dependency subhell
> * Here's where the catholic church banned all unborn children.
> * Download and debug all the APIs in need is not possible except for
> the person who is working for money on webkit.
>
> Conclusion: If you reach the stage of too many dependencies or code,
> which can only be changed by the one who wrote it, remove your project
> and leave the software industry for something productive. Your future
> hobby enthusiams will keep the project size small, just by practical
> means.
>
>
> Sincerely,
>
> Christoph Lohmann
So Webkit is problematic.
What would it take for a basic, sucks-less-than-webkit, web engine?
I don't mean to run GMail, but just basic web browsing: render text,
follow links, show images, terminal or X.
- HTTP client lib (is libcurl ok? oops no! 70k sloc!!!)
- Basic XML / HTML parser lib (simple, hand-rolled, recursive descent?)
- Basic layout engine, rendering frontends (text/md dump, terminal, X)
- Sandboxing (pledge, cgroups, privsep, etc? What can each OS give us?)
Things NOT to do:
- Silly security / privacy holes
- JS, JIT, other insanity
- History, bookmarks, password manager, ... external scripts if needed
- Caches (use a local caching proxy)
- Going over N thousand lines of ANSI C (find N)
Things to consider:
- Scriptability, "being UNIX-y"
- HTTPS - is it possible to sandbox the crypto code?
- Cookies - necessary evil? Reject 3rd party cookies by default?
- Basic CSS? How much CSS support is too much?
- Threads? Processes? Async IO? Best way to fetch / process / render w/o
freezing the UI? fork + pipes sounds least silly...
Would such a project make sense? Surf is the practical approach where we
have 95% of modern web working OK, at the cost of dealing with a huge
pile of suck.
What about a slightly more radical approach, where we have 95% of only
what we care about working OK, and reduce SLOC by 95%?
What about w3m? lynx? They're 50k, 84k sloc respectively. Maybe a good
place to start? Don't know yet.
Also I'd like to apologise for the empty talk without any code, I don't
have time right now to do a prototype, also everyone would hate it as it
would be in Python :)
K.
Received on Fri Apr 29 2016 - 22:25:48 CEST