debiandev

9 ms·

31.
by debiandev 7y ago
If only it was not so painful to package. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839786
32.
by debiandev 7y ago
> In order to ensure the quality for all packages, now you have to keep all versions anything depends on in check Spot on. This creates a burden of work impossible to handle for any distribution. What really happens with the "everyt
33.
by debiandev 7y ago
Having worked a lot with RPM, other package managers, containers and proprietary build systems... I would choose debs every time.
34.
by debiandev 7y ago
> a random docker is almost as bad as a random executable You can sandbox a random executable with seccomp, you cannot effectively sandbox a whole container without breaking many things.
35.
by debiandev 7y ago
> installed pre-configured Docker ARM images for 8-9 different media applications ... It just worked. Often the applications are packaged by random people on the Internet and do not receive security updates. There's plenty of eviden
36.
by debiandev 7y ago
I've been packaging for Debian for a decade and I ran into a lot of unfriendly upstreams that would refuse to make any change to allow packaging and I've never seen other Debian Developers treating upstream developers poorly.
37.
by debiandev 7y ago
> Nobody read the source code In Debian we review and vet packages.
38.
by debiandev 7y ago
Debian is already using reproducible builds.
39.
by debiandev 8y ago
Security and stability, independence from financial interests of an owner.
40.
by debiandev 8y ago
> Is the interest on Debian dwindling? On the contrary, the project is growing in terms of contributors, packages and internal projects. https://reproducible-builds.org/ mostly came out from Debian (see https:/&#x2
41.
by debiandev 8y ago
This is a misunderstanding of how Debian works.
42.
by debiandev 8y ago
Loud minorities and trolls on public mailing lists are not representative of the community of DDs and DMs.
43.
by debiandev 8y ago
DD here. "modern" dev culture feels more like a Silicon Valley / HN bubble, where people believe that all companies "move fast and break things". Thankfully, most companies (including FAANGs where I worked) are way
44.
by debiandev 8y ago
On PPA you need to trust a random individual instead of trusting an official distribution. Some distribution requires multiple pair of (skilled) eyes to vet a package.
45.
by debiandev 8y ago
The opposite is true: new vulnerabilities can be introduced in new feature releases, while older releases can receive backported security fixes. That means that the level of security of a well maintained stable release train can only increa
46.
by debiandev 8y ago
> Becoming a Debian Developer involves a lengthy process of showing commitment to their values and requires meeting another member in person to show identification to be added to their cryptographic web of trust At the very least. More o
47.
by debiandev 8y ago
True. But also new vulnerabilities land into unstable when upstream software releases are made. :) That's why the distribution is baked for months before being called stable.
48.
by debiandev 8y ago
HTTPS adds very little privacy in this context. The mirror IP address is in cleartext. Also, a smart observer might be able to detect APT traffic by analyzing the timing. If you want privacy, APT supports Tor and there are mirrors providing
49.
by debiandev 8y ago
Also the number well maintained packages is much higher.
50.
by debiandev 8y ago
Correct. Plenty of Debian Developers work full time on other software projects. Very often with synergies with Debian. Yet there's no obvious way for people to realize to what extent Debian influences other projects and companies.
51.
by debiandev 8y ago
> And yet they take in many of RedHat solutions and decisions Citation needed - that's simply not true.
52.
by debiandev 8y ago
> I think the fix is fairly trivial Not at all. Package maintainers and the Security Team in Debian do plenty of manual work to backport and test security fixes. > As soon as a security issue pops up for one of their dependencies, the
53.
by debiandev 8y ago
https://wiki.debian.org/Packaging is a good source and you can easily generate packages from other distributions from a .deb
54.
by debiandev 8y ago
> as someone doing precisely this kind of engineering for almost three decades, I can assure you that this is not the case Same here. > Unless one is an operating system vendor (like Joyent, redhat, SuSE, Debian, Canonical, CentOS, ..
55.
by debiandev 8y ago
I fully agree. I worked on systems that are not connected to the Internet for security reasons and receive "offline" security updates using distribution packages. It's also very common in security-sensitive environments to gi
56.
by debiandev 8y ago
Nimble is used only at build time for libraries and few tools. Packaging binaries for production is not its use-case.
57.
by debiandev 8y ago
You seem to be confusing /opt and /usr. > native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided No, native package managers sh
58.
by debiandev 8y ago
Bare with me before downvoting (or at least write why). At the beginning, patents were very similar to FLOSS. Before patents, blueprints were kept secret, mechanical design was sometimes unnecessarily complex as a form of obfuscation and if
59.
by debiandev 8y ago
Debian has a dedicated archive, named "non-free", for everything that does not comply with the DFSG. The DFSG is a set of guidelines that define what can be considered true FLOSS. The reason is to protect users from legal risks.
60.
by debiandev 8y ago
Quite the opposite. If you give a product for free you cannot be fined for it, obviously. Yet, open source can be vetted, and people can be paid to review and vet software. Debian developers review software before uploading it end often do

More ›