Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)L
Posts
439
Comments
601
Joined
3 yr. ago

  • I don’t see why using submodules as a package manager should excuse their endless bugs.

    I don't know what are these "endless bugs" you're talking about. Submodules might have a UX that's rough on the edges, but there are really no moving parts in them as they basically amount to cloning a repo and checking out a specific commit.

    Do you actually have any specific, tangible issue with submodules? Even in the cases you're clearly and grossly misusing them

  • It's interesting that the internet is packed with search hits of complains that Cloudflare's DNS is slowing everything but Cloudflare representatives are quick to post followups pointing the finger everywhere else.

  • Asking this question is like asking when was the last time you had to search through text.

  • Aside from the obvious UX disaster, Git has some big issues:

    I find this blend of claims amusing. I've been using Git for years on end, with Git LFS and rebase-heavy user flows, and for some odd reason I never managed to stumble upon these so-called "disasters". Odd.

    What I do stumble upon are mild annoyances, such as having to deal with conflicts when reordering commits, or the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn't, but I would not call any of these "disasters". The only gripe I have with Git is the lack of a command to split a past commit into two consecutive commits (a reverse of a squash commit), specially when I accidentally bundled changes to multiple files that shouldn't have been bundled. It's nothing an interactive rebase doesn't solve, but it's multiple steps that could be one.

    Can you point out what is the most disastrous disaster you can possibly conceive about Git? Just to have a clear idea where that hyperbole lies.

  • Cloud @programming.dev

    Cloudflare 1.1.1.1 incident on June 27, 2024

    blog.cloudflare.com /cloudflare-1111-incident-on-june-27-2024
  • There are no hard set rules, and it depends on what uses you have for the build number.

    Making it a monotonically increasing number helps with versioning because it's trivial to figure out which version is newer. Nevertheless, you can also rely on semantic versioning for that. It's not like all projects are like Windows 10 and half a dozen major versions are pinned at 10.0.

    You sound like you're focusing on the wrong problem. You first need to figure it what is your versioning strategy,and from there you need to figure out if a build number plays any role on it.

  • C Programming Language @programming.dev

    research!rsc: On Duff's Device and Coroutines

    research.swtch.com /duff
  • C++ @programming.dev

    P2996R4 - Reflection for C++26

    isocpp.org /files/papers/P2996R4.html
  • C++ @programming.dev

    Member ordering and binary sizes

    www.sandordargo.com /blog/2024/06/26/member-ordering-and-binary-size
  • C++ @programming.dev

    Hardening Modes — libc++ documentation

    libcxx.llvm.org /Hardening.html
  • Data Structures and Algorithms @programming.dev

    What is a CIDR trie and how can it help you?

    d34dl0ck.me /rust-bites-cidr-trie/index.html
  • C++ @programming.dev

    Learning C++ Memory Model from a Distributed System's Perspective (2021)

    blog.the-pans.com /cpp-memory-model-as-a-distributed-system/
  • C Programming Language @programming.dev

    The C Standard charter (2024)

    www.open-std.org /jtc1/sc22/wg14/www/docs/n3280.htm
  • Data Structures and Algorithms @programming.dev

    B-trees Require Fewer Comparisons Than Balanced Binary Search Trees

    databasearchitects.blogspot.com /2024/06/b-trees-require-fewer-comparisons-than.html
  • Programming Books @programming.dev

    Distributed Systems 4th edition - Andrew Tanenbaum

    www.distributed-systems.net /index.php/books/ds4/
  • Programming @programming.dev

    A simple benchmark of various math operations (2014)

    latkin.org /blog/2014/11/09/a-simple-benchmark-of-various-math-operations/
  • Data Structures and Algorithms @programming.dev

    the Gilbert–Johnson–Keerthi algorithm explained as simply as possible

    computerwebsite.net /writing/gjk
  • Remembering ActiveX Controls, the Web’s Biggest Mistake:

    Running JavaScript everywhere is looming as one of the biggest screwups in InfoSec. What do userscript extensions like Grease monkey teach us?

  • Ah, the Microsoft tradition of always having the wrong priorities.

    I wouldn't be too hard on Microsoft. The requirement to curate public package repositories only emerged somewhat recently, as demonstrated by the likes of npm, and putting in place a process to audit and pull out offending packages might not be straight-forward.

    I think the main take on this is to learn the lesson that it is not safe to install random software you come across online. Is this lesson new, though?

  • Programming @programming.dev

    IANA: Uniform Resource Names (URN) Namespaces

    www.iana.org /assignments/urn-namespaces/urn-namespaces.xml
  • .NET @programming.dev

    How to execute cleanup code using finally - C#

    learn.microsoft.com /en-us/dotnet/csharp/fundamentals/exceptions/how-to-execute-cleanup-code-using-finally
  • Agile is not a system. It’s a set of principles, set by the Agile manifesto.

    The Agile manifesto boils down to a set of priorities that aren’t even set as absolutes.

    I strongly recommend you read upon Agile before blaming things you don’t like on things you don’t understand .

  • ccache folder size started becoming huge. And it just didn’t speed up the project builds, I don’t remember the details of why.

    That's highly unusual, and suggests you misconfigured your project to actually not cache your builds, and instead it just gathered precompiled binaries that it could not reuse due to being misconfigured.

    When I tried it I was working on a 100+ devs C++ project, 3/4M LOC, about as big as they come.

    That's not necessarily a problem. I worked on C++ projects which were the similar size and ccache just worked. It has more to do with how you're project is set, and misconfigurations.

    Compilation of everything from scratch was an hour at the end.

    That fits my usecase as well. End-to-end builds took slightly longer than 1h, but after onboarding ccache the same end-to-end builds would take less than 2 minutes. Incremental builds were virtually instant.

    Switching to lld was a huge win, as well as going from 12 to compilation 24 threads.

    That's perfectly fine. Ccache acts before linking, and naturally being able to run more parallel tasks can indeed help, regardless of ccache being in place.

    Surprisingly, ccache works even better in this scenario. With ccache, the bottleneck of any build task switches from the CPU/Memory to IO. This had the nice trait that it was now possible to overcommit the number of jobs as the processor was no longer being maxed out. In my case it was possible to run around 40% more build jobs than physical threads to get a CPU utilization rate above 80%.

    I was a linux dev there, the pch’s worked, (...)

    I dare say ccache was not caching what it could due to precompiled headers. If you really want those, you need to configure ccache to tolerate them. Nevertheless it's a tad pointless to have pch in a project for performance reasons when you can have a proper compiler cache.

  • Also interesting, successful software projects don't just finish and die. They keep on going and adapt changes and implement new features. If we have a successful project that goes on for a decade but we have a clusterfuck of a project which blows up each year for the same time period, by this metric you'll have only a 10% success rate.

  • If you write it down it is documentation.

    I think you're not getting the point.

    It matters nothing if you write down something. For a project, only the requirements specification matters. The system requirements specification document lists exactly what you need to deliver and under which conditions. It matters nothing if you write a README.md or post something in a random wiki.

    Requirements are not the same thing as specifications either, but both are documentation!

    https://en.wikipedia.org/wiki/System_requirements_specification

  • that managers want to stay in control of everything, and they decide whether they do it or not.

    That's fine, it's a call from the manager.

    That doesn't make it Agile's fault though. In fact, one of the key principles of Agile is providing developers with the support they need. Blaming Agile for the manager single-handledly pushing for something in spite of any feedback does not have any basis.

  • So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.

    I think you're confusing documentation with specification.

    Requirements are specified. They are the goals and the conditions in which they are met. Documentation just means paper trails on how things were designed and are expected to work.

    Requirements drive the project. Documentation always lag behind the project.

  • the whole point of agile is to be short term

    Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can't accommodate any changes because the process does not have room for those.

    This is why this whole "things need to be planned" crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.

    Don't blame Agile for your inability to plan. No one forces you not to plan ahead.

  • The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.

    I think you got it entirely backwards.

    The whole point of Agile is being able to avoid the "big design up front" approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you're picking up along the way.

    The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.

  • Note that this is failure to deliver on time, not failure to deliver full stop.

    It's also important to note that the Hallmark of non-Agile teams is de-scoping and under-delivering. It's easy to deliver something on time if you switch your delivery goals and remove/half-bake features to technically meet requirements while not meeting requirements.

  • On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development.

    I don't think this is an Agile thing, at all. I mean, look at what Agile's main trait: multiple iterations with acceptance testing and product&design reviews. At each iteration there is planning. At each planning session you review/create tickets tracking goals and tasks. This makes it abundantly clear that Agile is based in your ability to plan for the long term but break/adapt progress into multiple short-term plans.

  • I've been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.

    The main factors in burning out we're always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It's not Agile's fault that your manager wants a feature out in half the time while looming dismissals over your head.

    It's not Agile's fault that stack ranking developers results in hostile team environments where team members don't help out people and even go as far as putting roadblocks elsewhere so that they aren't the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.

  • std::unordered_map is one of the worst ones

    It should be noted that the benchmark focused on the std::unordered_map implementation from GCC 13.2.0. I'm not sure if/how this conclusion can be extended to other implementations such as msvc or clang.