People that want the latest versions of gimp or whatever are probably not going to be running Debian stable. People that want to install a machine and not really be burdened by it for a couple of years are.
Debian has, for pretty much its entire life, had a large proportion of veteran sysadmins and programmers as part of the organization. Many of us have learned the value of this kind of stability from the school of hard knocks – over and over again. We recognize the value of something that just works, that is so stable that things like unattended-upgrades are safe and reliable. With many other distros, something like this isn’t even possible; when your answer to a security bug is to “just upgrade to the latest version”, just trusting a cron job to do it isn’t going to work because of the higher risk.
This and only this is what makes me run Debian stable on all of my daily-driver machines. I want a system that “just runs” but doesn’t bother me about updates and upgrades. You’ll realize the value of this, once you start dealing with real systems which control real actuators in the real world.
The most accessible examples of this are home-automation and smartphones. It’s also the reason why the systems controlling real production-lines in factories are often still running decades old versions of MS DOS, Windows 95, 98 or XP.
Nearly all of the “fast evolving stuff” I use for software-development has been relegated to virtual-machines in virtual-box. This is because it keeps my “important”-stuff away from the “I don’t have time to verify all this”-stuff, and because it is the fastest and easiest method of getting an extra development machine running.
I’ve noticed over the years that those Debian systems, only tend to break during major version upgrades, while my dedicated gaming machine which runs Windows 10, was rendered non-functional after it rebooted itself for an update just this weekend! To add insult to injury: The exact same thing happened to me right after Christmas, so there was absolutely nothing else on that machine other than a plain install of Windows 10 and a bunch of games installed through Steam.
It’s because of Debian’s approach that something like this doesn’t happen all that often, and as a user I have to admit that I totally love them for that!
i don’t get what’s more appealing about debugging things in a virtual machine than not in a virtual machine, unless you’ve had software dev tools render your whole machine unusable
I’ve had software dev-tools that rendered the (windows 7) machine I was working on completely unable to boot up.
Ever since then I’ve been doing just about all development with large projects in a VM.
Howver, the true appeal comes from the fact that I can be lazy: For example: I can shut down the host after saving the VM state to disk. When I boot up and return to the dev-work, I simply unfreeze the VM and I can continue exactly where I left off. It’s also pretty convenient that I do not have to be careful. When I do one “rm -Rf” too many or if I botch up something in a terrible way, I simply restore the snapshot. It’s also an easy way to have an OTAP-environment like this. If something went wrong on test or accept, you simply open an image that is a clone of the current test or accept system and you can dig around locally to reproduce and figure out what went wrong.
I love how fiercely independent Debianistas are. It’s true, Github tries to make sure that you do everything via its web interface. It even encourages newcomers to edit code and create small commits via the web interface, which has the effect of tying you even more to the site. Doubtlessly this has had some effect on its wild popularity, and of course a DD wouldn’t like the idea of being tied down to an external service (or even, to a particular VCS; although git is the most popular one for Debian, it is not required unless you want to use Debian’s salsa service).
That being said, there has been for a long time the idea to give debbugs a web interface. I scavenged the code here:
Some day, maybe me, maybe someone else, but maybe some day someone will update this to work with current Django and make it minimally good enough to be used with Debian.
It’s true, Github tries to make sure that you do everything via its web interface. It even encourages newcomers to edit code and create small commits via the web interface, which has the effect of tying you even more to the site.
I think having good and approachable UI can be separated from being a centralized service. That’s, in my opinion, the best idea of sourcehut - the service is “federated” and uses e-mail as a transport but at the same time has nice Web UI and buttons that actually help people to follow the workflow. For example “Subscribe” button is a mailto URI with correct address filled in, “Reply to thread” correctly sets Cc, In-Reply-To and other headers.
One could imagine a nice Web UI that’d allow people to edit files and then exported changes as an eml file to be sent (or a very long mailto URI with body parameter, I just tested, it works in Thunderbird).
I think centralized services just brought a lot of good things to the table, like easy modification of trivial things (typo fixes), CI integration, notifications about “merge-ability” and decentralized solutions did not catch-up with that. And users become more demanding, because ultimately they just want to get the work done, not fight with the system.
although git is the most popular one for Debian, it was not required until very recently
Is git now required for Debian? That would be surprising and disconcerting.
Debian source packages can declare Vcs-* metadata for packaging. On my up-to-date Debian unstable, fasm declares Vcs-Git to https://salsa.debian.org/debian/fasm.git, but yasm declares Vcs-Svn to svn://svn.debian.org/sam-hocevar/pkg-misc/unstable/yasm, so if there’s any requirement transition is not complete.
Stability through avoidance of change just doesn’t work in practice. Your system will change, constantly, through contact with the world. If you are hoping to hold back the tide by sticking with what worked before, eventually you will lose that battle.
Resilient systems change constantly. They embrace it. From the linked article, and the post it references… Debian doesn’t. That’s not healthy.
This and only this is what makes me run Debian stable on all of my daily-driver machines. I want a system that “just runs” but doesn’t bother me about updates and upgrades. You’ll realize the value of this, once you start dealing with real systems which control real actuators in the real world. The most accessible examples of this are home-automation and smartphones. It’s also the reason why the systems controlling real production-lines in factories are often still running decades old versions of MS DOS, Windows 95, 98 or XP.
Nearly all of the “fast evolving stuff” I use for software-development has been relegated to virtual-machines in virtual-box. This is because it keeps my “important”-stuff away from the “I don’t have time to verify all this”-stuff, and because it is the fastest and easiest method of getting an extra development machine running.
I’ve noticed over the years that those Debian systems, only tend to break during major version upgrades, while my dedicated gaming machine which runs Windows 10, was rendered non-functional after it rebooted itself for an update just this weekend! To add insult to injury: The exact same thing happened to me right after Christmas, so there was absolutely nothing else on that machine other than a plain install of Windows 10 and a bunch of games installed through Steam.
It’s because of Debian’s approach that something like this doesn’t happen all that often, and as a user I have to admit that I totally love them for that!
i don’t get what’s more appealing about debugging things in a virtual machine than not in a virtual machine, unless you’ve had software dev tools render your whole machine unusable
I’ve had software dev-tools that rendered the (windows 7) machine I was working on completely unable to boot up. Ever since then I’ve been doing just about all development with large projects in a VM.
Howver, the true appeal comes from the fact that I can be lazy: For example: I can shut down the host after saving the VM state to disk. When I boot up and return to the dev-work, I simply unfreeze the VM and I can continue exactly where I left off. It’s also pretty convenient that I do not have to be careful. When I do one “rm -Rf” too many or if I botch up something in a terrible way, I simply restore the snapshot. It’s also an easy way to have an OTAP-environment like this. If something went wrong on test or accept, you simply open an image that is a clone of the current test or accept system and you can dig around locally to reproduce and figure out what went wrong.
I love how fiercely independent Debianistas are. It’s true, Github tries to make sure that you do everything via its web interface. It even encourages newcomers to edit code and create small commits via the web interface, which has the effect of tying you even more to the site. Doubtlessly this has had some effect on its wild popularity, and of course a DD wouldn’t like the idea of being tied down to an external service (or even, to a particular VCS; although git is the most popular one for Debian, it is not required unless you want to use Debian’s salsa service).
That being said, there has been for a long time the idea to give debbugs a web interface. I scavenged the code here:
http://inversethought.com/hg/bts-webui/file/tip/bts_webui
Revision zero is close to 12 years old now:
http://inversethought.com/hg/bts-webui/rev/0
Some day, maybe me, maybe someone else, but maybe some day someone will update this to work with current Django and make it minimally good enough to be used with Debian.
I think having good and approachable UI can be separated from being a centralized service. That’s, in my opinion, the best idea of sourcehut - the service is “federated” and uses e-mail as a transport but at the same time has nice Web UI and buttons that actually help people to follow the workflow. For example “Subscribe” button is a
mailtoURI with correct address filled in, “Reply to thread” correctly sets Cc,In-Reply-Toand other headers.One could imagine a nice Web UI that’d allow people to edit files and then exported changes as an
emlfile to be sent (or a very longmailtoURI withbodyparameter, I just tested, it works in Thunderbird).I think centralized services just brought a lot of good things to the table, like easy modification of trivial things (typo fixes), CI integration, notifications about “merge-ability” and decentralized solutions did not catch-up with that. And users become more demanding, because ultimately they just want to get the work done, not fight with the system.
Is git now required for Debian? That would be surprising and disconcerting.
Debian source packages can declare Vcs-* metadata for packaging. On my up-to-date Debian unstable, fasm declares Vcs-Git to https://salsa.debian.org/debian/fasm.git, but yasm declares Vcs-Svn to svn://svn.debian.org/sam-hocevar/pkg-misc/unstable/yasm, so if there’s any requirement transition is not complete.
Sorry, edited it, I thought everyone had to use Salsa now.
[Comment removed by author]
I got 5 paragraphs in, and it lost me.
Stability through avoidance of change just doesn’t work in practice. Your system will change, constantly, through contact with the world. If you are hoping to hold back the tide by sticking with what worked before, eventually you will lose that battle.
Resilient systems change constantly. They embrace it. From the linked article, and the post it references… Debian doesn’t. That’s not healthy.