On Sat, 27 May 2017 12:34:14 +0000
sylvain.bertrand_AT_gmail.com wrote:
Hey Sylvain,
> It seems that EU (I'm french) is not able to secure a *proper*
> "comfort zone" to let us release our coding power.
>
> I did investigate EU funding seriously though, but what I got my
> hands on, are jokes, real f*cking jokes.
>
> I perceived like some "forces" are blocking any attempts at funding
> significant and realistic setups for those projects (in the huge
> economy which is EU).
>
> IRL matters forbid me to have a clear mind and more, that in order to
> code something significant (my IRL is indeed accelerating towards
> total destruction). I feel totally castrated and unable to express my
> skill sets: 2 people which were closed to me, literally told me that
> I should drop open source software if "I don't want to die"...
in the end, the EU is literally run by corporations, and thus most
decisions are based on their interests. It's easier to make money with
horrendous software solutions, both by selling the software itself and
by providing support or even solutions for problems that this software
makes.
> That said, since the coding solution seems way to far away, and our
> amazing legal system is supposed to protect the small against the
> big, on the WEB front, I'm actually preparing to go the legal way on
> critical web sites (I'll ask first nicely, coze not all of them are
> gangsters or sick minds, they just have a lack of perspective).
>
> Most of the critical web sites can have a noscript portal for "dirt
> cheap". Those web sites with a "service" too far away from a noscript
> web portal (a "rich interface is kind of mandatory"), they could
> provide a simple web service/network protocol interface (which do not
> depend on current web engines like this insult to sanity which is
> OAuth).
Going the legal way is easiest by blaming these websites for being
inaccessible. It depends on the legislation, but I'm sure there is some
leeway in France to sue JS-heavy sites for not allowing screenreaders
to properly interface with them.
> On the compiler front, many uses of GNU extensions may be fixed in
> the original code with alternatives, but the one which is mandatory
> and big for performant kernel/libc programming is in-line assembly.
> Replacing in-line assembly with assembly function calls will very
> probably kill fast-path performance in many cases.
Again, Roberto is the expert to ask here. Maybe it could even be
possible to somehow develop a translation layer for GNU extensions to
C99 code.
> On GPU shaders, no salvation, a SPIR-V compiler has to be written
> from scratch and some mistakes in the specifications made it far from
> trivial. But it's far from the abyssal work needed on the web front
> (to keep complexity in check, you must pre-build the vector control
> paths from blocks).
I honestly don't have a lot to do with GPU shaders. What's wrong with
OpenCL?
> On unicode, well, to keep it reasonable, just a lean implementation
> limited to roman like languages will do for the time being... but its
> trash coders are changing its interface more often than linux kernel
> interfaces for no reason. (need to have a look at harfbuzz-ng though).
A relatively sane subset of Unicode is to keep all this localization
stuff out and just use the basic tables. Still, it's a huge mess, but
so are languages.
With best regards
Laslo Hunhold
--
Laslo Hunhold <dev_AT_frign.de>
Received on Sun May 28 2017 - 13:39:58 CEST