Don't tug on that, you never know what it might be attached to • Hacker News Board

Re: Don't tug on that, you never know what it might be attached to

#91

Post by Joeri » Sat, Jul 02, 2016, 7:45 PM UTC

wpietri wrote: post #77

tonyedgecombe wrote: post #69

Earlier quoted context omitted.

A good vendor will work with you to resolve the problem, not all closed source software is bad.

I'm familiar with that theory, but from my personal experience I'd put the number of good-vendor software packages around 1%. And in retrospect, I'm not sure those cases were so much "good vendor" as "vendor over whom we had significant financial leverage".

From my personal experience I've only gotten consistently good support from Cloudera and Jetbrains, out of some 20-odd companies that I've contacted for paid support. So, for me the figure is more like 10% instead of 1%.

Re: Don't tug on that, you never know what it might be attached to

#92

Post by jahnu » Sat, Jul 02, 2016, 7:50 PM UTC

Joeri wrote: post #90

MertsA wrote: post #57

Earlier quoted context omitted.

This is what I hate about closed source software in general. Every sysadmin out there has complaints about how terrible support is from XYZ vendor, but it's not just that the vendor can't provide support, it's that by going closed source, the vendor is the only one who can really track down these sort of bugs. With an open source stack, no matter what breaks in any software component, I'm not left high and dry hoping…

This is why every web developer needs to learn to read C and C++, and how to navigate a codebase written in either of those, even if they never write any programs in them. Most of the software we use is built with those two languages. If you can't read them, you can't track down what's happening behind the curtain.

I think that's a little optimistic and to be honest, unrealistic.

A problem shared is a problem halved. In this case every web developer needs to have a network of people to collaborate with in order to diagnose the problem.

Re: Don't tug on that, you never know what it might be attached to

#93

Post by Joeri » Sat, Jul 02, 2016, 7:50 PM UTC

vacri wrote: post #30

krylon wrote: post #8

As a sysadmin on a Windows network of ~100 computers, this story makes me want to cry, although maybe for the wrong reason: I see weird problems of the sort "It did work before I went on my lunch break" on a fairly regular basis. How often would I like to go down the rabbit hole and explore these problems in such depth, but if I did that, I would hardly get any work done. The frequency at which our users run into the…

One of the biggest cultural changes I had when I jumped the fence from Windows to Linux was the reboot. On Windows, the culture was strongly "reboot first, if it still happens, then it's a problem". On linux, it was a measure of last resort, because then you can't fix the problem (as you say). Obviously the latter is the best way, but it's interesting that the culture of the two systems is so different, no doubt born…

There are windows sysadmins who schedule nightly server reboots "to keep the machines healthy". I've seen them in action. It is scary. The scariest part? It helps.

Re: Don't tug on that, you never know what it might be attached to

#94

Post by SystemOut » Sat, Jul 02, 2016, 8:18 PM UTC

loteck wrote: post #64

MertsA wrote: post #57

Earlier quoted context omitted.

This is what I hate about closed source software in general. Every sysadmin out there has complaints about how terrible support is from XYZ vendor, but it's not just that the vendor can't provide support, it's that by going closed source, the vendor is the only one who can really track down these sort of bugs. With an open source stack, no matter what breaks in any software component, I'm not left high and dry hoping…

As a sysadmin, I'm putting my neck on the line anytime something breaks. In many years of doing this type of work, I've noticed this fear of your neck being on the line is a myth. Heads rarely roll merely because something goes wrong. I've also noticed almost every sysadmin believes that myth, and it can make us very difficult to relate to or even work with. Ironically, that's a problem that may actually cause you to…

Back when I used to lead the engineering group for a company I was asked to also lead the IT and Ops teams. I was amazed at how many of the sys admins lived in fear that anything going wrong or taking a risk on something new and it not working as expected would get them fired. Virtually no one wanted to take any risks because of this fear. It took a long time of working with the team and demonstrating that people did not get fired when things went wrong. It was a real eye opener for me.

Re: Don't tug on that, you never know what it might be attached to

#95

Post by mjd » Sat, Jul 02, 2016, 10:25 PM UTC

davidu wrote: post #15

I read this, but seemed to skip over the part where he explains why this changed suddenly, when the behavior was documented? What changed to make the perl become capable whereas previously it lacked the low port capability?

I checked with Frew on this, and we still don't know the answer.

Re: Don't tug on that, you never know what it might be attached to

#96

Post by Osiris » Sun, Jul 03, 2016, 6:01 AM UTC

vacri wrote: post #32

xyience wrote: post #7

Earlier quoted context omitted.

Tests don't magically make changes safe or give the confidence to make changes.

A culture of many small changes means that you deal with smaller problems relatively quickly. The more you fall behind, the bigger the jump to where you should be, and it's not a linear relationship. At one place where I work, we're on nodejs 0.10, which is several release versions behind. It's causing us a bunch of problems, because while 0.10 is still technically not EOL'd yet, npm modules behave like it is... howe…

This is my experience as well with node and shrinkwrap. I see people using shrinkwrap to avoid potential issues, but what ends up happening is they get stuck on old versions of dependencies and when there's a bug fix or new feature that's needed it can be very difficult to upgrade. Instead, I prefer to try to always keep my dependencies up to date, especially with new major versions to avoid exactly this problem.

Re: Don't tug on that, you never know what it might be attached to

#97

Post by Bartweiss » Sun, Jul 03, 2016, 10:10 PM UTC

greenyoda wrote: post #53

Bartweiss wrote: post #50

Earlier quoted context omitted.

I think this is a serious issue, at least for developers. I've never been burned by a self-updating browser, but anything beyond that seems downright unacceptable. There are just too many fragile, hand-managed dependency chains at work even in good setups.

"I've never been burned by a self-updating browser..." I develop browser-based software which, after one Chrome update, was rendered unusable by a bug in Chrome. Fortunately, Google pushed out a new version with a fix the next day.

I did suspect that "I've never been burned" just meant I hadn't developed enough for browsers...

This also seems like a good reminder that transparent updating only works if your team is good and responsive enough to fix mistakes on the fly. If you're rolling out one update a month, you'd better give people a choice so they can decline when you hand them faulty upgrades.

Re: Don't tug on that, you never know what it might be attached to

#98

Post by dozzie » Mon, Jul 04, 2016, 12:57 PM UTC

digi_owl wrote: post #89

GavinMcG wrote: post #82

Earlier quoted context omitted.

nix formatting suggests that the asterisk in nix needs to be escaped. Apparently on HN that requires putting a space after the * though, so you end up with * nix.

Apparently HN's markdown implementation is supposed to leave the * alone as long as here is not another the other end. But there seems to be no upper limit to where that end may be. Also, it seems to only check if the * is near something else, not if it is before or after. Nor if the after is after a before (if that made any sense at all).

> Apparently HN's markdown implementation is supposed to

What made you think it's Markdown implementation? It's pure text, with paragraphs delimited with empty lines, code blocks being prefixed by space (or two, I never remember) and emphasis being marked by asterisks. There's nothing more.