On Sat, 27 May 2017 10:25:55 +0000 sylvain.bertr...@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 <d...@frign.de>
