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

#81

Post by mjd » Sat, Jul 02, 2016, 12:59 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?

That is a good point. I still don't know the answer to that! I _think_ it's that the sysadmins added the new capability to Perl sometime in the last few weeks, and the the problem then didn't appear until after the next time I reloaded the system configuration.

I will confirm this with the sysadmins and add it to the article. Thanks!

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

#82

Post by GavinMcG » Sat, Jul 02, 2016, 1:38 PM UTC

CoconutPilot wrote: post #44

The problem with "newish" features like capabilities, file attributes, SElinux is they haven't been integrated into the traditional nix utilities and almost nobody knows what is going on with them. A few examples of the poor integration: File attributes override the nix permissions such that you can set the immutable flag on a file and even root can't modify it. `chattr +i FILENAME && rm FILENAME` On distros that use…

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.

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

#83

Post by bluejekyll » Sat, Jul 02, 2016, 2:08 PM UTC

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 posit that all software has bugs. If this is true, closed source vendor software allows you no insight into the inner workings of the code; you are always at the mercy of the vendor.

Open-Source software has bugs, but it gives you the ability to look into the issues directly; allowing you to figure it out if you want.

The cool thing in open-source is you can always absolve yourself of responsibility and hire a vendor or maintainer or others to help fix the problem if there is one. Which means you have N potential solutions to a problem, compared to just 1 with a closed source vendor.

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

#84

Post by btilly » Sat, Jul 02, 2016, 3:59 PM UTC

digi_owl wrote: post #76

cantrevealname wrote: post #16

Earlier quoted context omitted.

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

The problem with trying to separate them is that often a security fix is put into code that had feature changes, and so you can't get the security fix without the feature changes.

Going the other way requires developers to maintain a variety of old versions of their code so they can backport security changes. Which is a lot of work for them for very little extra value.

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

#85

Post by digi_owl » Sat, Jul 02, 2016, 4:44 PM UTC

btilly wrote: post #84

digi_owl wrote: post #76

Earlier quoted context omitted.

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.

The problem with trying to separate them is that often a security fix is put into code that had feature changes, and so you can't get the security fix without the feature changes. Going the other way requires developers to maintain a variety of old versions of their code so they can backport security changes. Which is a lot of work for them for very little extra value.

IOW you can't get a developer to do straight maintenance work...

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

#86

Post by 616c » Sat, Jul 02, 2016, 4:58 PM UTC

krylon wrote: post #67

616c wrote: post #24

Earlier quoted context omitted.

I am in a similar boat. With DSC, I am increasingly excited with the idea end user computers can also shift to immutable, or approaching what we call immutable, infrastructure that has logically valid weight in the communities represented here. The problem? Culture. So many people do not understand when I say the following things: - Do not install with the GUI, please use the deployment system to document unattended…

I read about DSC a while ago, and it sounds very appealing. So far, though, I have not managed to actually get to know it personally, so to speak. We have over the past two years tried to move as much of the configuration as possible to GPOs, although they bring their own share of problems. On Unix-like systems, one can use log files to track down problems most of the time, on Windows it seems like logging is kind of…

I have just read about it and the WMF (WMI Management Foundation) docs, whitepapers, and framework. I have not played much.

GPO, and GPP (the preferences), are a nightmare.

- The gpresult utility and rsop.msc tell you changes, but that does not mean much, because

- GPO is async and requires sometimes a shutdown, not just a reboot (fom 5+ years of experience), so good luck dropping this crap on a dime; God help you

- The Registry.pol files are not easily auditable or usable outside gpresult and rsop.msc

- If you hit slow links, processing will be disabled; this is not slow all the time, but when 2% of the computers booting at 6:54AM on Tuesday it does not get applied

- A whole bunch of other stuff I forget in this rant

But I totally agree with you, such a pain. I have not had a lot of time for Salt, Puppet, and Chef. Whether it is in parallel or thanks to DSC (I saw some Powershell in one repo ... Ansible?) those tools are also a reality.

I use an expensive SCCM alternative, but I am seriously considering proposing moving to one of the Chef/Puppet/Anisble/Salt stacks with SSH becoming a reality on Windows.

All I can say is thank God.

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

#87

Post by Natanael_L » Sat, Jul 02, 2016, 5:27 PM UTC

TeMPOraL wrote: post #72

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…

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.

Similar to composability problems in cryptography. Naively combining primitives that individually hold certain security guarantees will most certainly undo all of the security, instead of "stacking" these individual guarantees.

Usually you can trace the insecurity to mismatched assumptions, unhandled edge cases or a failure to consider global contexts (like where you accidentally turn one function into a decryption oracle for another).

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

#88

Post by dredmorbius » Sat, Jul 02, 2016, 5:35 PM UTC

btilly wrote: post #84

digi_owl wrote: post #76

Earlier quoted context omitted.

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.

The problem with trying to separate them is that often a security fix is put into code that had feature changes, and so you can't get the security fix without the feature changes. Going the other way requires developers to maintain a variety of old versions of their code so they can backport security changes. Which is a lot of work for them for very little extra value.

Hence Debian's practice of back-porting security fixes on stable distros.

Also applies to Ubuntu, probably Red Hat, though the latter's vastly smaller repos mean vastly greater reliance on third-party sources, and concommitant risks of introducing/changing features when security fixes are wanted, or riding bareback without security updates.

There's also the inherent conflict between running current code and fixed code. Debian's legendary conservatism reflects a bias toward the latter, at least on its stable branches. Of course, you're welcome to lead and bleed on testing, unstable, or experimental, if you so choose.

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

#89

Post by digi_owl » Sat, Jul 02, 2016, 5:35 PM UTC

GavinMcG wrote: post #82

CoconutPilot wrote: post #44

The problem with "newish" features like capabilities, file attributes, SElinux is they haven't been integrated into the traditional nix utilities and almost nobody knows what is going on with them. A few examples of the poor integration: File attributes override the nix permissions such that you can set the immutable flag on a file and even root can't modify it. `chattr +i FILENAME && rm FILENAME` On distros that use…

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

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

#90

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

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…

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.