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.
Two people go on a date. The date is going well, there is chemistry between the two people. One says “if you beat me at any game we can have sex”. The two people will typically play a board or card game, and will flirt with the opportunity of sex during the game play, which is gonna be fun and exciting. Seems a good plot idea for your average romantic comedy movie or teenager’s series.
Now the joke is that the choice of game is stupid because you end up killing your date. Just with that you could make a meme/joke. Now the post is doubling down on the stupidity, insanity, etc., by making it morbid and showing that the guy still had sex with the corpse.
Here it is. My take on the issue, which is unlikely to be the only possible explanation which is not “incel shit”. I’ve wasted 10 minutes of my time, and you’ll likely will still not agree with me, and will prove valid my first comment.
Klipper was entirely a different program, process, etc. that was using the system tray. Nowadays it seems to be a plasmoid in the system tray. How can that be less of a UNIX philosophy than the Windows alternative? Because it’s developed by the same community that makes the shell? That doesn’t make sense to me.
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.
Related: There is an article on LWN called Lua and Python, which is mostly about the approach of the two languages WRT being “batteries included” or not.
I think Lua being a bit barebones is 100% fine… if you just pair it with a good helper library, or set of libraries with a coherent API, that allows it to thrive. Then you can either use the framework library or not, depending on whether your project requires the extras, or can do without.
As a parallel, I’ve been doing C++ development for almost two decades, and I cannot imagine doing anything non-trivial without Qt. For example, Qt has a debug framework that pretty prints automatically most containers, and adds the newline also automatically. Also, QString is an actual string type, whereas std::string is more like QByteArray. It’s functionality that it’s essential for me (and it’s just the minimal examples… then Qt has all the GUI functionality, of course, but I use Qt even in console-only programs!).
This is surely opinionated on my side, and most C++ devs don’t see it this way, but my point is that a language with a “core experience” that it’s lackluster to you should not be a bad thing if the language is capable enough to provide an ecosystem with a good 3rd party library that adds exactly what you want. In the Lua ecosystem that maybe it’s Penlight.
But I totally get your point. Penlight doesn’t even seem to have a math library, so I found no round implementation there. This can be not a problem for some, but deal breaking for others.
Normally the good jokes are also somewhat smart, even though they are not “serious”. A joke about Texas being big is not very smart, IMHO. Is also not very original, as it’s not the first one I’ve seen in this vein. And above all, it’s specially stupid to end it with a remark about “The European mind cannot comprehend this”, because Europeans know a lot more about the US than the US people know about Europe.
IOW, it’s not that it’s struck a nerve, it’s that it was legit bad.
PS: Oh, and, the fact that it appeals to Europeans, it seems like it appeals on Europe as a whole, which makes it doubly stupid, because then individual members of the EU/continent are like USA states, and then each member/state has routes as long as the one in the original meme.
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:
<span style="color:#323232;"> dnl Define somedir_c_make.
</span><span style="color:#323232;"> [$1]_c_make=`printf '%sn' "$[$1]_c" | sed -e "$gl_sed_escape_for_make_1" -e "$gl_sed_escape_for_make_2" | tr -d "$gl_tr_cr"`
</span><span style="color:#323232;"> dnl Use the substituted somedir variable, when possible, so that the user
</span><span style="color:#323232;"> dnl may adjust somedir a posteriori when there are no special characters.
</span><span style="color:#323232;"> if test "$[$1]_c_make" = '"'"${gl_final_[$1]}"'"'; then
</span><span style="color:#323232;"> [$1]_c_make='"$([$1])"'
</span><span style="color:#323232;"> fi
</span><span style="color:#323232;"> if test "x$gl_am_configmake" != "x"; then
</span><span style="color:#323232;"> gl_[$1]_config='sed "rn" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'
</span><span style="color:#323232;"> else
</span><span style="color:#323232;"> gl_[$1]_config=''
</span><span style="color:#323232;"> fi
</span>
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.
I’d have to dig it, but I think it said that it added the PID and the uninitialized memory to add a bit more data to the entropy pool in a cheap way. I honestly don’t get how that additional data can be helpful. To me it’s the very opposite. The PID and the undefined memory are not as good quality as good randomness. So, even without Debian’s intervention, it was a bad idea. The undefined memory triggered valgrind, and after Debian’s patch, if it weren’t because of the PID, all keys would have been reduced to 0 randomness, which would have probably raised the alarm much sooner.
this has to do with writing ‘better’ code, which has proved impossible over and over again
I can’t speak for C, as I don’t follow it that much, but for C++, this is just not fair. It has been proven repeatedly that it can be done better, and much better. Each iteration has made so many things simpler, more productive, and also safer. Now, there are two problems with what I just said:
That it has been done safer, that doesn’t mean that everyone makes good use of it.
That it has been done safer, doesn’t mean that everything is fixable, and that it’s on the same level of other, newer languages.
If that last part is what you mean, fine. But the way that you phrased (and that I quoted) is just not right.
At this point it’s literally easier to slowly port to a better language than it is to try and ‘fix’ C/C++.
Surely not for everything. Of course I see great value if I can stop depending on OpenSSL, and move to a better library written in a better language. Seriously looking forward for the day when I see dynamic libraries written in Rust in my package manager. But I’d like to see what’s the plan for moving a large stack of C and C++ code, like a Linux distribution, to some “better language”. I work everyday on such a stack (e.g. KDE Neon in my case, but applicable to any other typical distro with KDE or GNOME), and deploy to customers on such a stack (on Linux embedded like Yocto). Will the D-Bus daemon be written in Rust? Perhaps. Systemd? Maybe. NetworkManager, Udisks, etc.? Who knows. All the plethora of C and C++ applications that we use everyday? Doubtful.
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.
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.
On the one side I really like c and c++ because they’re fun and have great performance; they don’t feel like your fighting the language and let me feel sort of creative in the way I do things(compared with something like Rust or Swift)....
It’s just time to move on from C/C++, but some people just can’t seem to let go.
The Rust community has 2 websites that I keep periodically checking: Are we game yet? and Are we GUI yet?. The answers on those sites are respectively (as of February 2024, when this comment is written) “Almost. We have the blocks, bring your own glue” and “The roots aren’t deep but the seeds are planted”. I’ve seen the progress in Bevy and Slint, but it’s still the same, those websites don’t change, and my situation WRT to making a Rust project for fun or work it’s the same.
I’ll be happy to start doing Rust projects whenever I get the chance (which will be when it’s a sufficient tool for my use cases). But I’m tired of smoke sellers.
I’ve wanted to start a project in Rust, but for the ideas that I have (and the time that I have for a hobby project, as for work it’s rarely starting a new one, but continuing and existing one), Rust seemed a viable, but not ideal alternative to just doing it all in C++, for which I already have enough knowledge and very well proven libraries. I will look again soon, and I will keep looking because eventually something will surely click, it’s just that so far, the time has not been right.
Note that my point is not that it’s unusable for everyone. Just that it’s false that “some people just can’t seem to let [C or C++] go”, as the previous comment said. I can’t let go something that works well for something that doesn’t, given the projects that I have to work on.
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).
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.
Winner's Luck (lemmy.world)
I still don't get buffers (programming.dev)
Why I Left NixOS for Ubuntu (fd93.me)
Hey all, thought this might be of interest to some here....
GOD DAMMIT STEVEN! NOT AGAIN! (lemmy.world)
deleted_by_author
Holland has so much space (lemmy.world)
XZ backdoor in a nutshell (lemmy.zip)
C can be memory-safe (2023) (blog.erratasec.com)
True Story (lemmy.world)
Google cosplay is not business-critical (programming.dev)
Transcription: a Twitter thread from Gary Bernhardt....
White House: Future Software Should Be Memory Safe (www.whitehouse.gov)
On the one side I really like c and c++ because they’re fun and have great performance; they don’t feel like your fighting the language and let me feel sort of creative in the way I do things(compared with something like Rust or Swift)....
Hey, I'm new to GitHub! (programming.dev)
PySimpleGUI is now closed-source (github.com)
Previously LGPL, now re-licensed as closed-source/commercial. Previous code taken down....
Everything about TOML format - Orchard Dweller (www.youtube.com)
Visualizer:...
Parkable cities (startrek.website)
Release notes of an open source app. Someone is pretty mad at Canonical for Snap (programming.dev)