Norway.

Ups. Sorry, I meant "NO".

Ah, a classic watch. :-)

Elon probably thinks that SQL is MS SQL Sever, MySQL, or some such.

Is it, really? If the whole point of the library is dealing with binary files, how are you even going to have automated tests of the library?

The scary thing is that there is people still using autotools, or any other hyper-complicated build system in which this is easy to hide because who the hell cares about learning about Makefiles, autoconf, automake, M4 and shell scripting at once to compile a few C files. I think hiding this in any other build system would have been definitely harder. Check this mess:

  dnl Define somedir_c_make.
  [$1]_c_make=`printf '%s\n' "$[$1]_c" | sed -e "$gl_sed_escape_for_make_1" -e "$gl_sed_escape_for_make_2" | tr -d "$gl_tr_cr"`
  dnl Use the substituted somedir variable, when possible, so that the user
  dnl may adjust somedir a posteriori when there are no special characters.
  if test "$[$1]_c_make" = '\"'"${gl_final_[$1]}"'\"'; then
    [$1]_c_make='\"$([$1])\"'
  fi
  if test "x$gl_am_configmake" != "x"; then
    gl_[$1]_config='sed \"r\n\" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'
  else
    gl_[$1]_config=''
  fi

Sometimes that's part of the issue (or the whole deal), but sometimes it's not even that.

Sometimes it's that someone asked something difficult and elaborate to answer, which has been answered a ton of times, and it's tedious to answer again and again. But if someone answers with misinformation or even straight FUD, then one needs to feel the urge to correct that to prevent misinformation.

I suffered that with questions in r/QtFramework. Tons of licensing questions, repeated over and over, from people who have not bothered to read a bit about such a well known and popular license as LGPL. Then someone who cares little for the nuance answers something heavy handed, and paints a wrong picture. Then I can't let the question pass. I need to correct the shitty answer. :-(

Thanks. I should have linked to that myself, perhaps.

Yes. There is already an answer with many votes saying so, but I'll add myself to the list.

I don't have to like all the language, and not even all of the standard library. I learnt C++ with the Qt library, and I still do 99% of my development using Qt because it's the kind of software that I like to write the most. I can choose the parts that I like the most about the full C++ ecosystem, like most people do (you would have to see how different game development is, for example).

I'm also learning Rust, and I see nothing wrong with it. It's just that I see C++ better for the kind of stuff that I need to write (at this time at least).

I'm not fully sure what the intent of the joke is, but note that yes, it's true that a header typically just has the prototype. However, tons of more advanced libraries are "header-only". Everything is in a single header originally, in development, or it's a collection of headers (that optionally gets "amalgamated" as a single header). This is sometimes done intentionally to simplify integration of the library ("just copy this files to your repo, or add it as a submodule"), but sometimes it's entirely necessary because the code is just template code that needs to be in a header.

C++ 20 adds modules, and the situation is a bit more involved, but I'm not confident enough of elaborating on this. :) Compile times are much better, but it's something that the build system and the compilers needs to support.

Has it occurred to you that pressing the downvote button is just much easier that having to bother explaining something that should be obvious?

If it is not obvious to you that it's not incel shit, maybe even after an explanation you won't agree still because you have different views (which I'm not saying are not respectable, but are still different, so an agreement can't be reached), so whoever replies to you would have wasted their time.

So of course people downvote without replying.

Radon, the "handwriting" one, seems like if someone wanted to have Comic Sans but for code.

no more patching fuzzers to allow that one program to compile. Fix the program

Agreed.

Remember Debian's OpenSSL fiasco? The one that affected all the other derivatives as well, including Ubuntu.

It all started because OpenSSL did add to the entropy pool a bunch uninitialized memory and the PID. Who the hell relies on uninitialized memory ever? The Debian maintainer wanted to fix Valgrind errors, and submitted a patch. It wasn't properly reviewed, nor accepted in OpenSSL. The maintainer added it to the Debian package patch, and then everything after that is history.

Everyone blamed Debian "because it only happened there", and definitely mistakes were done on that side, but I surely blame much more the OpenSSL developers.

Lol. We’re as far away from getting to AGI as we were before the whole LLM craze. It’s just glorified statistical text prediction, no matter how much data you throw at it, it will still just guess what’s the next most likely letter/token based on what’s before it, that can’t even get it’s facts straith without bullshitting.

This is correct, and I don't think many serious people disagree with it.

If we ever get it, it won’t be through LLMs.

Well... depends. LLMs alone, no, but the researchers who are working on solving the ARC AGI challenge, are using LLMs as a basis. The one which won this year is open source (all are if are eligible for winning the prize, and they need to run on the private data set), and was based on Mixtral. The "trick" is that they do more than that. All the attempts do extra compute at test time, so they can try to go beyond what their training data allows them to do "fine". The key for generality is trying to learn after you've been trained, to try to solve something that you've not been prepared for.

Even OpenAI's O1 and O3 do that, and so does the one that Google has released recently. They are still using heavily an LLM, but they do more.

I hope someone will finally mathematically prove that it’s impossible with current algorithms, so we can finally be done with this bullshiting.

I'm not sure if it's already proven or provable, but I think this is generally agreed. just deep learning will be able to fit a very complex curve/manifold/etc, but nothing more. It can't go beyond what was trained on. But the approaches for generalizing all seem to do more than that, doing search, or program synthesis, or whatever.

Precisely, Gary Bernhardt has given a talk on ideology. I don't think he's precisely someone who thinks in absolutes. It's just preaching that some stuff is (probably) used more than it should. I've seen way, way, way worse projects that over engineered things and made things slow and unmanageable, than the opposite. Of course, everyone has seen different things, and our perceptions are amplified and biased by that.

Meanwhile, this was a feature on KDE-land since Klipper, which goes back (as far as I know and if I remember well) to KDE 3 or sooner.

"Theft" is never a technically accurate word when dealing with the so called "intellectual property", because the digital content being copied without authorization is legal in tons of cases, and because, come on, property is very explicitly exclusive. I cannot copy my house or my car, but I can make copies of my works for virtually 0 cost.

Using data for training ML models is even explicitly allowed in some jurisdictions (e.g. Japan), and is likely to be fair use everywhere else. LLMs are very transformative, and while they often can produce verbatim copies of fragments of copyrighted works, they don't store the whole works or significant pieces of them.

Don't get me wrong, I don't like big companies making big money. I would not mind a law that would force models to be open sourced. But restricting them to train their models on public data by restricting fair use, it would harm them very little (they could pay something if they are making some profit), while small researchers or companies would never be able to compete, because they would not have the upfront costs, nor the economic engineering to disguise profits and pay less.

PyQt.

I've been compiling apps depending on newer Qt and/or kdelibs versions for ages (back when the repository was literally called "kdelibs", about 20 years ago).

This has never been an issue for me. Even with autoconf/automake, I just compiled everything to its own prefix, so it doesn't interfere with the system at all. You don't even need to fix the build system in the cases where it's broken/lacks features, if you leverage all the "path" variables (CPATH, LIBRARY_PATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH, etc.). But autotools, cmake, qmake, and every build system I've used so far supports this out of the box.

Not claiming it's a skill issue, but I have to say I'm very surprised by reading any of this.

Specifically, for Debian, I was told 20 years ago by a very wise person "you never do make install on Debian, specially not for the kernel", and taught me how to use make-kpkg (or something like that, I don't remember the name of the tool), which was a way to make a debian package of a self built kernel, which is obviously something that can't be installed to its own prefix.

The github project page is for developers, and Github already gives you tons of ways to make a user website. Don't ask your users to visit github.com/group/project, make them visit group.github.io/project, like any sane person.

Same with Gitlab, BTW.

And if you don't like the full static site, use the wiki, or guide your users in the first paragraphs of the README so they find the user information if they must.

The very first moment that I had to use JSON as a configuration format, and I was desperate to find a way to make a long string into a JSON field. JSON is great for many things, but it's not good at all for a configuration format where you need users to make it pretty, and need features like comments or multi-line strings (because you don't want to fix a merge conflict in a 400 character-wide line).

Doesn't YAML have a (seldom used) feature of a start and end of document marker? The "YAML frontmatter" that a few markdown documents have, uses this.

The problem is not that the US is sparse, is that cities are. You are probably misunderstanding the problem, and if not, you are not explaining correctly. Check out The Dumbest Excuse for Bad Cities from Not Just Bikes for a breakdown of the issue.

No one is blaming you individually, or even the US citizens individually. The problems are multiple for sure, but you won't start to fix it unless you understand the issue properly. Maybe it's not your case, but many US citizens are surely not seeing the point at all.