Hacker News new | comments | ask | show | jobs | submit login

The blame with npm, DockerHub, etc. basically boils down to "it makes it too easy to share and run software".

There used to be this thing called software engineering. You are presented a problem and you or a team come up with possible solutions choosing carefully the right tools and components for the job.

Now we are entering the everything as a service era which includes software engineering. Instead of designing a solution you download someone else's, duct tape on a few packages, tweak variables and publish it.

You can also blame the breakneck pace demanded by today's tech sector where everything needed to be deployed yesterday in order to beat the other guy to the silicon valley millionaire finish line.

You can say it's a mix of impatience and laziness.

This effect isn't new, even in ye olde days of waterfall. Back then it was called rapid prototyping and first system syndrome.

The rapid just got rapider today with easy packages, frameworks and containers. The prototypes just became "web scale" and are run way beyond their intended lifespan, just like any first system is.

> There used to be this thing called software engineering.

And computers were once accommodated with the same with the space they deserved in large rooms.

Now we are entering the everything as miniature. Want more RAM? Throw out the whole thing, because it can't be fiddled.

You could say it's a mixture of impatience and abject cheapness.

> Now we are entering the everything as miniature. Want more RAM? Throw out the whole thing, because it can't be fiddled.

Development of some technologies seems to happen on some weird curve like this:

  end-user control / flexibility / repairability
  |                 ........
  |               ..        ..
  |             ..            ..
  |          ...                ...
  |      ....                      .......
  | .....                                 ....
                 power / money-making capability
(Not really sure about the Y axis label; I'm having trouble expressing the quality I'm thinking of.)

Things start as prototypes - hard to sell, hard to use, hard to tweak on user end. Over time, they become more flexible - think of e.g. PCs with interchangeable components. This is the golden era for end-users. They can fix stuff themselves, they can replace or upgrade components. The technology reaches maturity, and the only way from there is downhill - as businesses find new ways to fuck users over, both purposefully and incidentally. Make things smaller. More integrated. Sealed. Protected. The end result is the ultimate money-maker - a black box you lease and can only use as long as you're paying for the subscription.

Hardware may be cheap or expensive, it does not make a lot of difference.

The key is whether you see your data, or your customers' data, as a precious thing that needs care and protection.

If you do, you make the best effort to select the right software, understand how it works, deploy it correctly and securely, etc. If you don't, you just slap together something that sort of works from the easiest-to-obtain parts, and concentrate on other things.

A lot of people don't care too much about their own personal data; some of them are developers, product managers, even CEOs.

I'm not sure what distinction you're trying to make? Build it yourself vs reuse? Old-fashioned file-sharing reuse vs modern network-based package management? Sounds like you're mocking anything that isn't homegrown or acquired via floppy disk, but I want to give you the benefit of the doubt...

I would suggest that depends on how they present the community artifacts. If they provide a good deal of obvious disclaimers that the artifacts are built by Joe Random and "Use at your own peril", etc, then they are probably covered. If not, then they are guilty of conditioning people with bad behavior.

For an example of how this existed long before Linux containers:

There are third party RPM and APT package repositories that have existed for a very long time. The packages are not vetted by a company and there is no legal culpability for anything nefarious being contained within. People use these packages at their own peril and it is assumed they have mitigating controls to reduce risk.

Github is community contributed code and there is no enforceable legal contract between the developer and the consumer. The same thing applies. Use at your own peril and have mitigating controls (code diff reviews, static analysis, legal review, etc) This is especially true for all those projects under the MIT license.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact