[HN Gopher] The software industry is going through the "disposab...
___________________________________________________________________
The software industry is going through the "disposable plastic"
crisis
Author : ColinWright
Score : 63 points
Date : 2020-08-20 21:38 UTC (1 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| DangitBobby wrote:
| As long as you vendored your dependencies it all actually still
| should run fine. Bitrot is not a new phenomenon. But it is
| incredibly frustrating.
| reissbaker wrote:
| I've found that the further back in time you go, the harder it is
| to run programs without encountering odd bugs, until you hit a
| certain inflection point where the systems are so old that
| they're relatively simple to emulate, and for popular systems we
| often have high-quality emulators that are capable of running the
| software reasonably well. For example, try running Diablo 2
| (released in 2000!) on modern Windows, or modern macOS: it's not
| straightforward or bug-free, in my experience. It's reasonably
| good on Wine, ironically -- because the Wine developers have
| built a really good emulation layer.
|
| I don't think it's (application) developer fads; how would that
| even make sense? Either the OS broke userland, or it didn't; if
| it didn't, then the same binary should run just as well today as
| it did then. If it _did_ break userland, that 's not the fault of
| application or framework developers.
| melindajb wrote:
| cleaning up unicorn poop has been an excellent business. Nice to
| see it will continue for awhile.
| celim307 wrote:
| My buddy has built an entire career hopping to late stage start
| up after late stage startup and refactoring rails into java
| phkahler wrote:
| >> and refactoring rails into java
|
| Oooh planning ahead for round 2.
| ssivark wrote:
| The rich irony is that the problem is probably due to our
| reluctance to throw-away old code and rewrite better software
| with improved domain understanding. But that requires thoughtful
| and disciplined stewardship. Instead we recklessly patch leaky
| abstractions on top of each other because we're too lazy to work
| from scratch and are focused on "shipping" instead (cue:
| Titanic).
|
| We are so afraid of reinventing the wheel and actually having to
| understand something that we will happily refactor out a car
| wheel and use it for a bicycle (hey, "code reuse"!) and play the
| charade of "best practices".
|
| Software is one context where we don't have to worry about
| "disposing off" waste; we ought to make much better use of that.
| ricksharp wrote:
| Perhaps the issue is that it is far cheaper and easier to start
| from scratch and create a small app these days.
|
| As we innovate exponentially faster and have better tools and
| languages, it is far easier to tear the building down and start
| over.
|
| Also, I don't know of a single app I use regularly that is older
| than a few years.
| crazygringo wrote:
| I'm very confused. What does it matter, for running old software,
| whether a framework was a fad or not? And what does a "brittle"
| dependency even mean in this context?
|
| If you're trying to preserve software, you've got two options.
|
| One, you can preserve the binary and run it with emulation. For
| webapps, this means preserving a deployable image. Your
| faddish/brittle dependencies are 100% irrelevant, because your
| image includes them already, right?
|
| Or two, you can preserve the source code. Which for _any_ project
| is going to involve a mess of complicated tooling that dates to
| when the project used to be compiled. But if you 're intending to
| preserve something for the long term, you should preserve the
| dependencies too -- e.g. node modules or whatever.
|
| I don't really see what's different.
| aninteger wrote:
| I don't know... Can I run Netscape Navigator on Ubuntu 20.04? How
| about Gtk 1.2 programs or old Qt3 programs? Can I run Opera 12.x?
| agentdrtran wrote:
| I really, really doubt I can run most 1980s software on a modern
| machine without effort.
| fortran77 wrote:
| I can run 80s software on a modern PC very easily.
| NegativeLatency wrote:
| Depends on which software you're talking about, DOS box is
| pretty easy to use.
| phkahler wrote:
| But it's probably not too hard. Try running something that
| needs Flash player, or IE6.
| the8472 wrote:
| Microsoft offers virtual machine images for that.
| jeffhuys wrote:
| You can find them here:
|
| https://developer.microsoft.com/en-us/microsoft-
| edge/tools/v...
| rubber_duck wrote:
| Setting up a XP VM shouldn't be that hard.
| sudosysgen wrote:
| I do it every day, it's quite easy actually.
| jimmaswell wrote:
| For that to be true, there would have to be no actual domestic
| crisis, with poor countries with lax oversight responsible for
| 99% of the damage, but with politicians passing laws making our
| lives worse at home because it makes uninformed people feel good.
|
| I'm stocking up on plastic straws and bags while I can.
| leafmeal wrote:
| Why 2005?
| HenryKissinger wrote:
| Windows Vista.
| pdw wrote:
| That's about the start of the Ruby on Rails hype.
| nirse wrote:
| I had to get a Rails project from 2008 back up and running
| not so long ago, wasn't much more trouble than compiling ruby
| 1.8.7 (or was it 1.9.3?) and installing some gems.
| Admittedly, there were only a few dependencies in the project
| outside rails itself.
| NegativeLatency wrote:
| Don't forget the JS builder/bundler explosion
| sjy wrote:
| I wonder if the comment was intended to be mainly about the newer
| mobile OSes. I don't think I'd have too much trouble finding a
| way to run 10-year-old Windows or Linux desktop apps, and it
| would be easier than running Mac apps from the 1990s, but I
| didn't even get the opportunity to save copies of the iOS
| binaries I used 10 years ago. Even if I did, I doubt I'd be able
| to do anything with them.
| mylons wrote:
| they're talking about web apps and mostly javascript.
| emodendroket wrote:
| Doesn't make much sense then. Your browser will run those.
| at_a_remove wrote:
| I am reminded of the profession "programmer-archaeologist" in
| Vinge's _A Deepness in the Sky_. In roughly 2010 I reminded my
| grand-boss that a great deal of the important business process we
| had consisted of largely uncommented C and various mismashes of
| shell scripts.
|
| It's true, there's something about all of the frameworks and the
| fads and such which causes so many projects to need, well,
| continual attendance to the dependencies. One proposed platform
| at a previous job bothered me for reasons I could not explain, so
| I mapped out the major dependent technologies, pointed out that
| we had nobody who had even a passing familiar with with them, and
| also pointed out how quickly some of them were moving.
|
| There's something to be said for keeping your tower of
| dependencies short. It's a tradeoff, to be sure.
| contingencies wrote:
| _There 's something to be said for keeping your tower of
| dependencies short._
|
| Absolutely, but you still need to present an interface.
| Essentially, which interface you present (REST, command line,
| language-specific library, VM/container, etc.) has in most
| organizations become a political question, to which
| implementation details are largely held hostage.
| spamizbad wrote:
| People blame developers but it's all driven by a product
| mentality that favors rapid iterations and technical debt to run
| business experiments on customers. Slow-and-steady, carefully
| written software isn't tolerated within many product orgs these
| days.
| FridgeSeal wrote:
| I very much agree.
|
| I get that "done is better than perfect" but it feels like
| we've swung so hard in that direction that we seem to be
| largely neglecting stepping back and building the rough roll
| for the job in all but the largest places who have the luxury
| of having enough resources to assign a big enough team in the
| background to do it.
| enraged_camel wrote:
| >>Slow-and-steady, carefully written software isn't tolerated
| within many product orgs these days.
|
| The problem is that this works only for large clients and
| conservative problem domains (such as accounting) where things
| work at a glacial pace. Back in the day, only such clients
| could afford enterprise/custom software, so using a waterfall
| methodology to develop that software worked well enough.
|
| Things have changed. Software has gotten much cheaper to
| develop, which means it has become way more affordable, and the
| types of businesses who need that kind of software are in heavy
| competition with each other and their problems and needs change
| at breakneck speed. So your best best is to have your own
| software development practices to match that speed.
___________________________________________________________________
(page generated 2020-08-20 23:00 UTC)