sylware

Nope, I am blocked by anubis: javascript of recent whatwg cartel web engines (the worst of the worst).

I am looking for a noscript/basic HTML alternative front.

Any reddit noscript/basic HTML frontend alternative?

Well, with all the enshitified complex file formats out there, I bet this is a "piece of cake" (for the people of the field with good tooling) to find exploits in the state management of code dealing with them. And very high computer languages/specialized script languages won't protect anything as those are "logic errors". I think "closing" state machines on such complex file formats is just pointless, better design new file formats from the ground up, but this time with a much stronger focus on robustness (keep that state machine as small and simple as possible and super rigorously well defined, and I mean like maths maniacs). And it is hard: because the purpose of the file format must come AFTER the robustness, namely tough compromise on the purpose itself may have to be done.

Here, "regulation" is more about a "minimal platform for interop" than anti-trust.

That "minimal platform for interop" would be made of simple but able to do a good job enough and stable in time file formats and protocols. This minimal platform must be reasonably implemented with "Small Tech" (excluding de facto the whatwg cartel web engine and computer languages with ultra-complex languages or heavy runtime this is common sense).

That "minimal platform" should probably be made with subsets of current file formats and protocols. As I said, for instance a subset of PDF (with validation tools), mandatory handling of basic UTF-8 text files, no script/basic HTML for the web, brutally simple SMTP support (aka self-hosted, not paying for DNS, or email addresses with IPs literals, only the commands to send actually emails without fideling around), IRC bridge for chat, etc.

BTW, on the "assembly to save us", I was talking about very high level languages with interpreters/JITs coded directly in assembly (aka binary specifications), then Mr. Bellard quickjs, but also obviously python (but it seems its syntax is going amok which is bad omens)/lua/etc.

This "platform" should slow down a lot the endless enshitification cycle we are into.

If AI coding is that powerfull (cannot test it as its access is gated by the whatwg cartel web engines), it can probably help: like I said, since we are not alone, look at what the others like me did: they are using it to write transpilers from ultra-complex computer language syntaxes, I saw on HN this norvegian guy who is using AI coding to help write directly in 'human readable' assembly (here x86_64) the binary specifications of its own everyday software.

This plaform must be very rigid, but not completely, namely rational removal/restructuring could happen. Basically, implementation "from scratch" by "Small Tech" must always be reasonable.

Aside of all that, there is the ultimate hard truth: for much software developement, but not all, it is extremely hard to justify a permanent income and that honestly. Making all that very complicated to fit in any economy.

Here, only regulation can help, there is no going against corpos with billions of $ and backed by funds of thousands of billions of $. Much of Big Tech abuses non pertinent complexity and size, not to mention their manic usage of planned obsolescence. There, the regulation should secure and set in ice a basic subset of file formats and protocols for interoperability which are known to be reasonable to implement again from scratch with "Small Tech". And by subset, I meant for instance noscript/basic HTML for the web; UTF-8 text files for text; I guess JSON should be favored over XML; a subset of PDF (certainly not all of it...);etc. If an online service have a 'chat', a basic IRC bridge should be there with a properly display access URL, etc, etc. That does not block "new" and "innovative" things to happen in any way.

Some of Big Tech hates "small is beautiful" and stability in time then will fight hard with their $ for that not to happen (administration "corruption"). Complexity and size (including the SDK then the computer language syntax complexity) is their bread and butter to keep "control" and keep alternatives away.

For the "bootstrappable", it is the starting point of building from 'small and simple' toward big and complex, aka the SDK 'binary seed'. At the time anybody would expect a 'simple C compiler' with a simple linker and assembler buildable with that simple C compiler... but people at the gcc steering commitee and the usage of many C extensions without maintaining proper fallback to assembler source files (in kernels, hence linux) broke the chain of 'sanity' for good. Now you must have an ultra complex c++ compiler to "bootstrap" (~LFS), not to mention the required zillions of complex tools required by the "build systems". Lately, it seems AI coding may be the salvation here... How? AI seems to assist writting c++(insert you computer language with a complex syntax here) to simple C "transpilers" (somebody pretended to have done the same with a rust->simple C transpiler, was published here on HN). I have to say I have never used AI, since they are gated with the web engines of the whatwg cartel (I cannot even get a token to use some web API), I have never tested.

The conclusion: fixing the software stack to let sane small alternatives to 'exist' and be 'real life' is probably not going to be calm and quiet.

I did not get everything you said, sorry.

But where I do agree: I presented the "assembly saving the world from big tech toxicity" would come with very high level scripting languages (probably a mess... but less toxic than what we have today), but with their interpreters/JIT "compilers" written is such assembly without abuse of any macro pre-processor.

I gave some thoughts about porting Bellard quickjs to pure hand written/tool assisted RISC-V assembly.

In the SDK, I do include the "compiler": the computer language syntax complexity is critical here since it is a barrier of entry of any new "real-life" alternative compiler. NetBSD won't protect you here.

For this major reason, computer languages with a "simple" syntax and "alternative" real-life compilers should be favored (or you know it is reasonable to build one from scratch). The current _LESS WORSE_ alternative is C and similar. But this is far from a silver bullet. I think our only way out, namely getting rid of all this toxicity is assembly without abuse of any macro-preprocessor, that's why worldwide non-IP locked ISA standard like RISC-V are so much important.

Ohohoh! The complexity and cost of the various "open source SDKs" is on stellar scale. I build my own distro, and I usually remove SDKs to switch to linear orthogonal brutal build shell scripts... and I am going to warn you, you are going to see a lot of ugly close to insane.

You'll see also a good amount of more than questionable code generators. And when you will have a look at some _GNU_ makefiles of big corner-stone projects, you will question the sanity of their authors (the "makefile" itself is often, but not all the time, very questionable too nowdays). Everything was with a good intent, turned sour and painful on the long run.

On our modern computers, we should have "one-compilation-units" for most, if not all binary products (exes or shared libs) anyways. "Same language" binary static linking in the open source world should not be a thing anymore (have a look at those 'header-only' projects).

The invisible backdoor injectors (namely compilers) are a problem, for many reasons that most know here (barrier to implementation of real-life alternatives, [open source] developer lock-in, etc). The more complex is the syntax of a computer language, the worst it is (on c++ syntax complexity scale, or with a heavy/intrusive required runtime like many "new" languages do shove down your throat).

If you don't see any issue, get cproc/qbe C compiler (and the binutils gas assembler), then you compile linux (with a brutal and linear shell script, let's say for a real life x86_64 desktop) and we'll talk again after, ok? And once you succeed, we'll see how it holds in 7-10 years (the time ISO takes to break in a non pertinent way many things).

Well, in this very case, it is more complicated than that: they have to protect their software against planned obsolescence and developer tantrum (it would be the same for any "in production software").

Modifications and changes must be weighted very carefully. For instance "removing" (including in the SDK) is usually a less worse modifications than the others and it decreases the global technical size and complexity/number of layers of the stack/SDK (which is top priority in "security"), namely most of the time but not everytime a good thing.

Because, on most complex software (open source or not), a "believed" benign modification can be disastrous. It is even worse if close to bare metal involving complex hardware (even with massive QA[testing]).

The step by step is the right approach... but you'll discover that many 'components' are _INSANE_ and that includes their SDK.

Bare LFS is not enough (I run my own): you need a kind of userland (above glibc) multi-version system which some kind of "atomic-ish" switching (always have a stable SSH running in case something goes wrong, better than unplugging the system disk and fix it on another computer).

For linux, same thing, with a kind of flip-flop-ing for updates/fix/etc.

The insight that gives you will probably scare you: the current "open source" stack is an abomination (the worst is the SDKs I think).

That's why we need _LEAN_ open source, and that includes the SDKs.

I know (like selling software without official technical support), I was asking if actual and real hacking did occure.

In this case, they are probably big tech brain washed and lack a lot of experience/perspective.

I remember the time when I was warned again corpos: nice in the first decade, then nasty afterwards.

What's they were hacked and their current work in progress 'stolen'?

On my open source projects, there is always a big "WIP" messy phase which I don't "really" publish... because it is messy.

A elite dev is not someone who is "not doing any mistakes" (if that has a meaning in the first place)

A dev is much more likely to be qualified as elite when you look at how he/she handles his/her own 'real' mistakes.

Huh?

Re-using advances done by others is necessary in maths.

This is how hard sciences do progress.

Then if those BOTS are using whatwg web engines, what are your options?

Not to mention, they could be click farms with real humans behind, then what can you do?

It is much much worse than that: the real jail is the "web javascript" of the web engines of the whatwg cartel, well roughly speaking.

Then you are of extremely bad faith?

come on...

It is all about that single data point, which means that detector was big enough for that data point.

Ofc a timer will be set per connection and has to be only one part of a whole global and probably fine-grained connection policy !

Their only purpose compared to such timer, is, in their current state to create a hard dependency on exactly the web engines of the whatwg cartel and do exclude low end hardware (this does create a barrier of entry for new hardware or small hardware).

At least, they could have had the decency to design some "HTTP" specs to de-couple those maths challenges from those abominations which are the web engines of the whatwg cartel (maybe that's the case).

Yep, I could bet that a lot of BOTs are now based on those abominations (and probably using neural nets). You also have click farms with real humans.

There is so much wrong there... well Big Tech...

I saw bellard neural net compression benchmarks. If you have time and performant system, based on the semantic of the data to compress, neural net seems tough to beat.

It is a matter of good compromises: speed and efficacy. I even wonder if LZMA2 is worth replacing bzip2.

Isn't that XZ?

Real BOTs are more and more using whatwg cartel web engines, namely this has an end. If not all, namely the end was already reached. The ones not using them are more likely to be shadowpaid hackers by the whatwg cartel to ruin anything noscript/basic HTML (or they could be beyond idiotic hackers, unlikely).

Not to mention, many "maths challenges" out there are nothing more than a 'wait loop' in the end. Namely, you could replace them with a HTTP hard refresh timer with human scale wait times in order to get the same pertinent result. Those are actually even worse because they are pleasing the whatwg cartel since those are made to work only in their web engines.

The least they could do is to standardize those 'maths challenges' and make them HTTP header friendly.

They have to keep in mind: it will be more expensive (significantly, and in competent people, not only $$$) as you cannot beat big tech with their thousands of billions of $ and the fact they are scaled on a worldwide scope. And with a long term perspective, it is going to be even harder and more 'expensive': being independent and small has a price.

Just do not go on the ground of their "complexity", if you do, you are done for, going to be hell (specs subset only of file formats/protocols, and/or very simple alternative file formats/protocols, think docx vs utf8 text file).

And you better work on those technical regulations, and it is hard since it must not imped real and pertinent "progress".

Keep in mind that those front-ends are, in general, much more friendly towards noscript/basic HTML browsers than the official front-ends broke a few year ago. (well, nitter was at the time)

Don't think the 'whatwg cartel' will let some web not require their web engines.

Expect shadowpaid hackers to ruin their infrastructure. Don't be a fool, expect the worst (more so when the whatwg cartel is involved).

And if you, yeah you! If you are running an "AI scrapper", have the decency to preserve those front-ends (or get the code and run it yourself).

I don't recall to have had a twitter account.

Because it has been hostile to noscript/basic HTML browsers.

I could use a web API with some token, but it is impossible to create an account and generates such API tokens without a web engine from the whatwg cartel.

So this is a big enough detector? That would mean they need to wait for such events to occur again and again towards this "5sigmas".

Hopefully, other aparatus elsewhere are big enough too in order to spot similar events.

This is statistical significance ! WE NEED A BIGGER DETECTOR! GI'ME MONEY!

The javascript web is. Restore the interop with noscript/basic HTML and it will lean towards sanity, something lost a few years ago.

There will be RISC-V implementions specific to many use cases of CPUs.

I have to admit we were more in the "desktop" use case, then the 7GHz (I don't know how they will manage to keep the backend reasonably fed without severe speculation though).