4 ms·

I'm sorry to hear you feel afraid to learn more software development, but i think these concerns are largely unfounded. First of all, dependencies don't break j

I'm sorry to hear you feel afraid to learn more software development, but i think these concerns are largely unfounded. First of all, dependencies don't break just because they are unmaintained. If it worked ten years ago, it should still work now. For particularly complicated dependencies, there's a likelihood that they have bugs. But if they are popular, these bugs are often either things you probably won't ever come across or can work around if you do. Finally, the beauty of open source software is that you can fix things yourself! Found a package from 10 years ago that works 99% of the time, but you just need to fix one thing or add one tiny feature? Not a problem, you fork the repo and add what you need.

fermienrico 6y ago
> Finally, the beauty of open source software is that you can fix things yourself! Don't you need proper domain knowledge to hack into the some obscure error for svg conversion inside of cairo? All you were trying to do is to display the company logo.svg from your graphics department who exported it on Illustrator version 5.0 because our company is too poor to go to subscription model for Adobe. May be something goofy in the svg data. You spend next days fixing this open source package, ranting on stackoverflow and finally have to concede and file an bug report on Github. It gets rejected because you have not gathered all the necessary details to file a bug report including proper stack traces and operating system information.
- krisoft 6y ago
  if all you want to display is one logo then you fix the logo not cairo. You are more in trouble if your busines is accepting svg-s your users upload and only a minuscule amount breaks for unknown reasons.
dx87 6y ago
Gotcha, thanks for the feedback. I've never done professional software development, it's just something I picked up to broaden my skillset, so it's good to know that the concerns aren't really an issue in practice. Regarding fixing bugs in the dependencies, I think that's like a chicken/egg problem for me. I use the dependencies because I don't have the time or skill yet to make the functionality on my own, which means I also don't have the time/skills to fix bugs in the dependencies. I think I probably have to buckle down and get over that hump to be confident enough to make bigger projects that need more dependencies.
- smichel17 6y ago
  Skillset -- reading other people's code - especially if you can get to the point where you understand it well enough to fix bugs in it - is a great way to work on building your skillset. Time -- yes.
- james_s_tayler 6y ago
  Part of the skillset is evaluating dependencies on how well they fit with your goals both technical and strategic and what level of risk/benefit they pose, and how those dependencies are places in their respective ecosystem. Usually any ecosystem has a core set of dependencies that are heavily relied on by most or a lot of projects as the go-to solution for a given problem. Then there are often sets of dependencies where there are several popular well maintained choices to pick from depending on your needs. Where it gets a little trickier is things that are a bit more niche. That being said, most software development just wouldn't be possible without standing on the shoulders of giants so to speak cos it's just so time consuming. They're far more of a benefit than a detriment but you have to learn to assess them and make choices based on your individual considerations.
chrismorgan 6y ago
Dependencies do break because they are unmaintained. All the time. If it worked ten years ago, there is no guarantee whatsoever that it will work now, unless you: (a) run it in an environment of ten years ago (otherwise other platform dependencies may be unavailable, or platform behaviour may have changed); (b) ensure that environment is already fully set-up (otherwise internet systems from which it fetches other dependencies may be unavailable, e.g. due to a service being taken down or certificate changes); and (c) are using strictly offline-capable software (e.g. if a commercial library does an activation/licensing server check, that may fail). In other words, to be confident, you need to freeze a snapshot of the entire system, which is obviously terrible for security. If these conditions are not met, things may or may not work. Some platforms will be more robust over time than others. Scripting languages are generally atrocious, with an installability half-life well under ten years (I’m going to guess something around five years). Compiled languages are a mixed bag. Rust is one of the best options out there, so long as it’s pure Rust code only and doesn’t include any bindings on more build-fragile code. I shall give a few examples of the sorts of problems that can occur and have occurred to me in the last decade. • In 2012 I wanted to install IE6 on a Windows 2000 machine (don’t ask). But the underlying infrastructure at Microsoft was gone, so even if I had the full installer, it failed to install. • A few years ago I wanted to install something that depended (transitively) on some key foundational Perl package, but due to recent Linux kernel changes that package’s tests no longer passed. (Perl defaults to running the tests when you install. You can disable that, but clearly the software isn’t running as expected.) Fortunately the package was maintained, so I just had to install the newer version, overriding the stated dependencies. • You could be trying to install something with Node.js and it doesn’t work beyond Node 0.12 or 4 or something, so you’ll need to figure out how to get that old version of Node before you have any hope of running the project. And that probably means “figure out how to build it from source”, which is harder than you might hope, because it probably depends on old versions of libraries that used to be easy to get from your OS’s package manager, but are now unavailable, so you’ll have to build them from scratch too, recursively. • I used to use Hyde to generate my website. A couple of years ago, five years or so after it was abandoned, it had become very tedious at best to install anew, due to being part of the declining Python 2 ecosystem. A few years ago I think I tried setting it up on Windows and gave up after a while, though that’s hardly a fair comparison on its own. On my server, I had used https://aur.archlinux.org/packages/hyde-git https://aur.archlinux.org/packages/hyde-git to install it, but that’s no longer installable, because it depended on packages in the community repository that have been removed and have not resurfaced in AUR. This is probably not insurmountable, as you can probably install the package in other ways, but it indicates that the way that I had installed it has broken. I had two or three more examples in mind, but I’ve just been called for lunch. So just one more note: use lockfiles, they’ll normally make things more robust, but be ready to need to update some of those dependencies in order to get things to work at all a few years down the track, and you’ll be practising trial and error over which.
kabacha 6y ago
When I started Python development I felt exactly like OP did. There was this unmaintained library that didn't support Python3 and was breaking everything — turns out it took 15 minutes to change few print and import statements to get it working perfectly.

fermienrico 6y ago

> Finally, the beauty of open source software is that you can fix things yourself! Don't you need proper domain knowledge to hack into the some obscure error for svg conversion inside of cairo? All you were trying to do is to display the company logo.svg from your graphics department who exported it on Illustrator version 5.0 because our company is too poor to go to subscription model for Adobe. May be something goofy in the svg data. You spend next days fixing this open source package, ranting on stackoverflow and finally have to concede and file an bug report on Github. It gets rejected because you have not gathered all the necessary details to file a bug report including proper stack traces and operating system information.

krisoft 6y ago
if all you want to display is one logo then you fix the logo not cairo. You are more in trouble if your busines is accepting svg-s your users upload and only a minuscule amount breaks for unknown reasons.

dx87 6y ago

Gotcha, thanks for the feedback. I've never done professional software development, it's just something I picked up to broaden my skillset, so it's good to know that the concerns aren't really an issue in practice. Regarding fixing bugs in the dependencies, I think that's like a chicken/egg problem for me. I use the dependencies because I don't have the time or skill yet to make the functionality on my own, which means I also don't have the time/skills to fix bugs in the dependencies. I think I probably have to buckle down and get over that hump to be confident enough to make bigger projects that need more dependencies.

smichel17 6y ago
Skillset -- reading other people's code - especially if you can get to the point where you understand it well enough to fix bugs in it - is a great way to work on building your skillset. Time -- yes.
james_s_tayler 6y ago
Part of the skillset is evaluating dependencies on how well they fit with your goals both technical and strategic and what level of risk/benefit they pose, and how those dependencies are places in their respective ecosystem. Usually any ecosystem has a core set of dependencies that are heavily relied on by most or a lot of projects as the go-to solution for a given problem. Then there are often sets of dependencies where there are several popular well maintained choices to pick from depending on your needs. Where it gets a little trickier is things that are a bit more niche. That being said, most software development just wouldn't be possible without standing on the shoulders of giants so to speak cos it's just so time consuming. They're far more of a benefit than a detriment but you have to learn to assess them and make choices based on your individual considerations.

chrismorgan 6y ago

Dependencies do break because they are unmaintained. All the time. If it worked ten years ago, there is no guarantee whatsoever that it will work now, unless you: (a) run it in an environment of ten years ago (otherwise other platform dependencies may be unavailable, or platform behaviour may have changed); (b) ensure that environment is already fully set-up (otherwise internet systems from which it fetches other dependencies may be unavailable, e.g. due to a service being taken down or certificate changes); and (c) are using strictly offline-capable software (e.g. if a commercial library does an activation/licensing server check, that may fail). In other words, to be confident, you need to freeze a snapshot of the entire system, which is obviously terrible for security. If these conditions are not met, things may or may not work. Some platforms will be more robust over time than others. Scripting languages are generally atrocious, with an installability half-life well under ten years (I’m going to guess something around five years). Compiled languages are a mixed bag. Rust is one of the best options out there, so long as it’s pure Rust code only and doesn’t include any bindings on more build-fragile code. I shall give a few examples of the sorts of problems that can occur and have occurred to me in the last decade. • In 2012 I wanted to install IE6 on a Windows 2000 machine (don’t ask). But the underlying infrastructure at Microsoft was gone, so even if I had the full installer, it failed to install. • A few years ago I wanted to install something that depended (transitively) on some key foundational Perl package, but due to recent Linux kernel changes that package’s tests no longer passed. (Perl defaults to running the tests when you install. You can disable that, but clearly the software isn’t running as expected.) Fortunately the package was maintained, so I just had to install the newer version, overriding the stated dependencies. • You could be trying to install something with Node.js and it doesn’t work beyond Node 0.12 or 4 or something, so you’ll need to figure out how to get that old version of Node before you have any hope of running the project. And that probably means “figure out how to build it from source”, which is harder than you might hope, because it probably depends on old versions of libraries that used to be easy to get from your OS’s package manager, but are now unavailable, so you’ll have to build them from scratch too, recursively. • I used to use Hyde to generate my website. A couple of years ago, five years or so after it was abandoned, it had become very tedious at best to install anew, due to being part of the declining Python 2 ecosystem. A few years ago I think I tried setting it up on Windows and gave up after a while, though that’s hardly a fair comparison on its own. On my server, I had used https://aur.archlinux.org/packages/hyde-git https://aur.archlinux.org/packages/hyde-git to install it, but that’s no longer installable, because it depended on packages in the community repository that have been removed and have not resurfaced in AUR. This is probably not insurmountable, as you can probably install the package in other ways, but it indicates that the way that I had installed it has broken. I had two or three more examples in mind, but I’ve just been called for lunch. So just one more note: use lockfiles, they’ll normally make things more robust, but be ready to need to update some of those dependencies in order to get things to work at all a few years down the track, and you’ll be practising trial and error over which.

kabacha 6y ago

When I started Python development I felt exactly like OP did. There was this unmaintained library that didn't support Python3 and was breaking everything — turns out it took 15 minutes to change few print and import statements to get it working perfectly.