Live data from Hacker News

I fixed Windows native development

marler8997.github.io

111–120 of 406 posts

Re: I fixed Windows native development

#111

Earlier quoted context omitted.

you know why LLMs repeat those patterns so much? because that's how real humans speak

Real humans don't speak in LinkedIn Standard English

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.

Re: I fixed Windows native development

#112
post #85
post #64

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…

Which has been fixed on .NET 5 and later. .NET Framework should only be used for legacy applications. Unfortunately there are still many around that depend on .NET Framework.

.Net Framework 4.8 has a longer life cycle as the current .NET version

Re: I fixed Windows native development

#113
post #64

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…

> python in another realm here as well

uv has more of less solved this (thank god). Night and day difference from Pip (or any of the other attempts to fix it honestly).

At this point they should just deprecate Pip.

Re: I fixed Windows native development

#114
post #64

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…

When was the last time you actually used. NET? Because that's absolutely not how it is. The. NET runtime is shipped by default with Windows and updated via WU. Let alone that you're talking about .NET Framework which has been outdated for years.

.NET versions are faster outdated then .Net Framework 4.8

Re: I fixed Windows native development

#115
post #64

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…

> Toolchains on linux are not clear from dependency hell either - ever install an npm package.

That's where I stopped.

Toolchains on linux distributions with adults running packaging are just fine.

Toolchains for $hotlanguage where the project leaders insist on reinventing the packaging game, are not fine.

I once again state these languages need to give up the NIH and pay someone mature and responsible to maintain packaging.

Re: I fixed Windows native development

#116
post #99

I hope it would work with wine. Then cross compiling Win64 binaries from Linux would become convenient without requiring spinning up a Windows VM.

Yeah I noticed wine wasn't able to execute the MSI files. It also had a problem with the lock files. Both problems should be fixable though.

Re: I fixed Windows native development

#117

Earlier quoted context omitted.

MSYS2 is horrible. It brings a massive runtime environment and is a bad idea to foist on users.

Aren’t you thinking of Cygwin, or the MSYS2 shell (dev tooling)? The Windows-native software you build with MSYS2 can be shipped to and run by users that don’t have anything of MSYS2 installed.

He must be thinking of Cygwin as half of this is installed when you install git ;) Git Bash, etc…

Re: I fixed Windows native development

#118

Earlier quoted context omitted.

Real humans don't speak in LinkedIn Standard English

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.

Re: I fixed Windows native development

#119
post #64

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…

>Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath?

That seems more a property of npm dependency management than linux dependency management.

To play devil's advocate, the reason npm dependency management is so much worse than kernel/os management, is because their scope is much bigger, 100x more package, each package smaller, super deep dependency chains. OS package managers like apt/yum prioritize stability more and have a different process.

Re: I fixed Windows native development

#120

Earlier quoted context omitted.

you know why LLMs repeat those patterns so much? because that's how real humans speak

Real humans don't speak in LinkedIn Standard English

"LinkedIn Standard English" is just the overly-enthusiastic marketing speak that all the wannabe CEOs/VCs used to spout. LLMs had to learn it somewhere
Post reply on HN