lysdexic

joined 1 year ago
MODERATOR OF
[–] lysdexic 10 points 5 months ago

Git is ugly and functional.

I don't even think it's ugly. It just works and is intuitive if you bother to understand what you're doing.

I think some vocal critics are just expressing frustration they don't "get" a tool they never bothered to learn, particularly when it implements concepts they are completely unfamiliar with. At the first "why" they come across, they start to blame the tool.

[–] lysdexic -2 points 5 months ago (9 children)

Git is no different. But it sure feels like it never took the idea of a polished user experience seriously.

I've seen this sort of opinion surface often,but it never comes with specific examples. This takes away from the credibility of any of these claims.

Can you provide a single example that you feel illustrates the roughest aspect of Git's user experience?

[–] lysdexic -2 points 5 months ago* (last edited 5 months ago) (1 children)

it’s about deploying multiple versions of software to development and production environments.

What do you think a package is used for? I mean, what do you think "delivery" in "continuous delivery" means, and what's it's relationship with the deployment stage?

Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.

https://wiki.debian.org/DebianAlternatives

Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.

[–] lysdexic 3 points 5 months ago (3 children)

I feel this sort of endeavour is just a poorly researches attempt at reinventing the wheel. Packaging formats such as Debian's .DEB format consist basically of the directory tree structure to be deployed archived with Zip along with a couple of metadata files. It's not rocket science. In contrast, these tricks sound like overcomplicated hacks.

[–] lysdexic 1 points 5 months ago

Logging in local time is fine as long as the offset is marked.

I get your point, but that's just UTC with extra steps. I feel that there's no valid justification for using two entries instead of just one.

[–] lysdexic 1 points 5 months ago (2 children)

I’ve had mixed results with ccache myself, ending up not using it.

Which problems did you experienced?

Compilation times are much less of a problem for me than they were before, because of the increases in processor power and number of threads.

To each its own, but with C++ projects the only way to not stumble upon lengthy build times is by only working with trivial projects. Incremental builds help blunt the pain but that only goes so far.

This together with pchs (...)

This might be the reason ccache only went so far in your projects. Precompiled headers either prevent ccache from working, or require additional tweaks to get around them.

https://ccache.dev/manual/4.9.1.html#_precompiled_headers

Also noteworthy, msvc doesn't play well with ccache. Details are fuzzy, but I think msvc supports building multiple source files with a single invocation, which prevents ccache to map an input to an output object file.

[–] lysdexic 2 points 5 months ago* (last edited 5 months ago)

Here’s the sauce

I don't buy it. Unauthorized access attempts are a constant on the internet in general, and in AWS endpoints in particular. When anyone exposes an endpoint, it's a matter of minutes until it starts to get prodded by security scanners. I worked on a project where it's endpoints were routinely targeted by random people running FLOSS security scanners resulting in thousands of requests that were blocked either by rate-limiting or bad/lack of credentials. I don't believe that a single invoice of $1k would trigger such a sudden and massive change of heart, when accidental costs in AWS easily reach orders of magnitude above that price tag.

[–] lysdexic 3 points 5 months ago

This seems like something they just never concidered until a really big client that was getting hammered told them they can stick the bill.

Yes, this indeed screams "Cloudflare does not pull this sort of shit", and now they are spinning this as something they do out of kindness.

[–] lysdexic 1 points 5 months ago* (last edited 5 months ago) (2 children)

You'd be missing the whole point too if you think that the pointer is the root cause. The problem is that the class is not designed to be copy-able, let alone moveable. Your suggestion to use a unique_ptr will also blow up in your face the moment you try to copy an instance.

[–] lysdexic 0 points 5 months ago (1 children)

Naked pointers are just too stupid for modern C++ ;)

Anyone who works on real-world production software written in C++ knows for a fact that pointers are a reality.

Also, there are plenty of frameworks who employ their own memory management frameworks, and raw pointers are perfectly fine in that context. For example, Qt uses raw pointers extensively because It's object system implements an object ownership system where each object can have child and parents, and you can simply invoke deleteLater() to free the whole dependency tree when you no longer need it.

[–] lysdexic 1 points 5 months ago* (last edited 5 months ago)

Simply taking std::string by value (as it is a memory management class created for that explicit purpose) would have solved the problem without kneecapping every class you make.

I think you are missing the whole point.

The blogger tried to make a point about how special member functions can be tricky to get right if you don't master them. In this case, the blogger even presents a concrete example of how the rule of 3/rule of 5 would fail to catch this issue. As the blogger was relying on the implicit special member functions to manage the life cycle of CheeseShop::clerkName and was oblivious to the possibility of copying values around, this resulted in the double free.

You can argue that you wouldn't have a problem if the string was used instead of a pointer to string, which is a point that the blogger indirectly does, but that would mean you'd be missing the root cause and missing the bigger picture, as you'd be trusting things to work by coincidence instead of actually knowing how they work.

The blogger also does a piss-poor job in advocating to explicitly delete move constructors, as that suggests he learned nothing from the ordeal. A preferable lesson would be to a) not use raw pointers and instead try to adopt a smart pointer with the relevant semantics, b) actually provide custom implementations for copy/move constructors/assignment operators whenever doing anything non-trivial to manage resources, such as handling raw pointers and needing to both copy them and free them whenever they stop being used.

7
submitted 5 months ago by lysdexic to c/cpp
22
One year of C (2018) (floooh.github.io)
submitted 5 months ago by lysdexic to c/c_lang
12
Lamport timestamp (en.wikipedia.org)
submitted 5 months ago by lysdexic to c/programming
18
submitted 5 months ago by lysdexic to c/git
view more: ‹ prev next ›