301–310 of 406 posts
Is this post AI-written? The repeated lists with highlighted key points, the "it's not just [x], but [y]" and "no [a] just [b]" scream LLM to me. It would be good to know how much of this post and this project was human-built.
This was either written by Claude or someone who uses Claude too much.
I wish they could be upfront about it.
Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... python in another realm here as well. That shiny c++ project that needs a bleeding edge boost version that is about 6 months away from being included in your package manager…
If you somehow experience an actual dependency issue that involves glibc itself, I'd like to hear about it. Because I don't think you ever will. The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it: https://lwn.net/Articles/605607/
Now, if you're saying it's a dependency issue resulting from people specifying wrong glibc version constraints in their build… yeah, sure. I'm gonna say that happens because people are getting used to pinning dependency versions, which is so much the wrong thing to do with glibc it's not even funny anymore. Just remove the glibc pins if there are any.
As far as the toolchain as a whole is concerned… GCC broke compatibility a few times, mostily in C++ due to having to rework things to support newer C++ standards, but I vaguely remember there was a C ABI break somewhere on some architecture too.
Earlier quoted context omitted.
LinkedIn and its robotic tone existed long before generative AI. Know what's more annoying than AI posts? Seeing accusations of AI slop for every. last. god. damned. thing.
Yes that's the point. LLMs pretty much speak LinkedInglish. That existed before LLMs, but only on LinkedIn. So if you see LinkedInglish on LinkedIn, it may or may not be an LLM. Outside of LinkedIn... probably an LLM. It is curious why LLMs love talking in LinkedInglish so much. I have no idea what the answer to that is but they do.
The actual mechanism, I have no clue.
Earlier quoted context omitted.
What's exhausting is getting through a ten-paragraph article and realising there was only two paragraphs of actual content, then having to wade back through it to figure out which parts came from the prompt, and which parts were entirely made up by the automated sawdust injector.
That's not an AI problem, it's a a general blog post problem. Humans inject their own sawdust all the time. AI, however, can write concisely if you just tell it to. Perhaps you should call this stuff "slop" without the AI and then it doesn't matter who/what wrote it because it's still slop regardless. I completely agree with your parent that it's tedious seeing this "fake and gay" problem everywhere and wonder what a…
I hardly ever go through a post fisking it for AI tells, they leap out at me now whether I want them to or not. As the density of them increases my odds of closing the tab approach one.
It's not a pleasant time to read Show HNs but it just seems to be what's happening now.
> The build.bat above isn’t just a helper script; it’s a declaration of independence from the Visual Studio Installer. I am so fed up with this! Please if you're writing an article using LLMs stop writing like this!
I never understood this sentence structure, it adds zero information, it always goes like: “This isn’t just [what the thing literally is]; it’s [hyperbole on what the thing isn’t].”
In the UK, Marks and Spencer have a long-running ad campaign built around it (“it’s not just food, it’s...”)
Em dashes are fine too.
Or... you can "winget install Microsoft.VisualStudio.BuildTools" "winget install Microsoft.WindowsSDK.10.0.26100"
Nearly all of the Windows hate i see comes from 20 year old takes . ( the bing/cortana / copilot / ads slop criticism is warranted, but is also easily disabled).
Earlier quoted context omitted.
But those are installed system wide. What if you have two different project with different requirements at the same time? Every language should have a tool like Python uv.
> What if you have two different project with different requirements at the same time? Install multiple versions of Windows SDK. They co-exist just fine; new versions don’t replace old ones. When I was an independent contractor, I had 4 versions of visual studio and 10 versions of windows SDK all installed at once, different projects used different ones.
One day I decided to port my text editor to Windows. Since it depends on pcre2 and treesitter, these two libraries had to be provided by the system. In the span of ~2hrs I didn't manage to find a way to please Zig compiler to notice "system" libraries to link against. Perhaps I'm too spoiled by installing a system wide dependency in a single command. Or Windows took a wrong turn a couple of decades ago and is very ho…
System wide dependencies is fundamentally an awful idea that is wrong and you should never ever do it. All dependencies should be vendored into your project.
Earlier quoted context omitted.
MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw. Git installs its own Mingw and Msys2 stuff but mostly compiled…
A repacked Cygwin is one environment, but the default uses the UCRT from Microsoft.
MSYS2 is there to just provide the basics so you can develop programs that are Windows native but use some of the tools that have really strong Unix dependence like shells or Make. They depend on the existence of syscalls like `fork` or forward slash being the directory seperator.
Earlier quoted context omitted.
MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw. Git installs its own Mingw and Msys2 stuff but mostly compiled…
I think you’re underestimating or discounting the work the MSYS2 team put into their layered environments mechanism: https://www.msys2.org/docs/environments/
Without Cygwin enabling the path, it wouldn't be possible to build GCC for Windows without completely changing its build system. It would be a DOA fork while Mingw and PE32+ support is a part of GCC nowadays.
The nice and genius part of MSYS2 is that it is there to primarily encourage you to develop native Windows software that has better cross-platform behavior rather than Cygwin alone. If Microsoft made a better, free of charge C compiler in early 2000s that is adhering to the standards better, we wouldn't probably need Mingw to build cross-platform apps. Now MSVC is still free of charge for only open source and individuals.
[1] "Cygwin POSIX emulation engine", https://packages.msys2.org/base/msys2-runtime [2] https://github.com/msys2/MSYS2-packages/tree/master/msys2-ru...