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

Why does Debian change software?

blog.liw.fi

Post reply on HN
Print view View original

151–160 of 210 posts

Re: Why does Debian change software?

#151

Post by deng »

dsr_ wrote: post #126
RetroTechie wrote: post #84

Earlier quoted context omitted.

> Telemetry is perfectly acceptable as long as it is opt-in and does not contain personal data Telemetry contains personal data by definition . It just varies how sensitive & how it's used. Also it's been shown repeatedly that 'anonymized' is shaky ground. In that popcon example, I'd expect some Debian-run server to collect a minimum of data, aggregate, and Debian maintainers using it to decide where to focus effort…

The ongoing problem with popcon is that it's known not to be accurate, but since it's the data that's available, people make decisions based on it. popcon is least likely to be turned on by: - organizations with any kind of sensible privacy policy (which includes almost everyone running more than a handful of machines) - individuals concerned about privacy popcon is most likely to be turned on by Debian developers, a…

Yeah, isn't that a shame? Wouldn't it be nice if instead of catastrophizing that telemetry data is always only ever there to spy on us, that we might assume that there are actually trustworthy projects out there? Especially for FOSS projects, which can usually not afford extensive in-house user testing, telemetry provides extremely valuable data to see how their software is used and where it can be improved, especially in the UX department, where many FOSS is severely lacking. This thread here is a perfect example of this kind of black/white thinking that telemetry must be ripped out of software no matter what, usually based on some fundamental viewpoint that anonymity is impossible anyway, so why bother even trying. This is not helping. I usually turn on telemetry for FOSS that offers it, because I hope they will use this to actually improve it.

Re: Why does Debian change software?

#153

Post by bityard »

rmccue wrote: post #97
diggan wrote: post #93

Earlier quoted context omitted.

> it fucking sucked that they made source modifications As a maintainer, I can certainly understand how it feels like that, I'd probably wouldn't feel great about it either. As a user, I'm curious what kind of modifications they felt were needed, what exactly did they change in your library?

The library I was maintaining (SimplePie) was an RSS feed parser which supported every flavour of the RSS/Atom specs. Because of the history of those particular formats, there were a huge number of compatibility hacks necessary to parse real-world data, and cases where the "spec" (actually just a vague page on a website) was inaccurate compared to actual usage. This was a while ago (10+ years), but my recollection is…

First I want to say that I love Debian. They have a great distro that is simple and quite frankly a joy to use, and manage to keep it all going on basically nothing but volunteer effort.

However, I do believe that in certain areas, they give too much freedom to package maintainers. The bar for being a package maintainer in Debian is relatively low, but once a package _has_ a maintainer--and barring any actual Debian policy violations--that person seems to have the final say in all decisions related to the package. Sometimes those decisions end up being controversial.

Your case is one example. Package maintainers ideally _should_ work with upstream authors, but are not required to because a LOT of upstream authors either cannot be reached, or actively refuse to be bothered by any downstream user. (The source tarball is linked on their home page and that's where their support ends!) I don't know what the solution is here, but there are probably improvements that could and should be made that don't require all upstream authors to subscribe to Debian development mailing lists.

Re: Why does Debian change software?

#154

Post by deng »

Bender wrote: post #147
deng wrote: post #125

Earlier quoted context omitted.

By your definition, all data is PII.

Many corporate privacy policies per their customer contracts agree with this. Even a single packet regardless of contents is sending the IP address and that is considered by many companies to be PII. Not my opinion, it's in thousands of contracts. Many companies want to know every third party involved in tracking their employees. Deviating from this is a compliance violation and can lead to an audit failure and monet…

I can only repeat myself from above: it's about what data you store and analyze. By your definition, all internet traffic would fall under PII regulations because it contains IP addresses, which would be ludicrous, because at least in the EU, there are very strict regulations how this data must be handled.

If you have a nginx log and store IP addresses, then yes: that contains PII. So the solution is: don't store the IP addresses, and the problem is solved. Same goes for telemetry data: write a privacy policy saying you won't store any metadata regarding the transmission, and say what data you will transmit (even better: show exactly what you will transmit). Telemetry can be done in a secure, anonymous way. I wonder how people who dispute this even get any work done at all. By your definitions regarding PII, I don't see how you could transmit any data at all.

Re: Why does Debian change software?

#155

Post by Bender »

deng wrote: post #154
Bender wrote: post #147

Earlier quoted context omitted.

Many corporate privacy policies per their customer contracts agree with this. Even a single packet regardless of contents is sending the IP address and that is considered by many companies to be PII. Not my opinion, it's in thousands of contracts. Many companies want to know every third party involved in tracking their employees. Deviating from this is a compliance violation and can lead to an audit failure and monet…

I can only repeat myself from above: it's about what data you store and analyze . By your definition, all internet traffic would fall under PII regulations because it contains IP addresses, which would be ludicrous, because at least in the EU, there are very strict regulations how this data must be handled. If you have a nginx log and store IP addresses, then yes: that contains PII. So the solution is: don't store th…

By your definitions regarding PII, I don't see how you could transmit any data at all.

On the server side you would not. Your application would just do the work it was intended to do and would not dial out for anything. All resources would be hosted within the data-center.

On the workstation it is up to the corporate policy and if there is a known data-leak it would be blocked by the VPN/Firewalls and also on the corporate managed workstations by IT by setting application policies. Provided that telemetry is not coded in a way to be a blocking dependency this should not be a problem.

Oh and this is not my definition. This is the definition within literally thousands of B2B contracts in the financial sector. Things are still loosely enforced on workstations meaning that it is up to IT departments to lock things down. Some companies take this very seriously and some do not care.

Re: Why does Debian change software?

#156

Post by bityard »

yoyohello13 wrote: post #144

I respect the hell out of Debian and am grateful for everything they do for the larger ecosystem, but this is why I use Arch. It's so much easier just to refer to the official documentation for the software and know it will be correct. Also, I've never really encountered a situation where interop between software is broken by just sticking to vanilla upstream. Seems like modifying upstream is just a ton of work with…

You seem to be implying that Debian makes large significant changes to upstream software for the sake of integration with the rest of the OS and that Arch makes none at all. Neither of these is true.

Re: Why does Debian change software?

#157

Post by SAI_Peregrinus »

lmm wrote: post #128
SAI_Peregrinus wrote: post #100

Earlier quoted context omitted.

On the other hand it exposed that OpenSSL was depending on Undefined Behavior always working predictably. Something as simple as a GCC update could have had the same effect across far more systems than just Debian, with no patch to OpenSSL itself.

> On the other hand it exposed that OpenSSL was depending on Undefined Behavior always working predictably. Something as simple as a GCC update could have had the same effect across far more systems than just Debian, with no patch to OpenSSL itself. No it wasn't. It was reading (and xoring into the randomness that would become the key being generated) uninitialised char values from an array whose address was taken, t…

I see you're correct, I misremembered. That isn't really much better, since there's no requirement that unspecified values ever actually change. Compiler developers are free to always return `0x00` when reading any unspecified `char` value, which wouldn't provide any entropy. XORing it in guaranteed that it couldn't subtract entropy, but if there were no other entropy sources they failed to return an error. OpenSSL being able to generate 0 entropy and not return an error in its RNG was still an important bug to fix.

Re: Why does Debian change software?

#158

Post by yoyohello13 »

bityard wrote: post #156
yoyohello13 wrote: post #144

I respect the hell out of Debian and am grateful for everything they do for the larger ecosystem, but this is why I use Arch. It's so much easier just to refer to the official documentation for the software and know it will be correct. Also, I've never really encountered a situation where interop between software is broken by just sticking to vanilla upstream. Seems like modifying upstream is just a ton of work with…

You seem to be implying that Debian makes large significant changes to upstream software for the sake of integration with the rest of the OS and that Arch makes none at all. Neither of these is true.

I understand it's a spectrum, but I lean toward minimal possible changes to upstream.

Re: Why does Debian change software?

#159

Post by Barrin92 »

gspr wrote: post #64
Barrin92 wrote: post #52

Earlier quoted context omitted.

I second that. Not only are there not infrequent cases of package maintainers breaking software, it's effectively nothing but the "app store" model, having an activist distributor insert themselves between the user and software. It's why I'm really glad flatpaks/snaps/appimages and containerization are where they are at now, because it's greatly dis-intermediated software distribution.

Since this is the FOSS world, you are of course free to eschew distributions. But: > it's effectively nothing but the "app store" model, having an activist distributor insert themselves between the user and software. is just factually wrong. Distributions like Debian try to make a coherent operating system from tens of thousands of pieces of independently developed software. It's fine not to like that. It's fine to i…

>But a distribution is neither an "app store", nor does it "insert itself" between the user and the software.

Just scroll up to the second comment in the thread right now by the user rmccue. Given that Debian doesn't give the user any indication of the fact that it even has modified an upstream piece of software it's obviously perfectly possible for them to insert themselves without you even knowing it. And in that case, according to the developer, even introduced subtle bugs.

So you can run buggy software as a consequence of some maintainer thinking they know more than a developer, and not even know it because you have no practical info about that process. This is of course not a "choice" in any meaningful sense of the term.

Nobody ever actually wants to use a buggy php library maintained by debian over a functioning one maintained a by developer, they very likely just never even were aware that that is what they were served.

Re: Why does Debian change software?

#160

Post by ak217 »

bityard wrote: post #153
rmccue wrote: post #97

Earlier quoted context omitted.

The library I was maintaining (SimplePie) was an RSS feed parser which supported every flavour of the RSS/Atom specs. Because of the history of those particular formats, there were a huge number of compatibility hacks necessary to parse real-world data, and cases where the "spec" (actually just a vague page on a website) was inaccurate compared to actual usage. This was a while ago (10+ years), but my recollection is…

First I want to say that I love Debian. They have a great distro that is simple and quite frankly a joy to use, and manage to keep it all going on basically nothing but volunteer effort. However, I do believe that in certain areas, they give too much freedom to package maintainers. The bar for being a package maintainer in Debian is relatively low, but once a package _has_ a maintainer--and barring any actual Debian…

Agreed. The intent is good, but there are recurring problems that arise because of insufficient communication between the distro package maintainers and upstream, insufficient domain experience, or both. I think the solution is to set stronger expectations about what kinds of customizations maintainers should be making (in general, fewer than they make today), how to communicate with upstream, and more code review.
Post reply on HN