Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mephisto]

So are you expecting help or an ear?

[itisnotlogical]

This is why open source has a bad reputation:

cc1.exe - System Error

The code execution cannot proceed because libwinpthread-1.dll was not found. Reinstalling the program may fix this problem.

So much dependency hell.... and searching for the cause is just full of "why would you ever try to do the thing you are doing? Just do it this other way..." with incomplete instructions.

 

Or "It works for me, you must be stupid or something."

Or the only thing that does what you want is some stupid buggy cobbled-together Python script that hasn't been updated since 2003 and only works on a very specific combination of hardware.

[McTraveller]

Just an ear... I was tossing a coin between putting that here or in the "things that make you sad" thread.  But I figure there is more sympathy here in the programming thread 

[Magistrum]

You check the module's documentation and it tells you it works with some extra library, but you can't find that on any repository in the world, so you finally find an old forum post of a guy who said he actually found the whole thing in a webserver off-grid in the summit of Mount Everest and he's gonna post a link:

"last updated: 2004"

[Reelya]

Commercial stuff isn't that much better. Consider all the .NET bloat. That solves the above problem but now you have to keep a ton of bloated versions of .NET installed on everything, on the off-chance that some app uses some single component of some version of .NET. It's still dependency hell, except now you've front-loaded every possible dependency so you're never short. Open source could "fix" the issue of not having the required DLL, by doing what .NET does and bundle all possible DLLs to start with. But then who hasn't had the same issue of apps that won't work because you don't have the required versions of Microsoft's C Runtime or the right version of .NET installed?

Apple is worse, just gives a big "fuck you" if the version numbers of your software aren't the range supported by the exact version number of your operating system. I learned this the hard way trying to build for iOS. Specific version numbers of xCode are needed to build for specific ranges of iOS versions, and specific ranges of MacOS are needed for those specific versions of xCode. So you can't just do what you do on Windows, and boot up an old version of Visual Studio if you want and build for older C runtimes, everything has to match lockstep with everything else's version number. Yeah, so Apple solved the dependency problem by not letting anything run on anything except under very strict supervision. Instead of the "damn I have to download a DLL" issue, Apple just fixes it by going "run old software? Screw you, weirdo!"

However, Microsoft may have finally learned their lesson from the .NET bloat with the new .NET Core releases. These only package the needed dependencies for that particular program for the specific .NET Core version they were built for. So you don't have to have every single module of every variant of .NET Core on every machine.

The old .NET Framework system was like carrying no tools with you, except every work site you visit has all conceivable versions of all possible tools available at the site, then you move onto the next site, also carrying no tools, and that site also replicates every possible tool that anyone could possibly need, regardless of actual need. Like every job site has a rack of "hammers" with every possible type of hammer for you to select from, along with additional racks stretching into the horizon for all imaginable tool types.

Whereas .NET Core only compiles in the needed tools for the job, and carries its tools with it. If you didn't get the message, everyone should stop using old .NET and use .NET Core. Needing DLLs is a temporary nuisance while you get the DLLs you need. .NET bloat is permanent suckage, because so many apps use some small bit of each version number, so you can't get rid of any of it.

[Mephisto]

Needing DLLs is a temporary nuisance while you get the DLLs you need. .NET bloat is permanent suckage, because so many apps use some small bit of each version number, so you can't get rid of any of it.

If you want to put it that way, yeah.

If you want to put it another way, you're now compiling every bit of external code into every piece of software that uses it. Using the tool analogy that is completely inadequate for the task, it's like the worksite going "I have this hammer you can use" and all 50,000 programs going "no thanks, I have my own" and bringing identical hammers.

It's probably not an issue now given the price of storage. But if you were a bit counter in the past, I bet you'd have appreciated smaller executable sizes.

[Reelya]

That would be true, and it's the thinking behind .NET - why have 50,000 pieces of software bring 50,000 copies of the same module? However your point is predicated on a specific any very extreme scenario, that you have 50,000 apps bringing the one exact same module. And that's the thinking behind the original .NET Framework.

However, that's not the actual equation at play here. Real .NET ships with a zillion tools, and you have multiple ever-bigger versions of .NET on your system. Any one app only uses a very small subset of the available tools. There's going to be a cross-over point. If you have enough apps, and each one uses enough of .NET then at some point it's better to have a consolidated repository.

Microsoft switching to .NET Core basically answers the question of which approach works better. They've done the math here. You may have 50,000 components with code in them, but they're unlikely to be from 50,000 vendors. Each vendor can just make a DLL of the needed components for their .NET Core build and share the compiled tool among related .exes.

The reality is that you might have 20 installed packages installed that need .NET, and each one uses substantially less than 5% of the entire possible set of .NET components, so it's actually lighter to let each package bring their own tools, and keep .NET as a common development library rather than trying to ship it as a giant runtime library. Saying it's bloated to compile-in .NET Core is like saying C is bloated because you compile in the standard library code into the .exe, rather than pre-installing all possible C Libraries on the target machine.

[McTraveller]

The .NET philosophy is the same sort of plague as central repositories for web code: "just use this central library and it will be Great^TM".

Of course, I mostly work with embedded systems that only just now have 3MB flash and 256kB RAM (if you're lucky!).  So you can't afford libraries where you don't use part of it - you do statically link exactly and only what you need.

[LoSboccacc]

dependency hell is the quintessential "damned if you do, damned if you don't" conundrum.

[MorleyDev]

A lot of it just comes from the era the tech originated:

- .NET Framework was built for an era of centralized bare-metal or large virtual servers running many websites inside IIS, so sharing the framework allowed for caching and JIT optimizations.

- .NET Core is built for the modern era of containerization and cheap VMs running and of IoT, so is built around a core runtime with the ability to plug in and pre-JIT and package the dependencies.

[McTraveller]

So the SCotUS is going to hear that Google vs Oracle case about if APIs can be copyrighted.

I'm actually kind of nervous about what will happen here.

[Telgin]

Me too, since there's approximately zero chance any of the justices know what that really means.  I would hope they'd argue that much like you can't copyright rules, you can't copyright an API, but if you don't understand what an API is then you might not realize that's essentially what it does.

[MagmaMcFry]

What would change if APIs could be copyrighted?

[Reelya]

Well you couldn't make a PDF reader or such. It would force all platforms to roll their own incompatible standards to avoid the possibility of lawsuits. A lot of old software would probably break too, or be hard to get working, since it would be illegal to write code that interfaces with it. APIs includes file formats, whereas now the contents of a file can be copyrighted but not the actual format itself.

One real risk is an upsurge in patent trolls, since they can snap up the rights to a bunch of old software and claim copyrights on file formats and APIs from that era which is now used and assumed to be basic infrastructure.

[MorleyDev]

In the absolute most dystopian end result, you couldn't use a class with the same name and methods as any class written by another business.

In a much more realistic scenario, what you'd see is most modern public APIs from businesses like Microsoft and Amazon, as well as most active open source projects, introducing a clause allowing that API to be re-implemented by others, basically waiving any copyright. It'd be treated as another of the common clauses you see with open source.

But projects that reimplemented abandoned systems to allow them to be used by modern technology could be at risk, since those older systems will be treated as copyrighted-by-default and the original creators could pop up and copyright strike them. Or the rights could be sold to a patent-troll-style business who just go around shutting down or extorting money.

And any business that decided not to waive the rights, if they go away any APIs or systems they implemented will at best be locked in and only usable until technology changes break the ability to use them.

Plus the costs of fighting off 'copyright trolls' could be damaging to both businesses and innovative individuals.