23 ms·
> Developers can just publish their apps directly on their own schedule. As a Debian user I do not see that as a feature, I see that as a risk. One of the big
by click170 11y ago
> Developers can just publish their apps directly on their own schedule.
As a Debian user I do not see that as a feature, I see that as a risk.
One of the biggest reasons I use Debian is because package management is done the way it is, but a lot of people complain because the packages in Debian Stable are out of date. I think the disagreement here isn't on whether the software in Debian Stable is up to date, it's actually about what the definition of stable is. Many people prefer bleeding edge. For me, I prefer Debian's definition of stable, and I don't want the developers of the software being able to push it to my systems on a whim because on rare occasion developers have been known to use their users as their testers, and this is a risk I want to minimize.
Regarding your other points, could you expand a bit on decoupling the OS from the applications? Everything else sounds like it could be a feature request against apt, do you have a moment to file them? It sounds like you've got some good ideas.
- dmix 11y ago> Many people prefer bleeding edge. For me, I prefer Debian's definition of stable Having maintained Debian, Fedora, and ArchLinux machines over the past few years, I've found ArchLinux has vastly improved in terms of stability recently while still maintaining close to bleeding edge releases. I don't see it get enough credit for this. This must be the result of having a high quality team of package maintainers who know how to push out new packages properly. Fedora on the other hand also promises bleeding edge - but for years I found it broke far too often, and yum is certainly not helpful in those situations. As a result I no longer see it as a "bleeding edge vs stable" dichotomy. You can have your cake and eat it too if you a) choose your software stack wisely and b) use a distro with a smart team behind it. Switching to the Debian boxes always feels like stepping back 2yrs in a time machine, which has a high cost for a person who likes to keep up with progress in software development.
- rifung 11y agoHm interesting.. do you ever feel like you are missing out on any programs while on ArchLinux? It seems that when people want to support Linux they often only choose to support Ubuntu/Debian. I'm definitely tempted to give ArchLinux a try now though
- tormeh 11y agoThe great thing about Linux is that if some software supports one distro, then there's always a sane way to get it working on other distros.
- rifung 11y agoAh! Well, I suppose I was always afraid of having to mess with OS related stuff instead of getting things done but I think it's about time I learn. Thanks for the information!
- comex 11y agoOf course, there's also Debian unstable, which is, in fact, pretty darn stable. I don't maintain servers professionally, but I've been using Debian unstable personally for years, and rarely had problems.
- click170 11y ago> Switching to the Debian boxes always feels like stepping back 2yrs in a time machine, which has a high cost for a person who likes to keep up with progress in software development. (emphasis mine) It still feels like we're disagreeing because we have a different idea of what stable software is, yours is keeping up with progress in software development and mine is using software that's been tried and tested by many others first. If I may suggest, you may enjoy the Unstable or Testing Debian distributions the next time you're giving it a go, if you can get past the admittedly off-putting names. But further, are you suggesting that you can't keep up with progress in software development from a Debian Stable box? With apt-pinning, backports, and having the ability compile from source into .deb files, I have to disagree with you on this.
- keithpeter 11y agoManjaro is a derivative of Arch that includes repositories that are delayed for a few weeks to allow any occasional bugs to be caught. Manjaro Live ISOs provide an installer and hardware detection as well. Just in case anyone wants a play.
- johnny22 11y agoI've watched many applications hold up adding new features that require newer dependencies that don't exist in debian stable and RHEL. So I'm in favor of some sort of solution that keeps the base nice and stable, but still allows new apps to to coexist with it.
- click170 11y ago> I've watched many applications hold up adding new features that require newer dependencies that don't exist in debian stable To me this seems like a problem for the maintainers of the Debian package for that application, and not for the developers of the application itself. Why should the libraries available in one of the many possible linux distros hold up what features the application developers implement? Debian package maintainers are sometimes the application developers themselves, but this doesn't seem like it should be a problem for folks who just write software.
- qznc 11y agoFor Debian "stable" means that the version number does not change. For normal people "stable" means it does not crash. Since newer versions of software usually have less bugs, bleeding edge can be perceived has more stable to some users.
- stephenr 11y agoI think what you mean is the major version number does not change.
- wander_homer 11y agoWell, why not take a look at Debians Repositories: Debian Wheezy (oldstable) was released on 2013-05-04 and is still supported. Let's take a look at two utterly important libraries for desktop usage as reference: gtk+2.0: upstream: 2.24.27, 2015-03-03 (release date) wheezy: 2.24.10, 2012-08-06 (build date) qt4-x11: upstream: 4.8.6, 2014-04-24 (release date) wheezy: 4.8.2, 2013-02-05 (build date) Both libraries haven't received a single update since the release of wheezy, gtk+2 is 10 bugfix releases behind upstream and nearly 3 years old. So no, Debian doesn't change version numbers at all (at least for most packages). And honestly I don't get why. This kind of update policy where you even don't ship bugfix releases might have valid use in special cases (e.g. some embedded environments) but Debian wants to be the universal operating system. http://metadata.ftp-master.debian.org/changelogs//main/g/gtk+2.0/gtk+2.0_2.24.10-2_changelog http://metadata.ftp-master.debian.org/changelogs//main/g/gtk... http://metadata.ftp-master.debian.org/changelogs//main/q/qt4-x11/qt4-x11_4.8.2+dfsg-11_changelog http://metadata.ftp-master.debian.org/changelogs//main/q/qt4... https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=e6333a1a374591fef456f7fe73942226b5b8b388 https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=e633... https://blog.qt.io/blog/2014/04/24/qt-4-8-6-released/ https://blog.qt.io/blog/2014/04/24/qt-4-8-6-released/
- pmontra 11y agoWhat I want is to get (example) the latest nginx and postgresql as soon as they are released, that's why I install them from the developer's ppas both on debian and ubuntu. However I understand the merits of your conservative position (I read your other post too) but I feel that I'm missing too much in that way. There are many desktop applications that I install from 3rd party ppas on ubuntu because they are too out of date in the distro or unavailable, and I think no developer uses the distribution version of languages (node, ruby, erlang, etc). There are package managers for them and you need them server side too. Then you get used to use the distribution ppa only for the core OS and stuff you don't care much about. I'm not sure that I want to dockerize the desktop, and how silly would that be for less or ls, but in a way 3rd party ppas and conservative distros paved the way for it.