On Sat, 27 May 2017 10:25:55 +0000
sylvain.bertrand_AT_gmail.com wrote:
Hey Sylvain,
> I got the urge to recall that obvious to people here, coze it's
> discussing way too much on the surf front-end without anything done
> on solving the real pb: the web engine.
it has been settled years ago that the task of surf is to provide an
as-clean-as-possible interface to the sucky web.
In fact, the web and the mess we have with compilers is easily
comparable. In both cases, the problem is the fact that the data passed
to these programs has become a huge mess.
The web on the one hand has become a conglomerate of hundreds (!) of
web standards, which even Mozilla is struggling to follow with their
army of developers. It's the reason why they even dumped Thunderbird.
The web is a moving target, and even if we tried to pursue it, we would
be a bicycle chasing a racing car.
Compilers are the same thing. If we even tried to develop a compiler to
suit all use cases, we would have to add GNU extensions, and lots of
them. There needs to be a whole paradigm shift, and people need to stop
writing code that depends on these ugly extensions.
I don't see it coming, and we have tons of legacy code lying around
which won't just change magically.
Roberto will be much better in explaining it, but implementing GNU
extensions also complicates the parsing of the code. It won't happen,
and it's a very painful truth.
> I accounted for 3 other similar/critical issues while building my
> minimal custom distro:
> - the linux compiler, gcc, is slowly and surely turning into a c++
> pile of sh*t. (I was unrolling c++ into C from its libcpp component
> the other day, I can see now that c++ in gcc is the work of sick
> minds or/and gangsters).
The data structures in gcc were broken right at the start when they
chose to do pseudo-OOP in C while developing gcc. It's not a surprise
given it's the FSF, which is even able to bloat true(1) into an 80 LOC
monstrosity[0].
> - llvm (which, unlike gcc, has been a c++ pile of sh*t right from
> the start) is one of the worst pieces of software I have ever seen,
> and if you want to compile GPU shaders you must have it.
The only reason I have llvm installed is due to afl, which has a hard
dependency on clang. I haven't investigated it yet, but hope that it
may be possible to cut out the clang-part from afl in the Gentoo ebuild.
> - harfbuzz, the _only_ unicode layout engine which has an interface
> changing all the time, and a brain damaged implementation. I did a C
> partial port from c++, and I can tell you about it is that the guys
> behind this code are trash. All GFX toolkits are dependent on it, all
> web engines are dependent on it, that for unicode layout computation.
Just mentioning its name is a sin.
> The new obvious is: suckless is losing ground on critical pieces of
> software.
No, the problem is that we haven't been around early enough. Imagine
suckless happening 10 years earlier; the GNU coreutils wouldn't have
stood a chance and we could've even had strong influence on the Posix
standard.
But as it is with hypothetical arguments, they won't move you forward.
Given our limited numbers it is our fate to provide simple and
relatively isolated solutions for common problems. Look at dwm, st,
slock, dmenu, sent and if I may, farbfeld. They all serve one purpose
in the hope that more people pick it up and integrate them in their
software. Back in the day, in the 90's, the FSF had a field day getting
people to make their software dependent on FSF's.
Nowadays, we have musl, an obviously superior alternative to glibc. And
even there we have trouble, because so many people use GNU extensions,
and to a certain extent, musl included GNU extensions to support common
software, so in a way they bent over and accepted it.
To prevent new code from depending on GNU extensions, I'd probably as
the musl developer print warnings at compile time when such
functionality is used (as an idea).
> What seems to be the only way to get alternatives to those
> components: several teams of several commited to suckless philosophy
> devs in a clear and sane full-time "comfort zone" for several years.
> Coze, on the other side, many of them are full-time employees in huge
> corporations/fondations with a luxuary visibility and luxuary comfort
> zone.
This is not possible. For a proper layouting engine, you need hundreds
of people just to keep up with standards. Even Google is struggling to
keep up with it.
It's also understandable that many people, even developers within the
suckless sphere are using web services that require a lot from the
browser. Just accessing Google Docs is impossible with a homebuilt
layouting engine unless you really invest into the ugly depth of web
standards.
As mentioned above for the software world, there needs to be a paradigm
shift for the web away from web applications to proper native
applications.
Most people don't even know that back when Apple introduced the
first iPhone in 2007, there was no App Store. They wanted to build
everything around web applications. A few months later, they saw that
this would only lead to chaos and introduced the AppStore for iPhoneOS.
Hoping for a paradigm shift for the entire web is unrealistic.
Encapsulating oneself in custom networks just isolates you from the
public and is not a proper way to kickstart a paradigm shift unless the
new solution provides crazy benefits over the existing one. Privacy and
simplicity though are not goods highly valued among the common folk,
and thus, this kind of paradigm shift will remain a dream.
Accepting this truth is difficult, but I think the only way to have a
realistic outlook on our role in the software world.
With best regards
Laslo Hunhold
[0]:
https://github.com/wertarbyte/coreutils/blob/master/src/true.c
--
Laslo Hunhold <dev_AT_frign.de>
Received on Sat May 27 2017 - 12:50:52 CEST