fruitcantfly

joined 2 years ago
[–] fruitcantfly@programming.dev 2 points 1 week ago* (last edited 1 week ago)

That is not just a book about how to "cut potatoes". That is "A Creative Cooking Guide for Exercising Knife Skills", using potatoes as a medium. Similarly, your Rust book is an book on concurrency using Rust as a medium, as per the title: "Low-Level Concurrency in Practice". Both are complex topics, and both have picked a medium. Thus, they do not necessarily reflect on the underlying complexity of the medium, though concurrency in Rust is a complex topic due to the fact that the core language itself does a lot of work to make it "safe". Async would probably be an even better example of that.

However, in the case of initialization in C++ and in the case of move schematics in C++, these are topics that are complex because the core language has been accumulating complexity for a long time, and because the language designers cannot afford to break backwards compatibility. Which makes implementing and using move-schematics in C++, as an end-user of the language, much, much more complicated than in a language like Rust, that did not have to bolt this behavior on top of an already complicated language. Similarly with initialization, where C++ has accumulated many, syntactically overlapping forms of initialization, for both member and non-member variables variables

[–] fruitcantfly@programming.dev 10 points 1 week ago (5 children)
  1. Crazy initialization That sure is a lot of ways to initialize a variable! Even though some of these variables are quite different and would be initialized differently from each other in many other languages, even only counting the initializations that are functionally equivalent, there are a bunch of abuses of syntax that I’ve never seen used in the wild.

Initialization in C++ is so simple that somebody wrote a nearly 300-page book on the subject: https://www.cppstories.com/2023/init-story-print/

I plan to read it after finishing this 260 page book on move schematics in C++: https://www.cppmove.com/

[–] fruitcantfly@programming.dev 5 points 1 week ago (1 children)

But GCC did not improve their error messages (much) prior to Rust, despite Clang's error messages comparing favorably to GCC even before Rust 1.0 was released, as for example discussed in

https://gcc.gnu.org/wiki/ClangDiagnosticsComparison?action=recall&rev=1

Rust itself is 14 years old, slightly older than above wiki page, and even back then it had great error messages, though they've also improved since. Here's a fun site where you can see how error messages have evolved through Rust's life:

https://kobzol.github.io/rust/rustc/2025/05/16/evolution-of-rustc-errors.html

It's only very recently that GCC has started to catch up, for example with some nice improvements in GCC 15:

https://developers.redhat.com/articles/2025/04/10/6-usability-improvements-gcc-15

[–] fruitcantfly@programming.dev 1 points 1 month ago (2 children)

It's not just server-side: A lot of fingerprinting happens client-side, for example using a canvas to check what features your graphics card supports. You can see this in action via services like https://coveryourtracks.eff.org/ or https://amiunique.org/

[–] fruitcantfly@programming.dev 7 points 1 month ago* (last edited 1 month ago) (2 children)

A pull request is very much a proposal: It is a proposal to make specific changes to the code-base. The developers are not forced to accept it in any form, and discussions can take place in the pull request, should the developers (or third parties) not agree with (the exact form of) the proposed changes. Which is exactly what happened in the systemd pull request, to the extent that the actual developers had to lock the thread.

In the case of systemd, the "someone", or rather the "someones", who accepted the pull request also included the lead developer on the project, namely Lennart Poettering. Who else do you propose should decide what pull requests and other proposals to accept?

[–] fruitcantfly@programming.dev 20 points 1 month ago (1 children)

What do you mean, he “admitted” that?

It’s quite literally the first thing he wrote in his pull request to systemd:

Stores the user's birth date for age verification, as required by recent laws in California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc.

And the second paragraph of his pull request to arch:

Recent age verification laws in California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc. require platforms to verify user age. Collecting birth date at install time ensures Arch Linux is compliant with these regulations.

[–] fruitcantfly@programming.dev 2 points 1 month ago (1 children)

Development stopped not because LILO didn’t need any changes, but because of its limitations (source):

NOTE: I have finished development of LILO at December 2015 because of some limitations (e.g. with BTFS, GPT, RAID). If someone want to develop this nice software further, please let me know ...

Also, I dunno what your position is on this, but it is amusing to see calls for Canonical to replace GPL licensed software, with something with a more lenient license (BSD-3-clause). Normally that would cause outrage around here

[–] fruitcantfly@programming.dev 3 points 1 month ago* (last edited 1 month ago) (3 children)

I guess they have their own fork of it?

Upstream hasn’t seen a new release, nor any commits, since 2015: https://lilo.joonet.de/

ETA: It is also my understanding that LILO fundamentally does not support reading filesystems, while Canonical want to keep SquashFS, among others. Adding support for that to LILO, along with whatever other features are missing, would likely be a major undertaking

[–] fruitcantfly@programming.dev 3 points 1 month ago

and another thing: im not mad. please dont put in the newspaper that i got mad.

[–] fruitcantfly@programming.dev 29 points 1 month ago (5 children)

It’s probably easier to strip down GRUB, than it is to resurrect and add missing features to a project that has been dead for 10+ years

[–] fruitcantfly@programming.dev 7 points 1 month ago

It hasn’t been rolled back. You can go to the systemd repo and look at the main branch for yourself.

Here’s the commit. Just click through and see if the code was subsequently removed from any of the files. You’ll find that it wasn’t.

https://github.com/systemd/systemd/commit/7a858878a03966d2a65ef9e8f79b5caff352ac53

[–] fruitcantfly@programming.dev 1 points 1 month ago (1 children)

Did you reply to the wrong comment? I have no idea how you managed to get all that from my comment. All I’m saying is, "when you hear hoofbeats, think of horses, not zebras”

view more: next ›