dvhh

one big PITA for using C with the web is string handling, the default zero terminating char array is efficient in terms of memory usage and portability, but is function handling those are full of trap, you usually end up with some custom version of Pascal string that require some special shenanigans to work with other libraries.

Debugging those would be the the primary reason why people would prefer using higher level language.

while my heart lean heavily toward A, this would serverly limit Debian contribution and would rely on contributor honesty. It might be dismissed as an attempt to gatekeep contribution. But the issue of the human cost on the receiving end of the contribution and how sophisticated attack vector it could potentially be give me some concerns about long term quality.

B being the more pragmatic, despite the (valid) code licensing concerns. but could leave some very openly LLM driven project room to contribute package.

C as a middle ground would not satisfy any party and would only push back the resolution of the status quo.

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