Do not upgrade
-
@Bulb Last time I followed this guide:
Install Docker on Windows (WSL) without Docker Desktop
Updated April 10, 2022, with current Alpine instructions, Debian/Ubuntu package signing tweaks (no...
-
@magnusmaster said in Do not upgrade:
Shouldn't only major version updates have breaking changes?
Shouldn't
-
@JBert said in Do not upgrade:
@Bulb Last time I followed this guide:
Install Docker on Windows (WSL) without Docker Desktop
Updated April 10, 2022, with current Alpine instructions, Debian/Ubuntu package signing tweaks (no...
Thanks. My question was about the Windows containers though (it might have gotten a bit lost in the context).
-
@Bulb said in Do not upgrade:
@dangeRuss said in Do not upgrade:
I mean yes you can start the docker using a start file, but you can't like just start up a centos docker for example and start the httpd service in there.
The point of docker is that you have a container for just that one app. So you simply give
httpdas the command to run when starting the container. And you can tell docker to “restart=always” and it will automatically start it after reboot or if it crashes. You can also tell it to run a small helper init that reaps zombies if you have a program that spawns a lot of children and detaches them.@dangeRuss said in Do not upgrade:
Or maybe I'm just confused and you just can't do that in WSL.
WSL indeed by default does not have init, and it is an obstacle among other things when trying to get docker running in it, because docker normally expects to be running under systemd.
Well the docker would run on the windows side and integrate with WSL, so not really an obstacle.
-
@dangeRuss It is an obstacle for the containerd “bottom half” of docker that runs inside WSL.
-
@Bulb said in Do not upgrade:
@dangeRuss It is an obstacle for the containerd “bottom half” of docker that runs inside WSL.
Not sure what you mean. Once I start up docker desktop (which can be annoying sometimes as it is a bit heavy), the docker command inside WSL2 just works.
-
@dangeRuss Yes, if you use docker-for-desktop, then it will do all the necessary workaround to start docker engine and containerd in WSL. If you just install docker engine in WSL—which is otherwise completely sufficient—you have to work around the lack of init.
-
@Bulb said in Do not upgrade:
@dangeRuss Yes, if you use docker-for-desktop, then it will do all the necessary workaround to start docker engine and containerd in WSL. If you just install docker engine in WSL—which is otherwise completely sufficient—you have to work around the lack of init.
Yea, so I heard something about docker-desktop not being free anymore going forward, so we might need to switch to the other method.
-
Man...Docker. Our attempts at using Docker where I'm currently at have never gone well, especially considering we have devs using Windows and Macs and generally run our client websites on Linux servers so the combination of Vagrant and VirtualBox has proven to be a nice middle of the road compromise we can get to work pretty seamlessly on everyone's machines. Seeing as how you can replicate essentially the same Linux server setup as the staging/production servers and you don't have to worry about what the devs have installed locally (aside from vagrant and virtualbox of course). It's really nice when you have to clone a repo of a 5 year old project that uses Node.js, Gulp, Jekyll and other crap that will very likely not work on the devs local machine any more.
YMMV though.
-
@magnusmaster said in Do not upgrade:
Shouldn't only major version updates have breaking changes?
No, you remember that totally wrong.
The correct sentence is:Major version updates must have breaking changes.
-
@CodeJunkie We have a couple of projects that use Linux containers and our experience has been mostly positive once people got the basic hang of it. It's not really that different from using Vagrant, because the containers still run in a Linux VM (or now WSL on Windows, which is effectively slightly lighter-weight VM anyway. And Dockerfiles seem a bit easier to work with than Vagrantfiles.
Plus, the main point of containers is that you can test it locally, then you push it to the dev, then test and then production environment. Exactly the same container, the only difference is a couple of environment variables, so you have lower risk of incompatibilities between the environments (of course you can still have incompatible database schema or some other service, but the number of variables is much lower).
-
@BernieTheBernie said in Do not upgrade:
No, you remember that totally wrong.
The correct sentence is:Major version updates must have breaking changes.
Are you sure it's not "version updates must have major breaking changes"?
-
Security issue: compromised npm packages of ua-parser-js (0.7.29, 0.8.0, 1.0.0) - Questions about deprecated npm package ua-parser-js · Issue #536 · faisalman/ua-parser-js
Hi! See a warning at npm - https://www.npmjs.com/package/ua-parser-js - This package has been hijacked. Please revert to 0.7.28 First question - Can we use range ^0.7.28, or it is not safe? Second ...
-
The more I read about this web UI shit, the more I'm glad I don't have to do anything with it. Working half the time inside the FreeBSD kernel, half the time in userland but in close symbiosys with the kernel part of our code, I can sit back and read about e.g. leftpad and just laugh at y'all.
Enjoy.
-
@Steve_The_Cynic completely agree.
As much as people rag on at PHP, we don't have half the same bullshit as the JS folks because 1) we spent long enough without dependency management that we understood how to behave like adults, 2) our standard library is not woefully awful and lacking in features (just Disconsistent) and 3) our package repos are less prone to this fly-by-night nonsense because we've been aronud and seen this before, and 4) because of all of the above we tend to not glom 3000 packages to do anything in the first place.
There are those of us who knowingly do it wrong by checking in all the packages we did import into our repo so that we can vet the code we have, deploy it without any additional dependencies beyond 'here is my SCM and here is my CI/CD pipeline' and know that what we tested on is literally what we're shoving out the door without any guesswork or making sure we used the right ^ or whatever symbols.
But it's still bullshit. I remember the days when inclusion of third party libraries required effort and planning, if you didn't bring your own to the party.
-
@boomzilla said in Do not upgrade:
Security issue: compromised npm packages of ua-parser-js (0.7.29, 0.8.0, 1.0.0) - Questions about deprecated npm package ua-parser-js · Issue #536 · faisalman/ua-parser-js
Hi! See a warning at npm - https://www.npmjs.com/package/ua-parser-js - This package has been hijacked. Please revert to 0.7.28 First question - Can we use range ^0.7.28, or it is not safe? Second ...
-
@Arantor said in Do not upgrade:
But it's still bullshit. I remember the days when inclusion of third party libraries required effort and planning, if you didn't bring your own to the party.
-
@boomzilla said in Do not upgrade:
@boomzilla said in Do not upgrade:
Security issue: compromised npm packages of ua-parser-js (0.7.29, 0.8.0, 1.0.0) - Questions about deprecated npm package ua-parser-js · Issue #536 · faisalman/ua-parser-js
Hi! See a warning at npm - https://www.npmjs.com/package/ua-parser-js - This package has been hijacked. Please revert to 0.7.28 First question - Can we use range ^0.7.28, or it is not safe? Second ...
-
@Arantor We're (mostly) a Node.js/Typescript house, with some PHP (that we'd like to get rid of), a half-implemented Vue.js front end, plus some legacy stuff in Perl and client apps in Java/Kotlin and Objective-C/Swift (depending on the product).
But even in our Node side we try to keep outside dependencies minimal. I think my main product has dependencies on
- express.js (our server core, not something we want to write ourselves)
- the Mysql libraries
- (dev side) a testing framework
- an HTTP request library for the few cases where we need to send requests.
- and a few other small libraries (one to handle configuration files, one to output csv with less pain, one to do request body schema validation
But then of course there are the transitive dependencies. Which are...large and numerous. Sigh.
-
@Unperverted-Vixen said in Do not upgrade:
@Gąska said in Do not upgrade:
I know
is a popular philosophy but what's with people thinking dependency management is not part of a developer's job description?It's part of the job description, but the dependencies for even a simple "Hello, World" web page have spiraled out of control. We've gone from "everything you need ships with the OS as part of the .NET install" c. 2008 to "here's your 20 billion packages making up ASP.NET Core, plus another 10,000 npm packages for your client-side JavaScript to make it pretty".
Using .NET—a gigabyte-sized thing with methods somewhere in the 100,000s—for a "Hello world" web page is quite a bit closer to the current state of affairs already than to what it originally involved: using
catto slap a small text file into/var/www/htdocsand enabling your favorite httpd service.
-
@LaoC said in Do not upgrade:
enabling your favorite httpd service.
And how much space did your favorite httpd service occupy?
It's other people's code all the way down.
-
@Gąska said in Do not upgrade:
@LaoC said in Do not upgrade:
enabling your favorite httpd service.
And how much space did your favorite httpd service occupy?
A couple hundred KB for lighttpd or just under 10 MB (disk) for apache2.
-
Well, in order to host my website, I use butterflies!
And I do it uphill both ways!
-
Sure odds are someone else’s code is in the way - I don’t roll my own HTTP server from scratch in assembler because I’m not insane.
But there is a difference between responsibly pulling in third party libraries that you can and have vetted , and whatever the ever-loving fuck the npm community has normalised.
I used to work on a platform whose npm manifest specified 4 dependencies, which were all geared to compiling LESS/SCSS to CSS, which seems pretty normal in the web world, plus a linter plus grunt to run the different things. This spawned north of 3300 packages being installed.
Leftpad demonstrated several things - not least the lack of sensible fallbacks when people take their toys and go home. It highlighted an obvious hole in the language standard library, but it also shows how happy people are to pull in third party libraries rather than weighing up the question of rolling their own.
It also pretends the network has infinite bandwidth and zero connectivity issues.
And that’s before we talk about supply chain attacks. Or even the muppets who do this to themselves by importing misspelled libraries like the folks who pull in expresss with all 3 s’s on the end…
-
-
@Arantor Not really my department, but as I understand our thirdparty approval procedure requires going through the thirdparty approval procedures for all the dependencies of the thing you're wanting to add a dependency on. Recursively.
There are internal users of NPM. I think there's a curated repository, but it's also not something I deal with.
-
@Arantor said in Do not upgrade:
I’m not insane.
But you're totally right to call the npm ecosystem a dumpster fire, or maybe even a whole garbage tip inferno.
-
@PleegWat if you’re going to get every dependency you pull in, implicitly and explicitly, fair play. It’s just going to suck, hard.
-
@dkf well, I meant it specifically in the context of not building my own web server from scratch.
That reminds me I need to write the topic explaining why I am TRWTF. Will do that shortly.
-
@Arantor said in Do not upgrade:
it also shows how happy people are to pull in third party libraries rather than weighing up the question of rolling their own.
I think JavaScript itself takes a bit of the blame for that, because it's one of these languages where the simple and obvious way of doing anything is likely to be subtly wrong and may suddenly break in the most surprising ways given new input. That tends to make people think twice about rolling their own even if the problem seems trivial.
-
@ixvedeusi I think that’s only part of the problem, though. Certainly part of the problem is that the core standard library is a mess where different implementations aren’t consistent in the browser and as an industry sliding in polyfill libraries became fairly normal for a while.
So people coming to Node are already coming from web land with an expectation of bundling libraries to work around inconsistencies in the first place. Then bolt on how inconsistent the standard library is anyway (left pad should not really need a library if the standard library is sane) and you have a recipe for people being not merely ok with third party libraries but enthusiastic about it.
The part that kills me is that in language terms, JavaScript is about as old as PHP and Ruby and yet it isn’t learning the lessons the other two did.
For example I see things like Babel and i think “what combination of circumstances led you to the point of concluding that this was the best possible solution to your problem?” Now, I have myself seen some limited cases of this even in PHP - around 15 years ago when PHP 5 OOP started to become sane but PHP 5 adoption was lagging behind and apps that cared about being easy to install spent the effort doing class loaders that dynamically “fixed” things (e.g. rewrote public/protected/private to whatever PHP 4 supported) but it was never meant to become an industry-wide solution, it was a stopgap until hosts upgraded.
Fortunately in PHP land, PHP 7 gave enough hosts enough performance improvement that most of the small and mid tier hosts either offer multiple versions for their users or are at least in something reasonably supported. The outliers are the massive folks like GoDaddy with their custom infrastructure but even they too are catching up, meaning that you likely won’t have this nonsense in PHP so much where major transpilation works are necessary.
-
@Arantor said in Do not upgrade:
Certainly part of the problem is that the core standard library is a mess where different implementations aren’t consistent in the browser and as an industry sliding in polyfill libraries became fairly normal for a while.
Completely agree, the "base" environment is at least as much part of the problem.
@Arantor said in Do not upgrade:
in language terms, JavaScript is about as old as PHP and Ruby and yet it isn’t learning the lessons the other two did
I don't think that's entirely fair to say. From the little I know about "recent" javascript, there seem to have been efforts to clean up the language itself at least, with things such as 'strict' mode and modules for example. The main problem (and what AFAICT Babel and polyfills are aimed at solving) is that you can't know what implementation your code is gonna run on, you're expected to support all the versions of all of them back to the early noughties, and they are all wildly different in level of support and built-in functionality.
And of course since these problems are now "solved" the incentive to do something about the fundamental issues have drastically decreased.
-
@ixvedeusi that’s the thing though, talking to people who use this platform, it’s ridiculously easy to get the impression it’s less about “supporting everything back to the dawn of time” and really about supporting “literally not bleeding edge”.
Things have come a long way since the likes of jQuery were “reasonably necessary”, granted, but supporting back to “the early naughties” is not what a lot of these hipster people care about.
Hell, half of them only test in Chrome, not even the Chrome-a-likes, let alone current Firefox, so they sure as shit won’t care about compatibility back to the dawn of time. They throw things in because they realise that they need to support not bleeding edge, and any historical compatibility beyond that is a bonus.
I generalise, of course, because I’m sure it’s not every web dev. But it’s too many of them for my liking and at some point
became me.I swear writing cross browser code even for older forms of browser was never this janky and didn’t have the need for transpilers because we didn’t have transpilers.
-
@Arantor said in Do not upgrade:
half of them only test in Chrome
But then I only have a very small set of users — about 10 — that I need to care about in that application, and the only dependencies I have are strictly built-time only (i.e., the typescript compiler and the minimiser, neither of which is part of the deployment package). And I've chosen a language profile that's pretty conservative; I simply don't need anything very fancy in this app.
-
@dkf said in Do not upgrade:
minimiser
I believe the politically correct term is "frugal small person". :bad-joke-eel:
-
@dkf said in Do not upgrade:
But then I only have a very small set of users — about 10 — that I need to care about in that application
Only ten?
Just about as much as it took formaketo have fucked up syntax backwards compatible for 45 years.
-
@dkf if you have an audience of 10, that seems reasonable to keep your profile down in terms of user testing. But you’re sensible, unlike most of the folks I’ve spent the last decade simply being better than, heh.
-
@topspin said in Do not upgrade:
Only ten?
The service API will have a lot more users. The web interface that's to check what's going on (replacing a whole stack of Python command-line tools that nobody could ever remember and which scaled badly) won't.
-
@Arantor said in Do not upgrade:
But it's still bullshit. I remember the days when inclusion of third party libraries required effort and planning, if you didn't bring your own to the party.
I would argue that it still requires effort and planning if you want to do it right (controlled environment, ship-what-you-tested, etc., as you described), but that, especially for JS environments, some fine people(1) have built tools to allow it to be physically possible to import stuff without bothering with those things.
(1) As always, coded language for "prime fucknuts".
-
@Arantor said in Do not upgrade:
I don’t roll my own HTTP server from scratch in assembler because I’m not insane.
In a kernel module for more fun!
-
@Steve_The_Cynic I’ll rephrase that to better reflect intent.
I remember the days when inclusion of third party libraries required effort and planning, if you didn't bring your own to the party, so inevitably people actually bothered putting some of the effort in.
-
@Arantor said in Do not upgrade:
I remember the days when inclusion of third party libraries required effort and planning, if you didn't bring your own to the party, so inevitably people
actually bothered putting some of the effort inreinvented the wheel time and time again.FTFY
-
@dkf said in Do not upgrade:
@Arantor said in Do not upgrade:
I remember the days when inclusion of third party libraries required effort and planning, if you didn't bring your own to the party, so inevitably people
actually bothered putting some of the effort inreinvented the wheel time and time again.FTFY
There’s always a balance to be struck. But what’s wrong with reinventing leftpad instead of bringing in an external dependency? It’s literally like 3 lines.
(I assume just from the name, no idea if the module did anything else)
-
@Arantor said in Do not upgrade:
left pad should not really need a library if the standard library is sane
I'd like to note that this did land in the standard, but was named
String.prototype.padStartbecause a) it needed to not conflict with existing implementations, and b) something something right-to-left languages.The standard keeps getting updated with common features like this, but because people are already using the obvious names, they end up with stupid names. See:
globalThis(instead of justglobal),Map.prototype.emplace(instead ofupsert),Array.prototype.includes(instead of the more obviouscontainsorhas),Array.prototype.some(homophone withsum, instead ofany), et al.
-
The thing about libraries is that sometimes it’s worth the effort to bring them in, vet them, etc. And sometimes it’s not.
Leftpad is the slippery slope version - for most cases you could one line it even in the hellscape that is JS.
E.g. zero padding a number to 5 digits, need not be more than:
("00000" + var).slice(-5)But anyway, pulling in libraries meant you have to do some work yourself and that meant more people considered the costs of pulling in third party code rather than the current free-for-all world.
I still remember the time that a coworker and I had to do some CSV munging, they spent 3 days looking through a library they’d found that was basically just 1500 lines of unit-tested abstractions over the same functions I was using in code PHP… and when we had some data come in with backslashes in it, this was the end of the world because “how will we fix a bug in the library?” It wasn’t a bug, it was just wrong configuration… where the default function in PHP has a default escape character of \… that the library just doesn’t document but exposes anyway.
But it’s just easier for everyone to glom all the libraries. Glue all the APIs.
-
@Arantor said in Do not upgrade:
The thing about libraries is that sometimes it’s worth the effort to bring them in, vet them, etc. And sometimes it’s not.
The problem with
unprotected seximporting libraries is that you're importing everything they imported, and everything those libraries imported, and so on, and so on...
-
I just had to fix the bot again because I upgraded Node, which broke webgl bindings, which was needed for canvas, which was needed for jsdom, which was needed for HTML scraping (used by many modules, including XKCD).
-
-
@Arantor said in Do not upgrade:
But it’s just easier for everyone to glom all the libraries. Glue all the APIs.
The good libraries to adopt are the ones that cover an area properly and that have truly solid testing regimes so that you can know that the weird edge cases have been thought about and handled sanely. Good documentation is another very strong positive.
-
@dkf said in Do not upgrade:
weird edge cases have been thought about and handled sanely. Good documentation is another very strong positive.
