Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.plover.com

Post reply on HN
Print view View original

71–80 of 98 posts

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

#71

Post by mynewtb »

stephengillie wrote: post #33
AznHisoka wrote: post #25

Earlier quoted context omitted.

I hate apps that do 1 job and do it extremely well and it insists I update just so I am on the latest version. It works now stop bugging me. I don't care if you changed the color scheme!

A benefit to web apps is seamless updating to users. One click loads the updated webpage. They might not even notice their profile pic has changed from square to round!

That often is not a benefit for the users though and one of the reasons why I only use 'web apps' for throwaway work.

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

#72

Post by TeMPOraL »

MertsA wrote: post #57
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…

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…

Issues like the one in the article are orthogonal to the openness of software. Quite often, the problem lies in a set of settings that each have perfectly legitimate reason to be what they are that together interact in a bad way, even though every component is working as it should.

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

#73

Post by TeMPOraL »

stephengillie wrote: post #33
AznHisoka wrote: post #25

Earlier quoted context omitted.

I hate apps that do 1 job and do it extremely well and it insists I update just so I am on the latest version. It works now stop bugging me. I don't care if you changed the color scheme!

A benefit to web apps is seamless updating to users. One click loads the updated webpage. They might not even notice their profile pic has changed from square to round!

Today you reload and see nicer buttons; tomorrow you reload and see them thanking you for the incredible journey you went on together that leaves them with new jobs and $hittons of cash, and you with a search for a new tool.

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

#74

Post by TeMPOraL »

tamana wrote: post #31
xyience wrote: post #7

Earlier quoted context omitted.

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

No, they scientifically make changes safe and give confidence to make changes.

Do you think that, in case of the problem from this article, Perl devs should have had a test checking if their update doesn't break someone's Emacs when they try to use it in client-server mode, launching one via a Perl script and other via some other means, on a Linux with "capabilities" feature?

This story wasn't about trivial day-to-day developer bugs, but what kind of problems happen in really complex systems.

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

#75

Post by digi_owl »

In the end it seems that all complexity stems from trying to enforce access privileges on a system that do not gives a rats ass about anything beyond 0s and 1s.

IF we want to avoid said complexity we basically have to go back to running only one process at a time, loaded directly from dedicated, removable, storage when needed.

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

#76

Post by digi_owl »

cantrevealname wrote: post #16
userbinator wrote: post #2

Great debugging, and an example of the sort of behaviour that long dependency chains can expose. Or rather, I did until this week, when it suddenly stopped working. When this happens to me, the first thing that I ask myself is "what changed?", and I'm usually able to track down the cause to some configuration change. Incidentally, this is also why I never like modifying a working system unless it's absolutely necessa…

> Incidentally, this is also why I never like modifying a working system unless it's absolutely necessary. It's why I find auto-updating apps so infuriating. The trend is that every app, OS, and driver insists on being self-updating. It's going to be very difficult to maintain a reliable system if you're doing anything complex. Privacy issues aside, that's another reason I never plan to use the continuously self-upda…

The basic problem there is the mixing of feature changes and security changes in a single stream.

So you can't just say you want security fixes only, no new or changed features.

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

#77

Post by wpietri »

tonyedgecombe wrote: post #69
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…

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".

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

#79

Post by digi_owl »

paulddraper wrote: post #39
vacri wrote: post #30

Earlier quoted context omitted.

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…

Well, the other difference is that reboot isn't often needed to solve the issue, unless you're messing around with kernel modules.

This may well be changing though, as more and more "desktop-isms" claw their way deeper into the stack.

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

#80

Post by wpietri »

XorNot wrote: post #56
vacri wrote: post #30

Earlier quoted context omitted.

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…

Except you have to triage. I'll happily reboot any box which fails unusually because my overall system should be HA enough to survive that. It's only interesting if the failure count is high, and I'm running reasonably up to date code. Otherwise there's too many things in a day to get through.

I'm with Vacri; I'm very reluctant to do that. Small problems can be harbingers of big ones. Even when they aren't, small problems often confound the ability to solve big ones.

Most concerning for me, though, is what safety experts call "normalization of deviance". It's the process by which people become accustomed to small failures, which creates opportunities for big failures to happen. A big example is the Challenger disaster. [1]

I see shops with low bug rates, where people think a lot about quality. And I see shops that, thanks to high bug rates, are too busy fighting fires to ever spend much time on quality. I never see any place in between. And I think normalization of deviance is why.

[1] http://mikemullane.com/stopping-normalization-of-deviance/

Post reply on HN