Header-only libs can help avoiding the troubles and complexity of linker setup. This might be even more important on Windows, which this lib "explicitly support".
short answer, because C/C++ sucks. To work around how bad C/C++ sucks people put the entire implementation into one file. That way, there's less question of how you need to integrate it into your project.
In more modern langauges, this is a solved problem and it's easy to use other people code. In C/C++, it's not. As a relavant example, try using FreeType in your C/C++ project, make sure your solution compiles on Linxu, and Mac, and Windows (and ideally other platforms)
>> As a relavant example, try using FreeType in your C/C++ project, make sure your solution compiles on Linxu, and Mac, and Windows (and ideally other platforms)
I mean, it's also an attentional commitment for me to remember your idiosyncratic apology-preferences. So I might continue apologizing for replying late to your email, unless you convince me that _everyone_ doesn't like this...
My main home PC is a Puget Serenity workstation from 2017. It has been rock solid and outperforms much newer laptops. And it has almost zero fan noise which is a priority for me. Unfortunately it looks like they may have discontinued the Serenity model, at least I don't see it on the website anymore.
I've been using Puget workstations for like 10 years now and the builds are really reliable. The one time I had issues with a build (not their fault - defective parts), they went the extra mile and rebuilt it after normal troubleshooting failed.
They do a lot of careful thermal testing and for the inside of their builds they often cut special acrylic dividers, flowguides, supports etc to manage airflow and make sure nothing comes loose like a heavy GPU.
Fractal still sells a Serenity workstation[1], but it's essentially an off-the-shelf AMD Ryzen-based system, installed into a Fractal Design Define 7 Mini case, with a Noctua tower air cooler and case fans replacing the stock cooling. They have a variety of photos showing their customized fan setup in various configurations.[2]
It's a reasonably well-built system, but $3,500 USD is hard to justify for a basic system with an 8-core CPU, 32 GB of RAM, and no discrete GPU, especially given that it's using parts that you can just purchase and assemble yourself.
I know that prices of some components have increased significantly, but not by THAT much.
This illustrates the difficulty of maintaining a separation between bugs and discussions:
> To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users
In this case it seems you believe a bug exists, but it isn't sufficiently well-understood and actionable to graduate to the bug tracker.
But the threshold of well-understood and actionable is fuzzy and subjective. Most bugs, in my experience, start with some amount of investigative work, and are actionable in the sense that some concrete steps would further the investigation, but full understanding is not achieved until very late in the game, around the time I am prototyping a fix.
Similarly the line between bug and feature request is often unclear. If the product breaks in specific configuration X, is it a bug, or a request to add support for configuration X?
I find it easier to have a single place for issue discussion at all stages of understanding or actionability, so that we don't have to worry about distinctions like this that feel a bit arbitrary.
Is the distinction arbitrary? It sounded like issues are used for clear, completable jobs for the maintainers. A mysterious bug is not that. The other work you describe is clearly happening, so I'm not seeing a problem with this approach other than its novelty for users. But to me it looks both clearer than the usual "issue soup" on a popular open source project and more effective at using maintainer time, so next time I open-source something I'd be inclined to try it.
Some people see "bug tracker" and think "a vetted report of a problem that needs fixing", others see "bug tracker" and think "a task/todo list of stuff ready for an engineer to work on"
Both are valid, and it makes sense to be clear about what the teams view is
Agreed. Honestly, I think of those as two very different needs that should have very different systems. To me a bug tracker is about collecting user reports of problems and finding commonalities. But most work should be driven by other information.
I think the confusion of bug tracking with work tracking comes out of the bad old days where we didn't write tests and we shipped large globs of changes all at once. In that world, people spent months putting bugs in, so it makes sense they'd need a database to track them all after the release. Bugs were the majority of the work.
But I think a team with good practices that ships early and often can spend a lot more time on adding value. In which case, jamming everything into a jumped-up bug tracker is the wrong approach.
I think these are valid concerns for a project maintainer to think through for managing a chosen solution but I don't think there is a single correct solution. The "correct", or likely least bad, solution depends on the specific project and tools available.
For bug reports, always using issues for everything also requires you to evaluate how long an issue should exist before it is closed out if it can't be reproduced(if trying to keep a clean issue list). That could lead to discussion fragmentation if now new reports start coming in that need to be reported, but not just anyone can manage issue states, so a new one is created.
From a practical standpoint, they have 40 pages of open discussion in the project and 6 pages of open issues, so I get where they're coming from. The GH issue tracker is less than stellar.
This is not a standalone article but a section from Butterick's book, "Typography for Lawyers", which is hosted in full on the website. The book is an opinionated style manual, and many alternatives are described in nearby sections.
