Isomer · HackerTrans

il y a 2 ansdiscuss

I have allergies. I remember walking home from work one day thinking "Ah, my sinuses have cleared, the pollen must have finally gone." only to wake up the next morning all stuffed up again. Then it dawned upon me that work has HEPA filtered air, but my bedroom does not despite spending ~⅓ of my life there. Having an air purifier in my bedroom means I've avoided almost all symptoms of allergies for the last 5+ years without needing to resort to medication.

Isomer

il y a 3 ansdiscuss

> If you’re getting a new phone or are worried about losing your existing one, you can always choose to back up your data to the cloud so it doesn’t get lost. We’ll automatically encrypt your backed-up data so no one can read it, including Google.

https://blog.google/products/maps/updates-to-location-histor...

Isomer

il y a 6 ansdiscuss

Close. AIUI, Google was annoyed at people meddling with DNS results, and with ISPs providing terrible DNS performance for their customers.

Google wins when the Internet is fast. Google's goals here are that you can use Websearch quickly and without hotspots etc meddling with traffic. The story is simple: If companies meddle with DNS results, or provide poor performance, then users don't use the Internet as much, and Google doesn't get to sell ads. Google wants you to have the fastest, most reliable Internet it can, because that means you don't get frustrated and go do something else. Google doesn't need to scrape the logs for whatever people think google might be scraping the logs for.

Google _does_ log some data for dealing with abuse (as you can probably imagine 8.8.8.8 gets a _lot_ of intentional and unintentional abuse), but tries to be as clear as it can be about what gets logged, what it's used for, and how long it's kept. Google treats these logs very very carefully, carefully limiting who has access, and when you need to use the logs to debug something, it's very carefully audited.

Disclaimer: I used to be one of the SREs oncall for Google Public DNS (but not any more – I now work for a different SRE team at Google).

Isomer

il y a 6 ansdiscuss

The janitor is trying to help make packaging less toilsome:

- The janitor is trying to automatically migrate people to newer versions of debhelper, reducing the number of different build system variants.

- The janitor attempts to perform validation of all the long, complex, changing rules for you, so if you meet their requirements then it will propose an upgrade. If the janitor can automatically bring you into compliance with the rules, it will, otherwise it'll leave you upgraded to the step that requires a human to intervene. You can manually upgrade it one step, and then the janitor will loop back around and do the rest for you.

- The janitor will also fix suboptimal, or unnecessary packaging changes and improve them for you too, hopefully leaving you with a much smaller, simpler packaging system that's easier to reason about.

Isomer

il y a 6 ansdiscuss

This is an excellent point.

One change the Janitor can try to make automatically is upgrading debhelper version. Newer debhelper versions include support for compiling code with additional security measures. So we end up with more secure packages.

If ~everyone migrates off an older debhelper version, then the debhelper developers don't need to keep maintaining that code and can delete it, leading to a more maintainable code base, less complex documentation that says "X, unless you're on an older version, when it's Y" and so on.

The Janitor is pretty good at trying something like upgrading debhelper, then doing a build, and running the package tests, performing a package diff to make sure nothing unexpected happened then proposing a merge. Doing this by hand is slow and laborious. If debhelper always tried to autoupgrade to the newest version when it was run, it would be frustratingly slow.

And once the merge proposal is accepted, then it's clear which packages need human attention, and which were able to be cleanly migrated by automation. We use this a lot in the janitor. Run a fixer over all eligible packages, and see which ones succeed. Then investigate a handful of packages that failed, see if there is a common pattern that can be extracted and fixed. Then we reapply the fixer to all the remaining packages, see how many were fixed, and repeat the process until there are only a very few remaining.

Isomer

il y a 6 ansdiscuss

Hi, I've been working with Jelmer on the janitor and related infrastructure for over a year now and worked with him writing this blog post.

As others have pointed out, this is used for Debian metadata, so upstreaming doesn't really apply. While "priority extra" might seem trivial, there are other much more sophisticated examples of what the janitor can do. For example, applying multiarch fixes. These fixes are a lot more complicated, so we didn't want to show their code and have to explain everything that's going on during the blog post, as the blog post was already long enough. This was just to give people an idea that it's possible to make large scale, high quality fixes relatively easily and how they might go about it if they also have a fix they want to propose.

We've been using the lintian metadata fixes as a proving ground to learn how to make safe, high quality changes at scale. Fixing one package is trivial, doing even a mediocre job of fixing 60,000 packages is much much harder. Nobody wants crappy automated junk in the repository.

There are also other easy to overlook, massive non-technical problems in this space, like trying to convince people that the Janitor is doing worthwhile work and people should embrace it. Significantly more thought and effort has gone into making sure people are delighted (or at least not too annoyed) by the janitor than the actual changes themselves. There's things like making sure you can correctly identify and preserve a large number of idiosyncratic formatting styles. This is open source software, and everyone has their own distinct opinions as to what is "best". You also don't want to overwhelm people with fixes they're not interested in. We've already got sketches of blog posts coming up that discuss some of these issues and how the janitor handles them.

The janitor can do things other than just lintian fixes, such as multiarch improvements and merge in new upstream releases and even upstream snapshots. These aren't enabled yet, as there are still being polished up to the standards Debian demands. For some of them (like merging new upstreams) there a lot of very difficult non-technical questions that still need answering. (How do you make sure that a compromised upstream developer submitting a backdoor into a common library doesn't have that code automatically pushed out to everyone?)

The goal of the janitor is to help Debian move forward (more) rapidly, to increase the overall quality of packages in the archive, and free up the humans so they can concentrate on things that require human judgement (eg writing high quality descriptions).

If the janitor is successful, then you shouldn't have to spend much time working on packages. All of the drudge work that takes human time should be automated, leaving only the things that require actual human discretion. This helps alleviate your "I ain't got no time for that". We're not there yet, but we're working towards it.

We have discussed being able to apply fixes further upstream. It's an even harder problem to get right, and again, most of the complexity is in the non-technical side. So far, we've not tackled this, but we have deeply considered it. For the technical sided problems, before we can do any upstream fixes, we need a reliable way of being able to find the upstream repositories, we need to be working on the latest upstream snapshot, we need to know how to build the package, etc. These are all problems the Janitor is already working on solving cleanly and elegantly first.

Don't worry, we've got some awesome plans for the Janitor. Lintian fixes are just the very first step.

comments