Why is Debian the way it is?
blog.liw.fi
blog.liw.fi
Meanwhile Debian doesn't suffer from any of this because it's been doing things so as to avoid these issues all along.
If your goal is to distribute software across multiple distros and operating systems, bundling dependencies makes sense.
If your goal is to maintain a distro, shared libraries that you can apply a security patch to exactly once is obviously better.
But these are two different people with either goal.
If your goal is to consume software for which you need long term reliability, accepting software that bundles an unmaintainable (to you) set of dependencies does not make sense. Unless you have no better option [edit: or if you're paying to delegate your problems to someone else I suppose].
As a user, using software sources that make the same choices Debian makes is always preferable for you if that alternative is available.
Mandating shared dependencies means that Debian is often running software against a dependency version that the original author did not develop against or test against. Sometimes the Debian package is effectively a fork. This results in Debian-specific bugs which get reported upstream. Distribution-specific bugs are a crappy experience for upstream developers because it wastes their time, and it's a crappy experience for users to be told that their software cannot be supported upstream because it's a fork.
Maintaining a huge repository of forked software is also an enormous undertaking. It's common for Debian users to be running fairly old versions of software. This is also not ideal, particularly for desktop users who read upstream documentation and require support when entire features are missing from their antique Debian version.
If you're an upstream who gets frustrated by Debian users, then it's worth considering why they're using Debian the first place.
There are some users who don't want this, and they tend to be the vocal minority. Debian is not the right distribution for them!
This situation resulted in Debian distributing a broken version of our software for several years. I did not come away with positive impressions of their packaging processes.
I won't link to it, as he blocks links coming from here...
> ...
> I did not come away with positive impressions of their packaging processes
I am not coming away with positive impressions of your upstream versioning or release processes :)
Of course, an important "exception to the exception" is when you're making software that can easily be distributed by distributions, e.g. because it's end user software and open source.
I think the optimal cases for bundled dependencies are (a) large closed source binaries that never change, like games, and (b) self-deployed software, e.g. something like a server written in Go that is compiled and maintained in its running environment by a single developer or company.
I have trouble understanding why this is desirable for either authors or end users. Even for open source end user applications, I want the software that I'm running to be reflective of the software that was authored and not the software that some distro maintainers think it should be.
I don't. As an end-user, I couldn't care less about what the author wanted, I want to run the best possible version of the software. Often that's the version maintained by my distro, as they've put in the effort to make sure all the different software on my system works well together.
You gave up one package system too early. I managed to get the Python 2 plugins working with AppImage bundle someone linked to on some forum.
Except that it's clear that Debian is suffering from a manpower problem and has run into fundamental scaling limits with its current architecture.
Thus, we're seeing things like Nix and Silverblue at the OS level with Snaps and Flatpak at the application level.
I don't know what the solution is, but it seems to me like Debian is going to need to do something shortly.
Distribution releases have the advantage that they have a large number of followers who share the same set of versions, and so can shake out the issues and fix the bugs together. In practice I think this beats what most upstreams that each pick their own sets of versions can achieve on their own.
It only takes one skilled engineer to fix any given issue in a given distribution release, even at today's scale. That's not a big burden, and is even available to those not skilled with a relatively inexpensive support contract.
Corporate upstreams additionally tend to focus on what matters to paying customers; other use cases can often receive a "not supported" answer. A community of followers operating on the same set of versions can address these use cases more easily, too.
I have been aware of the IETF for quite a while. What is most amazing is that the internet today was built (more-or-less) by the IETF. See The Tao of IETF (https://www.ietf.org/about/participate/tao/). This is an organization with no members. It just works. Hardly anyone really knows about it.
Just as interesting is what happened when the corporate world decided to compete with the IETF for control of how the internet worked. Some people call this the protocol wars. (https://en.wikipedia.org/wiki/Protocol_Wars). For a while it seemed like each month the OSI would announce a project to replace parts of the internet, like TCP, with an X.protocol. Of these efforts very few survived and thrived - like X.509.
The question that comes to my mind is whether these kind of democratic type collaborative organizations are in fact superior (far superior?) to the traditional corporate model. I personally have watched many corporations act with obvious stupidity. Doing things that can only be described as severely fight-their-way-out-of-a-paper-bag challenged. To put it kindly.
Certainly these other-style organizations do not really stack up on an economic basis. The income of most corporations dwarfs that of both the IETF and Debian. And yet as a contributor and creator, I can ask Cuo Bono? Certainly not the contributors, they subsist.
And perhaps most interesting to me, and perhaps worth an experiment, is whether it is possible to use an IETF or Debian style model that competes with the corporate model. It did work once with the Protocol Wars, so maybe.
(edit to remove markdown syntax, sigh)
I would not describe it as 'corporate world decided to compete with IETF', than 'governments tried to enforce its power'. IETF working groups are often full of engineers from corporate vendors trying to collaborate to ensure interoperability, while ISO is traditional top-down governments-led organization.
So perhaps that part of my argument is completely wrong. And distracts from the main question: could other fundamental models of collaboration be significantly more productive (efficient) than corporate models?
during that time, alot more money was being dumped into this internet thing, and companies realized that if they could get their widget written into internet standards, it would be really good for business.
partially due to that, and partially due to a largely ineffective focus on multicast protocols (PIM, RSVP, etc.), these people became less central over time, and alot of the formative protocol design activity stopped.
just my perspective, but it seems odd that we're still largely stuck in the early 90s protocol-wise. clearly there have been some changes (http3, bar), but not really much considering the relative timespans.
in any case, the point being that corporate involvement in the IETF wasn't a given in the early days, and it hasn't been an unqualified win.
the stupid dance tls1.3 has to do is best case in point.
It grew on me after a long time. I always thought it was not the most "technically sound" way of doing things
i.e. I don't really like the packaging model of global updates where you don't know what's going on, and sometimes there are version conflicts
But I have come to appreciate the stability and good intentions of the Debian project
Sometimes it's not technical excellence that matters the most, but the purpose and goals of the project
There are some specific complaints I have about technical choices for Debian, like the way daemons autostart post install. But these complaints are outweighed by the benefits of using a distro with coherence across packages and upgrades.
Apt is also just such a phenomenal package manager. It is fast out of the box, and supports some relatively tricky scenarios—like using stable for your system, but a newer Nginx from backports. Feels like I can get the newer features for the one or two packages that I really care about, and then use something stable and boring for everything else.
> Apt is also just such a phenomenal package manager. It is fast out of the box,
This wasn't always the case. There's a good reason almost all guides first written before 2015 specifically instructed everyone to use 'apt-get' directly. For quite some time the more uniform 'apt' frontend really wasn't intuitive or helpful. (Just to be clear: these days it is phenomenal in its simplicity and clarity.)
And as someone who has has to dive in to the package managers' code bases, the overall quality of libapt used to be .. questionable. Figuring out code and control flows back in 2010 was like trying to rub chili out of your eyes with an unsanded wooden spoon.
But the sheer bullheaded stubbornness Debian imposes on their package universe and its architecture means it's an absolute joy to work with if you're doing any kind of distro customisation work.
from apt(8):
SCRIPT USAGE AND DIFFERENCES FROM OTHER APT TOOLS
The apt(8) commandline is designed as an end-user tool and it may change behavior between versions. While it tries not to break backward compatibility this is not guaranteed
either if a change seems beneficial for interactive use.
All features of apt(8) are available in dedicated APT tools like apt-get(8) and apt-cache(8) as well. apt(8) just changes the default value of some options (see apt.conf(5) and
specifically the Binary scope). So you should prefer using these commands (potentially with some additional options enabled) in your scripts as they keep backward compatibility
as much as possible.
So I don't know what tool other than apt-get could "guides first written before 2015" use.
OTOH aptitude is, to this day, a joy to use.
What do you mean?
But it's a small issue compared to the mess I see in the rest of software these days ...
Alpine Linux seems interesting too, although right now Debian suits me well. I guess the problem is that I still don't make Debian packages myself, while Alpine's APKBUILD seems more approachable -- pure shell, while Debian has an array of tools and formats.
But Debian "lagging" a bit can be a feature, not necessarily a bug.
This can be configured with service-policy.d(5), see https://packages.debian.org/bookworm/policy-rcd-declarative-... for example.
What are you getting conflicts on? Unless you’re pulling from Sid, and did something fun like upgrading libc6, you shouldn’t see version conflicts if everything was installed via apt.
Debian does have Conflicts package metadata - https://www.debian.org/doc/debian-policy/ch-relationships.ht...
So in theory I don't like it, but I now better understand the possible reasons for it, and I haven't run into it recently
I think there is room for other systems that don't have this problem, but Debian is good at what it does, and you can build other things on top of it
Then it mislead you. Anarchist organisations aren't typically characterised by large, long and complex sets of policies, constantly evolving, that are strongly policed. Often by bots.
This is the reaction from one software engineer that stumbled into Debian infrastructure: https://lists.debian.org/debian-devel/2023/09/msg00334.html
To quote one part of that email:
I've been maintaining free software for 30 years so I've got a lot of experience with a lot of different tools, and I've rarely encountered anything that is as comprehensive and well-documented as all this stuff is.
And while it's a flat(ish) style hierarchy, it has leaders (the DPL), a judiciary (the technical committee) and even behaviour police (whoever polices the conduct - it is policed).
1. Many anarchist movements do not demand this much change. They only demand removal of specific forms of hierarchies they think most problematic. The Occupy movement for instance was demanding the curtailment of the political power of the 1% over the 99%. Its always better to think of political movements as directions of evolution in political space, rather than specific destinations.
2. Then how do anarchists propose that laws/constitutions be imposed? By consensus and discussion. By making sure everyone is on board. Or by temporarily giving someone conflict resolving power (as in the Debian case). Plenty of societies and organizations operate this way, and work fine. Read The Dawn of Everything for some historical examples. See a region in Syria [1] as a modern example.
[1] https://en.wikipedia.org/wiki/Autonomous_Administration_of_N...
The politics of it certainly generated a lot of distrust and resentment among the users and contributors. The project's reputation was undoubtedly hurt.
Perhaps most importantly where the technological impacts. It's one thing when a user can generally ignore the politics surrounding a Linux distro, and the software still does what it needs to do. It's another matter when one routine update after another causes their computer(s) to no longer boot, among other serious problems, all thanks to systemd. Users definitely notice incidents like that, and it decreases, or even eliminates, their trust.
So much hard-earned and invaluable goodwill was unnecessarily lost during and after that period of time.
If any good did arise from that situation, it was that more people became aware of the BSDs, or tried them again if they'd used them in the past. FreeBSD and OpenBSD saved users who needed the reliability and trustworthiness that Debian used to offer, before systemd negatively affected the quality of Debian.
Is there any publication quantifying this?
I followed the whole debacle with interest, and my personal experience with my servers was the exact opposite: adopting systemd improved reliability and made administration significantly easier. It's sad that this was politicized by a small part of the community, but the end result was worth it.
Systemd is incredibly controversial among a niche group of people who have strong opinions about how init & core system functionality should work, and then there’s an outer ring of people who focus on one or two problems with some relatively minor problems that Systemd caused for which there are viable workarounds. Like how Systemd terminates processes that belong to your session when you log out.
I remember writing SysV style init scripts or rc.d / BSD style init scripts. It was awful. You had all these copy-pasted shell scripts with various gaps in functionality depending on who wrote them. Getting a service to run in Systemd feels like heaven by comparison. I don’t even care about, like, Docker.
I think the reports of problems (like background processes getting termed on logout, how any security problems in Systemd tends to be severe by nature) were just so numerous compared to the reports of the benefits (like the boot time improvements and the massive improvements running daemons). It was some bad decisions and a lot of bad PR, but the overall impact IMO is very positive.
Here's the /etc/rc.d/sshd:
#!/bin/ksh
#
# $OpenBSD: sshd,v 1.7 2022/08/29 19:14:25 ajacoutot Exp $
daemon="/usr/sbin/sshd"
. /etc/rc.d/rc.subr
pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*"
rc_configtest() {
${daemon} ${daemon_flags} -t
}
rc_cmd $1
[Unit]
Description=OpenBSD Secure Shell server per-connection daemon
After=auditd.service
[Service]
EnvironmentFile=/etc/default/ssh
ExecStart=/usr/sbin/sshd -i $SSHD_OPTS
StandardInput=socket
Simply not true in (modern) BSDs, well at least OpenBSD; I'm not familiar with the others.
I had the same feeling when Apple came out with launchd in 2005. It felt like such a massive improvement over the existing state of things. Systemd also feels like a massive improvement.
I stumbled upon an auditor with programming skills, who did all his scripting in Korn shell. To me it was like he was from another planet.
Beyond that, I've heard of enough problems involving systemd from my Debian-using colleagues and acquaintances, too.
I don't know if it's been formally studied in any way, but it was clear to me that I definitely wasn't alone in experiencing problems involving systemd.
The widespread negative sentiment that exists toward systemd, including from well beyond the Debian community, didn't just come out of nowhere.
From what I can see, it was generated thanks to a lot of people directly experiencing a lot of unnecessary problems caused by systemd.
Instead we welded the systemd engine into the chassis and pray that when it comes to replacing it we aren’t the ones on the hook.
I don’t see how such a compatibility layer would work in a way that doesn’t suck horribly.
added: Debian's (to me) about (among other things) technical superiority, a robust packaging system, as well as user freedom and choice. It's super easy to not use systemd these days, "what is debian" didn't change, there was just a slight delay in reality catching up to principles. :)
During this thought process I always make a plan of what open source software project I should donate, and debian is always one of the first several candidates.
Now I just need the money! (meanwhile I donate to debian anyway)
The best thing someone could do in this scenario would to be hire someone to work on/improve Debian directly.
Linux in general could use various improvements, if some billionaire decided to fund people to work on it. But I don't really see how any distro could use the lion's share of that funding. Instead, much of it probably needs to go to infrastructure things like drivers, Wayland, etc., so that Linux works better on people's computers. Other things that could use development funding are various applications. But these are things that all distros share.
> The easiest method of donating to Debian is via PayPal to Software in the Public Interest, a non-profit organization that holds assets in trust for Debian.
> Software in the Public Interest (SPI) is a non-profit corporation registered in the state of New York founded to act as a fiscal sponsor for organizations that develop open source software and hardware. Our mission is to help substantial and significant open source projects
Edit: But also, freexian
https://www.freexian.com/lts/debian/
> To achieve the 5 years of support, and properly cover all Debian packages, Freexian organizes a corporate sponsorship campaign with the goal of funding the work of multiple Debian contributors who are established as independent workers.
> If you are not yet convinced, here are seven reasons why you should help fund the Debian Long Term Support initiative (LTS):
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
"We acknowledge that some of our users require the use of programs that don't conform to the Debian Free Software Guidelines. We have created "contrib" and "non-free" areas in our FTP archive for this software."
I had it running on a couple of my machines about 1 or 2 years ago and an update came in for WiFi that bricked them. I started looking into rolling back or whatever and just decided to switch those to Ubuntu (or Kubuntu actually) and they work great and have has no issues.
Debian 12 even made a dedicated non-free-firmware repo for free software purists who would like to concede having non-free drivers just so they can use their hardware.
When it comes to an already installed system, enabling the non-free repos and installing linux-firmware (or more specific firmware-* package for your hardware) should fix it.
My Debian 12 install didn't come with proprietary Nvidia drivers, nor did it ask me if I wanted them during installation. I had to enable the non-free-firmware repo to get them.
I'm not 100% sure about this but I believe it may enable it for you automatically if non-free firmware was used during the install. I mentioned it just in case.
> My Debian 12 install didn't come with proprietary Nvidia drivers
The primary problem of the previous non-free driver policy is the lack of network drivers which make it impossible to install nor download the drivers even if you somehow managed to install the OS. This is now resolved.
It's not a big deal if the ISO doesn't include every non-free driver out there as long as you can manually install it after the fact.
Here is the relevant part from the release notes:
> In most cases firmware is non-free according to the criteria used by the Debian GNU/Linux project and thus cannot be included in the main distribution. If the device driver itself is included in the distribution and if Debian GNU/Linux legally can distribute the firmware, it will often be available as a separate package from the non-free-firmware section of the archive (prior to Debian GNU/Linux 12.0: from the non-free section).
> However, this does not mean that such hardware cannot be used during installation. Starting with Debian GNU/Linux 12.0, following the 2022 General Resolution about non-free firmware, official installation images can include non-free firmware packages. By default, debian-installer will detect required firmware (based on kernel logs and modalias information), and install the relevant packages if they are found on an installation medium (e.g. on the netinst). The package manager gets automatically configured with the matching components so that those packages get security updates. This usually means that the non-free-firmware component gets enabled, in addition to main.
https://www.debian.org/releases/bookworm/amd64/ch02s02.en.ht...
The guy truly believed in the GNU/Linux 'way' and 'free as in speech' software. His initial drive was from the difficulty of packaging and package management and that is probably his biggest contribution. Network-of-Workstations (NOW... think peer-to-peer infratsructure) was his passion that he really never quite got going.
Bruce Perens, the guy he handed control over to, is the authoritarian leader being refered to. I like the guy. He's definitely in the old guard, aka Linus Torvalds, style of management. In big complex projects with volunteers that syle works.
Anyways, the old days of Linux and Debian were a blast. I never quite go tinto like all these other people, but I miss those old days.
There's way too much money people involved today. So it goes.
Ian's manifesto explains it all, anyways.
https://www.debian.org/doc/manuals/project-history/manifesto...
> https://en.wikipedia.org/w/index.php?title=Ian_Murdock&oldid...
After that, I heard he was CTO of Sun. At that point his marriage had fallen apart and his drinking had become a problem (I got all this second hand through mutual friends).
Everyone was shocked by the suicide and the events leading up. Seemed like he spiraled at the end.
So I think traditional Linux distributions will remain, at least as development tools.
Of course it is true that many end users these days get by with just a phone or a tablet but this is a general thing and also results in less Windows users too.
Also my point is about Linux kernel, being as relevant as AT&T UNIX, after the generation that created it is no longer among us.
Ubuntu and RedHat basically don’t work by any of my definitions of “work”.
They’re both enterprisey and bloated and flaky in all the ways Windows was in the 90’s, except they add flatpack/snap, letting each program be its own flaky OS install, compounding the problem. Want to save a file to ~? Read this 1000 page tome on the 21 successors to SEL first.
Anyway, my current heuristic is that if it defaults to systemd or wayland, then I don’t want to use it.
Debian was never the default for big sprawling corporations, so it’s not clear to me that just staying on the “suckless ethos” side of such an ecosystem fork would be that bad vs. Linux in its previous heyday.
All in all, my intent is mostly just to say we’re not in consensus. I doubt a massive revolution is coming if your assumption is that it is because there’s some overwhelming majority with your opinions.
It was a different world. Full of hope and wonder at this new thing. Remember the first major browser wasn't out until '94. We were all playing with Mosaic from the NCSA (which us Purdue kids got to have a small hand in).
Meanwhile, you can still build the full version of RetroArch from source code by installing the dependencies of Debian's source package, but building the original source code instead.
It's otherwise a great os.
It's in a sense like a legacy carmaker or newsroom being more concerned with its own control than with the product. Doesn't end well over the long term.
I don't buy this. People don't choose Debian for the third party software in the repo. If they did, it's a bad choice.
People choose Debian as a rock solid and stable base OS, and it's perfectly rational to use it as a base for third party software on top from other sources.
It's an excellent choice. Debian provides about 60k software packages compared to say 15k in the Fedora repos. Debian and derivatives vastly outnumber other distributions in terms of available software, it's what drove Ubuntu's popularity, everything's available on it.
You can use it as a stable base OS, but it doesn't have any particular advantage, and even some disadvantages compared to RedHat or Suse distributions which offer you many more enterprise tools like Yast out of the box, package managers that are able to do atomic and reversible transactions, which apt still does not do, and so on.
If I need a specific app to always be up to date, I can get it from external sources on a case-by-case basis, such as downloading an AppImage/Flatpack from the developer's website or using Docker.
Why wouldn't you want a rolling distro if you want everything updated all the time?
I have heard users of other distros and a few upstream complaint that Debian "modifies" their packages?
Is it so? If yes, there surely must be a good reason. Can someone tell me about it?
* make the software behave like Debian needs it (configuration is stored somewhere in /etc/, no additional downloads at runtime, use the system libraries instead of vendored ones) * security backports. Debian freezes the functionality at release and only provides security updates. Many software nowadays just includes security fixes in new releases bundled with new functionality.
In combination these two kinds of patches lead to growing differences between a Debian released version 1.2 and the "real" 1.2, making it harder to handle bug reports (e.g. you get a bug report for version 1.2-Debian, but only support the "real" version 1.4 with a whole set of updated libraries).
The third kind of patch has mostly gone out of style; it's when Debian thinks they can improve the software. That lead to things like removing randomness from SSH keys: https://github.com/g0tmi1k/debian-ssh
This type is actually really common. Debian packages something like 30k upstreams, and so some are always behind.
1. Incremental versions. Think like Chrome, there are not bug fixes, just new versions that may contain bug fixes.
2. Major versions, where you'll end up with semver style versioning. You'll have version 1 and version 2, but you'll also get version 1.1 released after 2 as it is the same as version 1, but with just a bugfix applied.
Debian essentially will only work with the second methodology, as they are API stable, which makes software developed by the first method incompatible.
To work around this Debian will backport "fixes" from version 3 to version 1, and create their own version 1.debian-2. The problem here is that people will now raise bugs with upstream on behaviour that was never released.
Yes Debian is allowed to do this, but upstream is also allowed to be unhappy with the additional workload that Debian puts on them.
Love it, Debian is amazing.
Get this wrong, stuff breaks regularly, and one ad-hoc fix follows another, forever.
Get this right, and everything Just Works™ (generally).
Debian is very good in this regard (along with the BSDs, I'd say).
I love that whole paragraph. And in general prefer their philosophy.
https://bootstrappable.org/ https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...
I don't understand what the author means here. What is unclear about the four freedoms? To me, Debian's definition looks redundant.
And yet that isn't actually good enough. Those general principles, being general rather than specific, require the key word, interpretation, in each new specific context. And different people with different goals can and do always ALWAYS warp interpretation in infinite ways that are all perfectly reasonable sounding on their face, and yet someone else can always produce a totally different interpretation, which also holds together.
The DFSG said yes.
Does a licence says "you may modify this and redistribute it as much as you like, but if you put it on a CD then everything else on there must also be free" count as free?
The DFSG said no.
What was this about ?
They weren't literally an owner. That's why the "implicitly". Everyone was still only volunteers. But everyone volunteerily let them call all the shots.
Then later they developed a formal democratic structure and the leader is more of a coordinator than boss.
- 3rd-party software is not welcome; there is no mechanism for installing it securely because you are supposed to either install software from official repository or compile what you have written yourself. For example, if you want to install Sublime Text, or VS Code, there is no way to do it securely, without giving untrusted software access to your browser history and SSH keys. Of course, you can ignore security and run sudo curl http://script , but it doesn't guarantee that the installer won't break something. It is like we are back in 95 when every second program would replace system DLLs in Windows folder and break other software.
- there are third-party repositories, but they can cause conflicts and you better not use them, but there is no other way to install third-party software.
Third-party software is very important, I install OS to run it, and it surpises me that Linux is so unfriendly to third-party software, including closed-source software and doesn't provide means to install and run it securely and reliably and without making developers adapt it to every existing distribution.
- their bugtracker is email-based and as I don't use email it is completely alien to me. But maybe this is not bad because it stops most of people from posting bugs and saves time to reply to them.
I also tried Fedora, and here is what I don't like:
- they release a new version every 6 or 12 months and it is incompatible with older version, and you have to use a very weird way to upgrade: first, you need to install non-standard plugin (dnf-plugin-system-upgrade), then you need to download packages, then reboot into a temporary OS, then if everything is ok, it will create a new OS, and reboot into it. It looks complicated, easy to break and probably requires a lot of disk space, while Debian can upgrade everything in place.
- if a system component like Gnome is crashing, there will be neither log records nor crash dumps and you will never figure out why it has crashed
Also, APT is buggy when dealing with mixed 32-bit/64-bit packages: I wanted to install a package once and it suggested to delete half of the system to do it; luckily I have noticed that the package list is too long before agreeing. Why would package manager delete packages when I ask to install something, I don't understand. As a bugtracker requires using email, I didn't report it, and it would be difficult to reproduce this anyway.
You don't need to adapt your software that much to have it run on Linux distributions; there are standards that the distributions implement that you can rely on. Often software that claims to only support one particular distribution will run perfectly fine on others. Linux distributions are not unfriendly towards third party software, but they have no obligation at all to spend effort to make that software work, it's the third parties that should do that work.
The bug tracker being email based is because when Debian started, that was the normal way to communicate on the Internet (besides IRC). A lot of tools were built on it, and the Debian developers themselves are used to it, so there is little incentive to change this.
The Debian developers would say that apt is not buggy; it's just that if there are conflicts, they have to be resolved in some way, which means deleting some of the conflicting packages. It also does ask you to confirm in this case. Although it would indeed be better if it would detect this is a very unsatisfying solution.
First, if you don't trust a bit of software, why are you installing it?
But more importantly - you don't want your text editor to be able to open and edit your browser history files, or your ssh key files?
If my text editor wasn't able to open and edit those files, I'd consider it extremely broken!
The more people you trust, the larger is the chance that you get deceived.
> But more importantly - you don't want your text editor to be able to open and edit your browser history files, or your ssh key files?
Only with my permission.
Do I? Strange, I've never noticed needing to do that myself.
Giving VS Code express permission to your home/filesystem (the default if you install it traditionally) is a security risk [0] [1] most people rarely think about.
[0] https://blog.aquasec.com/can-you-trust-your-vscode-extension...
[1] https://www.techradar.com/news/hackers-are-using-malicious-m...
Um, I thought it was?
I've not used it, because I'm happy with (neo)vim for my dev needs, but I thought that's what it did?
If VS Code isn't used to edit text, what is it for?
Edit: (neo)vim and emacs both have 3rd party extension ecosystems, with extensions written in languages that can access the internet, so I'm not sure how that affects your test?
On Fedora you can use ABRT (AKA Problem Reporting) to view logs and tracebacks of a component that has crashed, and report the problem via Bugzilla. Also, GNOME isn't a system component, Fedora would still work without it, but it would use a TTY terminal instead.
I’m thinking: implemented in nodejs with a cli with emojis and animations.
The GitHub read me should have a minimum of 80 emojis and a meme or two.
The core dependency of the cli should be a 6 month old framework with 92 commits. When that library reaches 1 year old, it should be swapped out for something newer as the sole maintainer will have left their job and/or got bored with the project having spent so long on it
* creating Debian packages is a difficult process to learn. There’s a bunch of tools and wrappers around those tools to handle inadequacies and it’s not clear how to do it “right”. For example, if I just have a binary and want to put it into a Debian package without pulling in some random shell scripts that aren’t part of Debian proper, it’s not immediately clear how to do that.
* Non-atomic and imperative install/remove/etc. hooks make it difficult to robustly handle failures. Since there is no file system manifest or sandboxing, there’s no real guarantees that removing a package will actually remove it.
* there’s no spec for a .deb package. This means the only way to correctly generate a Debian package is through the difficult tooling. I understand why this choice is made, and it has a lot of benefits for the continued evolution of the debian project. However, it makes it difficult to build better tooling around deb packages.
There is a large range of documentation, everything from the simple to the more advanced to different packaging niches. The large amount of docs makes that harder to navigate though, and a lot of stuff is moving towards automated packaging these days anyway.
I agree it always makes sense to have sources involved for packages that are getting distributed as part of the distro, but what if I want to just deploy my product on a server without the sources?
If you want to make external packages (such as those that don't come with source), then you can just use `dpkg-deb --build` or one of its many wrappers to shove the binary into a .deb.
The only significant future change I can think of is the mtree stuff, which would add an additional metadata file to .deb files.
There are several warts in the .deb file format that the dpkg folks aren't fixing because of compatibility concerns.
https://wiki.debian.org/Teams/Dpkg/RoadMap https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking https://wiki.debian.org/Teams/Dpkg/TimeTravelFixes
there are distributions that provide rollback. but as far as i can tell they require you to keep the old version to roll back to, stored on your computer. you can't roll back otherwise.
i really want this to work like revision systems for code, where i can just checkout any old version that was committed.
another feature that i would like to see everywhere is stickiness of the packaging source. currently, if i include additional repos they override the main repo, such that always the newest version is picked from any repo.
this makes it difficult to include less trusted 3rd party repos. i would like to be able to add 3rd party repos such that only the packages that i explicitly install from that repo will also be updated from that repo, while any other packages in that repo will be ignored unless no other repo has them.
in debian it is possible to set priorities for different repos, but that is not easy to manage. the priorities to have each package update stick to the original repo should be default.
guix and nix do provide some of this as far as i can tell, but i am not a fan of keeping every package self contained with massive link trees. (i may change my mind on that some time maybe, but that's what i feel for now)
conary was/(is?) a packaging system that did have both of these features, although, according to some of the developers the repository was a bit clunky and could have been better. but that was under the hood, not noticeable to users and packagers. i loved working with it and i wish foresight, the distribution using it had become more popular so that it would have had the manpower to keep going.
https://manpages.debian.org/testing/devscripts/debbisect.1.e... https://wiki.debian.org/BisectDebian
https://wiki.debian.org/AptConfiguration#apt_preferences_.28...
I found it be a big ball of easily forgettable twine of rules tools and oddities myself that every time I needed to redo something was a hassle. With many foot guns that lead to odd package issues.
Can you elaborate, please? What do you mean by this?