dvhh

Checks out, pgrust is mainly an LLM driven rewrite with minimum supervision and guided by 100% test suite conformance.

I don't know if converting the code could be an issue with copyright, but might be contrived as plagiarism

License for test might be subject to debate, because afaik the project is merely running them.

but yes the test files should be presented under their original licence.

it does not, it basically delegate that part to lower level library for which you have to write the glue code for, there is an example for SDL.

Security by obscurity worked quite well

I might be in a niche user, but what I a mostly looking forward into an ARM laptop, would be to be silent with preferably passive heat management or as little at possible active heat management (all day battery usage is a given).

Wasn't it Frank Klepacki that composed the music for Dune 2.

Stephane Picq worked with Cryo interactive for the first Dune game.

I heard Basic is pretty good as far as embedded script interpreter

And desktop app are tuning into bloated website

admittedly mc is far from being a "modern" TUI

works with curl, maybe there is a case to either build a proxy for UDS and expose them to a browser, or open a request ticket to browser maintainers to support UDS

I would recognize sarcasm when I see it. But statistically, that could be true, considering the amount of C code running ( probably far less than COBOL or FORTRAN ), Compared to the relatively small amount of Rust code vs the amount of faults observed with it.

Considering how Ubuntu seems to influence Debian development, this is only slightly surprising.

See: https://lists.debian.org/deity/2025/10/msg00071.html - Hard Rust requirements from May onward - by a Core Ubuntu Developer

confirming that Rust popularity is in great part due to the advent of LLM for generating code.

If I wanted a browser with AI, I would have used Chrome or Edge

looking at the statement, I find it weird that Benj Edwards is trying very hard to remove the blame from Kyle Orland, Even if he is not directly responsible.

Once used object storage as queue, you can implement queue semantic at the application level, with one object per entry.

But the application was fairly low volume in Data and usage, So eventual consistency and capacity was not an issue. And yes timestamp monotonicity is not guaranteed when multiple client upload at the same time so unique id was given to each client at startup and used for to add guarantee of entries name. Metadata and prefix were used to indicate state of object during processing.

Not ideal, but it was cheaper that a DB or a dedicated MQ. The application did not last, but would try again the approach if adapted to stuation.

Comes with the general perception of OS vs Software failure responsibility:

- On Windows, this is Window's fault - On Apple OS, this is the application's fault - On Linux, this is the user's fault

Of course exception do apply, but as far as I know MacOS I have noticed some instance of application patching by the OS itself (although I haven't dug deeper, I can confirm that the application did have a slight change of behavior even before applying vendor patches, and I doubt it was anything done by the anti-malware protection)

As far as I understand LLM what is being asked is unfortunately close to impossible with LLM.

Also I find it disingenuous that apologists are stating thing close to "you are using it wrong". Where it is advertised that LLM based AI should be more and more trusted (because more accurate, based on some arbitrary metrics) and might save some time ( on some undescribed task).

Of course in that use case most would say to use your judgement to verify whatever is generated, but for the generation that is using AI LLM as a source of knowledge ( like some people are using Wikipedia as source of truth, or stack overflow) it will be difficult to verify, when all they knew is LLM generated content as source of knowledge.

sure that "being written in C" or in "PHP" would have gathered far less interest

Considering that the code is mostly x86 assembly, the gains from such optimization are quite unlikely.

The software does not necessarily need to be written in C ( or C++) for these elementary security holes to happen.

Isn't usb-c display port alt mode a lost cause anyway ?

got a 404, anyone else can confirm?

I have a similar experience where jpeg encoding and webp encoding result in far less computing resources use that jpeg XL or AV1, and was curious at what other people used (as I might be using the wrong library).

One issue is that format support detection was iffy, compared to Jpeg XL where people knows to use the accept header to declare support format.

And that's probably the gist of it, manufacturer find it cheaper to get rid of a legacy piece of infrastructure than "fixing the shielding" (and also support the vehicle that are already out there).

I feel that in "CDN" the C is way too close to D, some uppercase character spacing seem to close, defeating the "readability" purpose

Because most C compilers also include a C++ compiler, or that the compiler toolchain of choice for freeBSD happens to be LLVM (it was an old version of GCC before because newer version use an incompatible license, and before that I think gcc replaced pcc in the original bsd unix, the discussion to pcc with gcc is probably lost in time) that includes C and C++ compiler.

I am guessing that performance of current standalone C compiler is not as good as the one produced by compiler suit.

Following the conversation thread, rust also use llvm under the hood, but a customized one. Which would force the base system to have two versions of llvm.

For the main purpose that they are used for, displays that don't need to be updated frequently, like e-reader or "smart" price tag display.

However updating the display is more costly in terms of power than lcd.

We can also factor in that most e-reader also include backlight.

As a caveat, I appreciate e-ink technology, and the innovation that it brought us. I would also love to get my hand on one of those color e-ink android tablet. But I am not hoping to have a huge difference in battery usage from it, e-reader are very specialized device and can afford optimization that more versatile device cannot.