debiandev
Debian Developer here. Part of packaging work, for Python libraries or anything else, is to verify the reliability of the upstream developers, audit the code, set hardening flags, add sandboxing and so on.
I spotted and reported vulnerability myself and it's not uncommon.
And the syntax is very friendly and intuitive.
Reminder: the Debian Packaging Guidelines are meant for official Debian packages.
Making a package with dpkg-deb -b <dir> <packagename> is very easy and gives all the features of APT (dependency tracking, config management, atomic deployment).
But it's still done - as long as there's usually one version of a given library in the whole archive.
Imagine doing that for e.g. 5 versions of a given library, embedded in the sources of 30 different packages.
Especially the word "avoid", knowing that the article is already written.
> In the meantime, I'd recommend reading the blog: in it a Debian developer mentions having very friendly interactions
And still, you keep assuming that I'm not talking in good faith and that I'm trying to subtly attack he article.
Every time similar content is shared here there's a number of people making exaggerated claims around Debian being dead or in deep trouble.
The other comments accusing me of doing damage control are a good example.
I recommend attending Debian events in person (once COVID is gone) to see that 99% of interactions between people are very friendly.
1) People announce leaving publicly and the FLOSS community takes notice of it. This is a sign of health of Debian. In many other projects few people notices.
2) The number of Debian developers, projects, and packages has been increasing for decades.
3) For each person writing on mailing lists and blogs there are 10 people quietly contributing.
4) The same applies to the occasional flamewars. Vocal minorities are not representative of the thousands of DDs and contributors.
This is a false dichotomy.
> By not having that escape valve
Please do your research before posting. Building packages with bundled dependencies is allowed, actually.
Having a handful of small files from 3rd parties bundled in few packages is relatively harmless (if they are not security critical) and allowed.
Having 200 dependencies with hundreds of thousand SLOC creates a significant burden for security updates.
Put security-critical code in some of dependency and the burden become big. Make the dependencies unstable and it gets worse.
Now create a similar issue for many other packages doing the same and the burden becomes huge, for the whole community.
> This also encourages passive aggressive software design criticisms.
I would call it outspoken criticism of bad software design.
And yet the number of DDs keeps increasing (and Debian is one of most successful projects).
Indeed it takes time to do packaging, and this is by design. Packagers are expected to thoroughly review the code they are packaging and smooth out various sharp corners.
Many times I've found bugs in the upstream code while packaging. Sometimes around security and privacy, often around documentation, usability or non-x86 architectures.
Every time I check if other distributions opened bugs or applied patches for the same issues. It almost never happens.
This is why I might spend 2 hours on a package instead of 10 minutes.
Furthermore, rebuilding and distributing a large number of large binaries every time a vulnerability is fixed is harmful!
- It encourage users to delay security updates. Hundreds of millions in the world have slow or expensive or capped Internet connectivity.
- Makes the distribution unsuitable for many embedded/IoT/industrial/old devices with very limited storage
- It gives the impression that the distribution is bloated.
I've never found a packaging tool without an extensive and clear manpage with examples.
> I think the biggest issue is the social problem of the long and arduous process to become a trusted Debian Developer. Although there's now an easier Debian Maintainer option for restricted access, it's still not easy to become one. Other people have to go through a developer to update or add packages.
There is an arduous process to become a senior engineer in a FAANG, or a tenured professor, or an airline pilot.
That's why a lot of people trust Debian.
[citation needed]
> And, what's more, the contracts we're talking about are all basically pro-forma.
I had very custom employment contracts with 2 well-known large tech companies. When asking to remove some clauses and add new ones they did not flinch at the ask and let me have meetings with their lawyers.
I have many other examples but a quick search on the internet can show how many contract-related discussions happen between large companies, suppliers, local governments & so on
Matasano is not the size of a FAANG and similar or maybe it has a small legal team by choice.
Having worked with lawyers, this largely overstates the risk. Companies are happy to discuss, modify and sign new contracts every day.
All these contracts are "unchallenged in court", by definition, because they are entirely custom.
A lot of software licensing contracts for closed source have complex and restrictive clauses to prevent "renting" such software through SaaS or weakening limitations using legal loopholes.
Yet companies still sign such contracts.
Another type of custom and complex contract is employment.
Furthermore, companies sue each other every other day over contract violation around IP, copyright, trademarks, patents but also employment contracts, rent, building regulations, shipment delays, all of that.
The idea that a FLOSS license is some scary monster is propaganda.
The goal of such propaganda is to drive the FLOSS community to provide valuable software for free and with zero strings attached - aka free labor.
I had a similar experience. I took exams on patent and copyright law with IP lawyers as teachers during my degree.
Then I worked in well known tech companies and had the opportunity to attend meetings with lawyers, business people, read contracts, etc. and oh boy!
Misconceptions abound terribly. The average techie overestimates his/her understanding of law and business.
"permissive" licenses are stupidly lenient. Companies never sign similar contracts between each other when exchanging goods or services. Contracts have hundreds of defensive clauses to mitigate risks or ensure fairness.
And yet people praise Android for "inventing" the app store and preventing people from [inadvertently] installing stuff from random website.
[1] https://web.archive.org/web/20160523181321/http://goodbye-mi...
Simply throwing a bunch of files into a package or a container is very quick.
Making an official Debian package is not supposed to be quick. DDs thoroughly review and test the software they are packaging. While packaging I often chase missing licensing information, find plenty of bugs, write systemd unit/init files and sandboxing, write manpages, functional tests, and sometimes find serious vulnerabilities.
I worked on various packaging and deploying systems, and most other distributions don't come anywhere close to this level of scrutiny.
I should also add that becoming a DD requires years of commitment and proven track record of work.
The next time someone complains that making a container is very easy in comparison they should ask themselves: how much can I trust a software source with a very low entry bar?
apt-get install maint-guide ...and then read:
file:///usr/share/developers-reference/index.html file:///usr/share/doc/maint-guide/html/index.en.html
Also look at existing packages and talk to DDs. Avoid random wikis.
I worked on many deployment systems and reading these guides made me a better engineer overall.
Please provide a source to back that claim.
Just write software that is not unnecessarily difficult to package.
Licenses cannot be reviewed automatically in a reliable way. Debian developers review the licenses and store them in a machine-parsable file.
When packaging we are required to disable privacy harming "features".