pmarin

It used Maxima many years ago.

The arena is replacing the javacript garbage collector not memory managament.

WHy not just add a hardware switch to allow Android sideloading?

Are these multibillion companies so incompetent to not think about it?

I am sorry if I mistaken you for a bot but the model you are describing have not been implenented by any graphic driver in decades.

Just to be clear the hardware abstraction layer used by wayland and any current Xserver is exactly the same.

i don't think it has a huge impact on the discussion here. but this is such a key difference versus X, that i think is hugely under-told: Wayland compositors all rely on lots of kernel facilities to do the job, where-as X is basically it's own kernel, has origins where it effectively was the device driver for the gpu, talking to it over pci, and doing just about everything. when people contrast wayland versus X as wayland compositors needing to do so much, i can't help but chuckle, because it feels like the kernel does >50% of what X used to have to do itself; it's a much simpler world, using the kernel's built-in abstractions, rather than being multiple stacked layers of abstractions (kernels + X's own).

Are you an AI bot? Modern X11 server using DRM are more than 20 years old. You are talking about how X11 servers worked in the 90's

I don't think is about China, it's more about Winnie the Pooh's legacy.

The C way is to avoid abstractions in first place.

C++ compile time execution is just a gimmicky code generator, you can do it in any language.

That sound more like software pseudo-engineering to me.

How many people know about https://lite.duckduckgo.com/lite/ ?

Is a version of DuckDuckGo without Javascript. Very fast and compatible with minimalistic web browser like lynx.

That sound more like a demake than a port. Very cool anyway.

20 years on Debian. Not a single crash with apt

I don't use a compositor in XOrg.

Win32 has already a pretty good opengl 1.2 software renderer.

Archive.org because jwz doesn't like HN.

He updated it later on:

"Update: On June 8th, 2024, I submitted this privacy policy to Google, and on June 10th, they accepted it. I take this to mean that they found it to be 100% factual and endorse it entirely. XScreenSaver was restored to the "Play" [sic] store, and people were able to again downloaded and enjoy it freely.

But then!

Barely 6 weeks later, on July 24th, 2024, Google instituted yet another new policy: basically they told me that if I didn't give them a sample of my blood a copy of my driver's license, they would remove XScreenSaver from the "Play" [sic] store, again.

Obviously that's never going to happen. Do I, the person who wrote the above list cataloging Google's various predations, seem like the sort of person who would willingly give Google my private details? On purpose? I do not think so.

Having distributed XScreenSaver for over a decade to I-don't-even-know-how-many users (I actually don't know, I never looked) Google suddenly decided that it was a huge problem that they don't have a lock of my hair.

Since I enjoy wasting the time and money of multinational superpredators, I spent a few weeks going back and forth with what passes for developer "support" over there. You can read about it over on my blog. Eventually they just started ignoring my emails, and in November 2024, XScreenSaver was again de-listed from the Google "Play" [sic] store, presumably this time for good.

However, we can take solace in the fact that Google endorsed the above privacy policy, and found no fault with it whatsoever."

Also known as Dash in Debian (it's satandard POSIX shell) and sh in Busybox that sadly tainted the original BSD source file with GPL2.

https://github.com/mirror/busybox/blob/master/shell/ash.c

The standard POSIX specification describes the vi line editing mode for the shell command line. They tried to add an emacs mode but... [1]

"In early proposals, the KornShell-derived emacs mode of command line editing was included, even though the emacs editor itself was not. The community of emacs proponents was adamant that the full emacs editor not be standardized because they were concerned that an attempt to standardize this very powerful environment would encourage vendors to ship strictly conforming versions lacking the extensibility required by the community. The author of the original emacs program also expressed his desire to omit the program. Furthermore, there were a number of historical systems that did not include emacs, or included it without supporting it, but there were very few that did not include and support vi. The shell emacs command line editing mode was finally omitted because it became apparent that the KornShell version and the editor being distributed with the GNU system had diverged in some respects. The author of emacs requested that the POSIX emacs mode either be deleted or have a significant number of unspecified conditions. Although the KornShell author agreed to consider changes to bring the shell into alignment, the standard developers decided to defer specification at that time. At the time, it was assumed that convergence on an acceptable definition would occur for a subsequent draft, but that has not happened, and there appears to be no impetus to do so. In any case, implementations are free to offer additional command line editing modes based on the exact models of editors their users are most comfortable with."

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...

Yeah but looking how auto has been abused in C++ I don't think it worth it.

And why this is not the default behaviur?

I am pretty sure many users are going to think it is correctness check an not an optimization attribute.

I know it, but if you have a bug that reach the Unreachable path the compiler can't tell you anything. that is why I use assert(0) in debug builds.

Its a crippled form of code generator in an era where compile time execution is suported by many modern system languages.

But I don't like any of them. I prefer to write my own code generators.

For example sometimes you forget to change all the relevant types from uint32_t to uint64_t when refactoring some value and stuff breaks weirdly

Use size_t

auto, constexpr: Kill them with fire.

unreachable. No when the optimizer compiler can f*#k up my code if you combine it with unintended undefined behaviur. I just use asser(0) in debug builds. Not kidding.

I am not angry, just very sad but I guarantee you most people who love to program in C or do it for a living are not "standards enthusiasts".

Type inference only make the code harder to read. You ended doing mental compiler work when you could just write the damm type.

And the people who say "I Just hover the variable in my IDE" It doesn't work in a terminal with grep, you can't hoved a diff file and not even github do the hover thing.

Combine that with the implicit type promotion rules of C. Have Fun.

Many people still write in a C89 dialect just fine.

Most of the good stuff is written in it: sqlite, curl, STB libraries, zlib, OS kernels etc.

I wish the C Standard Committe stopped smearing all C++ bullshit in to C. Now that many of the C++ people who promoted those features are abandoning the ship.

It's what you get when your C compilers are implemented in C++.

https://tools.suckless.org/tabbed/

A rewrite of an old code base with today's hardware characteristics in mind should yield better performance, in Rust, C/C++ or any other system language.