Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Miguel A. Vallejo wrote: ... > I activelly follow the development of some programs in diverse areas > (ham radio, astronomy, emulators, etc), and new versions usually > appears in unstable months after release. The more prominent example > is the kernel itself. Current version is 5.5.7, but unstable still > have 5.4.19. When the statibily of your system depends on a feature or > bug solved in a new kernel version, this can be distressing. > > Even with all this, I still prefer to use Debian. these days so much is happening in other repositories that as much as possible for a project i want to follow closely i'll just fork it on github and pull it to my machine and use some form of an environment to localize the changes (putting in more paths to binaries/libraries, etc). i think a lot of what is packaged for debian is nice and i appreciate the efforts of the people who do it but with some code the developers have no idea of how to do things properly and they are messing up so i have no choice but to follow them (and regret it in one case because it's annoying to not have someone understand a cycle of development which involves ideas like stable vs. development and not introducing breaking changes too frequently - like every minor release...*sigh*). songbird
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
I have a friend who works as a system administrator that always says: Debian Stable --> Debian Server Debian Testing --> Debian Desktop Moderate Debian Unstable --> Debian Desktop Fast Being Moderate and Fast the speed at you will eat new bugs. As time goes by, I'm more and more agree with him. Debian Stable should be enough for everyone, but... in practice only works for servers and very low demanding desktops / workstations. if you use fast moving software (for example, ham radio applications), or developing new software, or helps developing new software, your only option is to run ahead to testing / unstable. Packages versions in Stable are obsolete even on the very same launch day. The developer puts a new version, you download the sources, try to compile them, compilation failed, asks the developer why and the answer is always the same: Your put_any_library_here version is obsolete, please upgrade. So you are forced to move to testing / unstable. Another case is if you suffer a serious bug with stable, usually hardware support. Then, also your only option is to run ahead to testing / unstable and cross your fingers. In my case, suffering the big problems with Intel video cards the only option is to move to unstable and pray for every new kernel to be the one that solves the problem. I've read there will be no chace to get a working kernel with Intel cards until next 5.7 so now I'm on stable, which seems to be somewhat stable (only one chrash in the last 7 days). I activelly follow the development of some programs in diverse areas (ham radio, astronomy, emulators, etc), and new versions usually appears in unstable months after release. The more prominent example is the kernel itself. Current version is 5.5.7, but unstable still have 5.4.19. When the statibily of your system depends on a feature or bug solved in a new kernel version, this can be distressing. Even with all this, I still prefer to use Debian.
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Tue, Feb 25, 2020 at 06:48:21PM +0100, Sam wrote: > Thanks for your points of view! I agree that Stable comes at a cost, and of > course if I ever were to set up a server Debian would probably be my choice. > > Regarding derivatives, I know about Ubuntu, Mint, etc., but I don't exactly > like distributions tied to or ultimately dependant on commercial entities (I > want a change of air after going through Ubuntu, openSUSE...) I recently made the move to Debian after being a Ubuntu user since 4.10 (first release). > I have also seen independent Debian derivatives (MX Linux comes to mind), but > they either used backports or the Testing distribution. > > I would happily consider using Debian Testing for example, but wherever I see > someone asking about it I always find someone discouraging from using it due > to the possibility of having broken or unsecure packages for a long time due > to it being automated. Is it actually usable for a Workstation? The same > would A lot of people seem to be using Testing as such. > apply to Sid, I can no longer allow myself to fix big breakages after broken > updates (I don't know if that really happens often in Sid) I chose Debian Stable because I need to get work done and can't afford disruptions due to broken updates - I already have to deal with broken internet connectivity, ISP/institutional shenanigans from time to time. I kept my old Ubuntu LTS instance running while I setup Debian Stable with stuff that gave me the same functionality. I have customised my Stable instance with the software that is minimally resource intensive (no GNOME/KDE/XFCE). To make the decision easier: * When work is important stick with Debian Stable * HTH, Didar > Thanks, > Sam > > -- Somewhere in Tenafly, New Jersey, a chiropractor is viewing "Leave it to Beaver"!
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Thu, 27 Feb 2020 09:30:36 -0500 Stefan Monnier wrote: > > Right. You can also use a CD based Linux such as finnix to shrink an > > existing LVM logical volume (LV), create a new LV for swap, and run > > mkswap to lay down a swap partition on it. > > BTW, you don't need a separate CD or anything like that: you can use > your initrd for that same purpose. I.e. at the Grub prompt, tell it > to boot with an argument like `break=local` (IIRC) and it should > (hopefully) drop you into a shell soon before mounting the root > file system. You can then use `lvm lvresize`. > > Bear in mind that LVM knows nothing of filesystems: before you shrink an LVM logical volume you need to shrink the filesystem that lives on it, and conversely if you enlarge the volume, you then need to enlarge the filesystem afterwards. -- Joe
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Thu, 27 Feb 2020 08:54:02 +1100 Keith Bainbridge wrote: > > > I'm having trouble understanding how LVM snapshots works on / if it > is outside the LVM. > I don't think anyone has picked this up. Yes, you do need additional space. I've only done it a few times. It basically involves leaving enough unallocated space to accommodate whatever you want to do with the snapshot. What I used it for was on-line system backup. You can generally get away with just copying a Linux system while it is running, if not much is going on at the time, particularly if you temporarily stop SQL servers and the like. Various volatile files won't be consistent, being copied at different times, but if they are general housekeeping files which are constantly being re-written, then the contents won't matter much after a restore and reboot. Yes, some inconsistencies can be critical, and restoring it in full over your working system is a bit risky. Using it to restore individual files is generally safe, for most people a full restore from backup would be a last resort (OK, second last, just before reinstalling). But I've booted an online copy on another machine on several occasions without (as far as I know) any issues. If you want an absolutely consistent backup (e.g. copying to a bigger hard drive), you either shut down and take it with an external tool, or you can use LVM. When you enable the snapshot, the region of interest is frozen, further disc writes are basically done to a journal, not to the frozen region, and the journal is reconciled with its parent region when you close the snapshot. In the meantime, you can take a backup where no disc files will change while you're doing it. You need enough space for the snapshot to store everything that may written until you terminate the snapshot, but with modern discs you can generally allocate as much space as the largest region you want to back up, which is the safe option. Performance will be a bit reduced during the snapshot period, but that depends on what the system is being used for, how much writing is going on, and in any case a system backup itself will slow things down a lot. Windows Server partitions with Volume Shadow enabled do something like this continuously, managing daily snapshots and deleting old ones up to the limit of allocated space. Read the current docs for exact details of how to do this. -- Joe
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
> Right. You can also use a CD based Linux such as finnix to shrink an > existing LVM logical volume (LV), create a new LV for swap, and run > mkswap to lay down a swap partition on it. BTW, you don't need a separate CD or anything like that: you can use your initrd for that same purpose. I.e. at the Grub prompt, tell it to boot with an argument like `break=local` (IIRC) and it should (hopefully) drop you into a shell soon before mounting the root file system. You can then use `lvm lvresize`. Stefan
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Thu, 27 Feb 2020 11:43:42 +1100 Keith Bainbridge wrote: > OK I am in the process of install debian in vbox. It set up LVM > using the whole partition, and allowed several logical volumes. > > Am I safe to believe that this is what will happen with a SSD when I > start? Yes. > > I got a prompt that I didn't set a swap partition. I ignored that for > now, but will have to remember when I do the real thing. Right. You can also use a CD based Linux such as finnix to shrink an existing LVM logical volume (LV), create a new LV for swap, and run mkswap to lay down a swap partition on it. See https://www.thegeekdiary.com/how-to-add-swap-space-in-linux/ Or just use mkswap to create a swap file. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Thu, 27 Feb 2020 08:59:55 + Brad Rogers wrote: > On Wed, 26 Feb 2020 19:47:35 -0600 > John Hasler wrote: > > Hello John, > > >blindly upgrading nightly causes far more problems than it solves. > > Because that's what gets asked about. Nobody posts saying; > > "I updated lasted night, and everything worked!" > > There's no point. > > However, I do recognise that you wrote 'blindly' and there, you're > right. > I've found it rare for an upgrade to break anything, and if it does, I have more than one computer. What is fairly common is that the upgrade of a large system such as KDE or Qt takes place over a period of time, making upgrading tedious for a week or two. A couple of weeks ago, I had over 400 packages held up by a dependency on one new (and buggy) library. But that's about as bad as it gets. The last time I reinstalled sid was several years ago, on a mobile that I don't upgrade often, and aptitude and apt-get both choked on about a gigabyte of upgrades. The time before that must have been more than fifteen years ago, when a damaged perl upgrade stopped the package tools, even dpkg, from working, and it was beyond my abilities to fix manually. But generally, if the apt tools still work, it's fixable, and it's pretty rare for anything to need fixing. If there is a breakage, the quick answer is to go back to the previous version if it's in the cache, if it's not it can be found on the Net, or if it's not a show-stopper, wait for it to be fixed. -- Joe
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Wed, 26 Feb 2020 19:47:35 -0600 John Hasler wrote: > Andrei writes: > > An entire month without security updates is not the best idea in my > > opinion. > > It appears to me from watching this list that the practice of > blindly upgrading nightly causes far more problems than it solves. As I am not an IT professional or systems programmer, I can't be of much help in building Debian. But I can see bugs as easily as the next user, and I can do basic troubleshooting. So I do fully upgrade sid almost every day, and have contributed a number of bug reports. It's actually quite difficult to be the first, but I can sometimes add a data point. -- Joe
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Wed, 26 Feb 2020 19:47:35 -0600 John Hasler wrote: Hello John, >blindly upgrading nightly causes far more problems than it solves. Because that's what gets asked about. Nobody posts saying; "I updated lasted night, and everything worked!" There's no point. However, I do recognise that you wrote 'blindly' and there, you're right. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" I am alone there's nobody there I Look Alone - Buzzcocks pgpnPV6rF3H7G.pgp Description: OpenPGP digital signature
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Brad writes: > I update daily, but 'cherry pick' in the event of transitions that > _might_ have repercussions. So you *don't* "track" testing by doing automatic full upgrades every day. That is the practice that I'm arguing against. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Andrei writes: > An entire month without security updates is not the best idea in my > opinion. I follow the security list and do security updates as required, of course. Those rarely (if ever) require full upgrades. There is no need to do daily full upgrades just to stay up with security. > Additionally after a month the upgrade can become quite complex with a > lot more moving parts, i.e. it will be difficult to tell what broke. I haven't found it so, but then, as I noted, I run neither KDE nor Gnome. It appears to me from watching this list that the practice of blindly upgrading nightly causes far more problems than it solves. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On 27/2/20 8:54 am, Keith Bainbridge wrote: Thanks for the positive responses. I am interested now because I am about to buy a new drive. I guess the answer to these will be obvious when I choose LVM at the disk selection stage, but do I need to keep system partitions separate? as I install the 2nd & 3rd install? OK I am in the process of install debian in vbox. It set up LVM using the whole partition, and allowed several logical volumes. Am I safe to believe that this is what will happen with a SSD when I start? I got a prompt that I didn't set a swap partition. I ignored that for now, but will have to remember when I do the real thing. System is running well, though. Further changes tonight -- Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On 27/2/20 3:46 am, Charles Curley wrote: On Thu, 27 Feb 2020 00:15:44 +1100 Keith Bainbridge wrote: Is LVM viable? I can see the benefit of re-sizing on the fly. I use multi-boot. I can see the possibility of /dev/sda1 and LVM using the rest. But is it viable, please? Yes, it is viable. I use an encrypted partition with LVM on it to hold everything except /boot on laptops, desktops, and headerless servers. That works well for me. However, I set it up at installation time. Since I have never set up an Rpi, I have no idea whether you can do it on one. Be sure to back up /etc/lvm/ in case the LVM headder gets clobbered. I've had no problem with that for more than ten years, but you never know... Thanks for the positive responses. I am interested now because I am about to buy a new drive. I guess the answer to these will be obvious when I choose LVM at the disk selection stage, but do I need to keep system partitions separate? as I install the 2nd & 3rd install? It seems I'd be wise to create several smallish virtual partitions and add them to my 'work area' as I need them. Amongst other quirks, I have taken up the practice of having a small /home partition for each OS, and sym-linking all data type directories from a bulk partition. I've been using /mnt/data but I saw /data a couple of times last night. I'm having trouble understanding how LVM snapshots works on / if it is outside the LVM. -- Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Tue, 25 Feb 2020 19:18:10 -0600 John Hasler wrote: Hello John, >*Don't* "track" Testing or Unstable by upgrading nightly. I'm with songbird (and others). It can be done, with care; I subscribe to the 'Testing Changes' mailing list. I subscribe to the 'Debian Developers' mailing list. I subscribe to the 'Debian KDE' mailing list. I update daily, but 'cherry pick' in the event of transitions that _might_ have repercussions. By reading, or at least scanning, those lists, I can update fairly safely. I only came unstuck once, and that simply resulted in me having to enter a password twice at a login prompt. A situation that was rectified a couple of days later when KDM (as was in use at the time) got updated. I considered upgrading to sid, but decided against it because I'm far from knowledgeable enough to sort problems out myself, should they arise. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" You're all invited to a party, you don't even have to come Get The Funk Out - Extreme pgpbC1TUGLR1l.pgp Description: OpenPGP digital signature
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Thu, 27 Feb 2020 00:15:44 +1100 Keith Bainbridge wrote: > Is LVM viable? I can see the benefit of re-sizing on the fly. I use > multi-boot. I can see the possibility of /dev/sda1 and LVM using the > rest. But is it viable, please? Yes, it is viable. I use an encrypted partition with LVM on it to hold everything except /boot on laptops, desktops, and headerless servers. That works well for me. However, I set it up at installation time. Since I have never set up an Rpi, I have no idea whether you can do it on one. Be sure to back up /etc/lvm/ in case the LVM headder gets clobbered. I've had no problem with that for more than ten years, but you never know... -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
John Hasler wrote: ... > *Don't* "track" Testing or Unstable by upgrading nightly. I don't > understand why people want to do this. A full upgrade (after a test > upgrade) about once a month is plenty. different people have different purposes. :) my reasons for my morning routine is to determine what is being changed or worked on in the packages that i use/have on this machine. most days i scan the proposed updates and see that they are things i don't mind if they get updated. they're not too likely to impact the few things i do the most. so for me to just get them updated means the next time i do use them i will either help with the testing part or more likely i won't notice any difference at all. which is good. if i do see a bug and have the time to report it then i've done what i consider part of my giving back to the developers and users of the same code base. they can at least be aware that somewhere ahead "There May Be Dragons!" having a nice running computer system that does what i want and expect is my goal. to do that at times means i can't always keep exactly up to date so i will put some updates on hold until i have a bit more time to investigate or ask questions or file bugs or ... > If you have packages you need to have the current release of wait until > they've been available for a week or so without serious or important > bugs that would matter to you. Then do a test upgrade so that you can > decide whether you can go right ahead, have to do a full upgrade to make > it work, or perhaps should wait a bit. yes, if something looks very intrusive to the basic packages i use every day i try to make sure i have time set aside to make sure it all goes as expected. most often in the past that has meant 99.99% of the time that i don't have any problems at all. once in a while "stuff happens[tm]" and having a booting stable set up is sufficient for me to get what i need done accomplished. > I've been doing this with Unstable for most of this century with very > few problems (and none recently). > > And a caveat: I don't use either Gnome or KDE. ditto. they kept changing in ways that got in the way of my workflows/habits/expectations. songbird
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Hi. On Thu, Feb 27, 2020 at 12:15:44AM +1100, Keith Bainbridge wrote: > Is LVM viable? I can see the benefit of re-sizing on the fly. I use > multi-boot. I can see the possibility of /dev/sda1 and LVM using the rest. > But is it viable, please? Yes. LVM does not care if your drive was detected as /dev/sda, /dev/sdb or /dev/somethingelse. It'll work regardless. Reco
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Further to lvm snapshots, I have read about 10 articles explaining the concept of LVM and how to set them up. All of them talk about using /dev/sdb, c, d or more for LVM. None uses /dev/sda I am running a laptop and raspberry pi's, all with only 1 prime 'disk' and USB attached disks/sticks. Is LVM viable? I can see the benefit of re-sizing on the fly. I use multi-boot. I can see the possibility of /dev/sda1 and LVM using the rest. But is it viable, please? Keith BAINBRIDGE keithr...@gmail.com +61447 667 468 Sent from my Apad On Wed., 26 Feb. 2020, 16:42 Keith Bainbridge, wrote: > On 26/2/20 10:59 am, Stefan Monnier wrote: > > LVM snapshots > > I use timeshift for the same purpose; and have needed it a couple of > times over 14 months since switching from mint. > > I look at what packages are to be upgraged, and if more than a few > libraries, I create a new timeshift first. Usually adds about a minute > to the upgrade. > > > I am about to look into LVM snapshots NOW, though. > > -- > Keith Bainbridge > > keith.bainbridge.3...@gmail.com > +61 (0)447 667 468 >
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On 2020-02-26, Andrei POPESCU wrote: > > Debian testing already has checks and delays in place to filter out > (most of the) problems. Updates fixing security issues are prioritised. I used testing once; I found 'apt-listbugs' to be quite helpful in obviating potential disaster (it was invariably only a question of waiting a day or two for things applicable to my installation to be fixed). >> I've been doing this with Unstable for most of this century with very >> few problems (and none recently). > > In both cases (testing and unstable), if the system is in any way=20 > exposed to security threats updating more often than that would be a=20 > good idea. > > Kind regards, > Andrei > http://wiki.debian.org/FAQsFromDebianUser > -- "J'ai pour me guérir du jugement des autres toute la distance qui me sépare de moi." Antonin Artaud
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Ma, 25 feb 20, 19:18:10, John Hasler wrote: > Sam writes: > > I will give Testing a spin and will definitely take another look at > > the Debian derivatives. You also made me admire the Debian community, > > so that's a big plus on the > > reasons-why-I-definitely-need-to-switch-to-Debian list :) > > A couple of suggestions if you decide to use Testing or Unstable. > > Subscribe to the debian-devel list and scan the subject lines often > enough to be aware of upcoming transitions that might affect you or > kerfuffles that might make you want to delay upgrading until they are > resolved. This doesn't really take much time. > > *Don't* "track" Testing or Unstable by upgrading nightly. I don't > understand why people want to do this. A full upgrade (after a test > upgrade) about once a month is plenty. An entire month without security updates is not the best idea in my opinion. Additionally after a month the upgrade can become quite complex with a lot more moving parts, i.e. it will be difficult to tell what broke. Just don't do upgrades right before important deadlines, events, presentations, etc. Otherwise upgrading every few days up to a week ensures that your system is reasonably up to date (security) and the upgrades are not too complex. > If you have packages you need to have the current release of wait until > they've been available for a week or so without serious or important > bugs that would matter to you. Then do a test upgrade so that you can > decide whether you can go right ahead, have to do a full upgrade to make > it work, or perhaps should wait a bit. Debian testing already has checks and delays in place to filter out (most of the) problems. Updates fixing security issues are prioritised. > I've been doing this with Unstable for most of this century with very > few problems (and none recently). In both cases (testing and unstable), if the system is in any way exposed to security threats updating more often than that would be a good idea. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On 26/2/20 10:59 am, Stefan Monnier wrote: LVM snapshots I use timeshift for the same purpose; and have needed it a couple of times over 14 months since switching from mint. I look at what packages are to be upgraged, and if more than a few libraries, I create a new timeshift first. Usually adds about a minute to the upgrade. I am about to look into LVM snapshots NOW, though. -- Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Sam writes: > I will give Testing a spin and will definitely take another look at > the Debian derivatives. You also made me admire the Debian community, > so that's a big plus on the > reasons-why-I-definitely-need-to-switch-to-Debian list :) A couple of suggestions if you decide to use Testing or Unstable. Subscribe to the debian-devel list and scan the subject lines often enough to be aware of upcoming transitions that might affect you or kerfuffles that might make you want to delay upgrading until they are resolved. This doesn't really take much time. *Don't* "track" Testing or Unstable by upgrading nightly. I don't understand why people want to do this. A full upgrade (after a test upgrade) about once a month is plenty. If you have packages you need to have the current release of wait until they've been available for a week or so without serious or important bugs that would matter to you. Then do a test upgrade so that you can decide whether you can go right ahead, have to do a full upgrade to make it work, or perhaps should wait a bit. I've been doing this with Unstable for most of this century with very few problems (and none recently). And a caveat: I don't use either Gnome or KDE. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
> I would happily consider using Debian Testing for example, but wherever I see > someone asking about it I always find someone discouraging from using it due > to the possibility of having broken or unsecure packages for a long time due > to it being automated. Other tools you can use: LVM snapshots. Take a snapshot before updating to testing/unstable, so you can easily revert if you don't like the result. I've used that for my machines running stable but where some (typically hardware, usually graphics-related) bug/regression shows up. Stefan
Re: Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Thank you very much for the tips! I will give Testing a spin and will definitely take another look at the Debian derivatives. You also made me admire the Debian community, so that's a big plus on the reasons-why-I-definitely-need-to-switch-to-Debian list :) Thank you, Sam
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Peter Ehlert wrote: > I think Debian Testing would fit you very well > It is like a rock, honestly. that hasn't been my experience, but i know what i'm doing well enough to fix things or to ask for help here if i find something i don't understand well enough. i got bit by some kind of lightdm transition or update and then before when system[-x] came along i had a failure during that which was not easy enough to solve as i did not have any exposure to system[-x] to that point. as i am here now and all is working ok i'm happy. debian does rock. :) thanks to the people who volunteer and do the work and answer questions and fix bugs. :) songbird
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Roberto writes: > On strategy would be to run testing and not update too frequently. I do that with Unstable. Works fine (but I use neither Gnome nor KDE) I follow the security list and upgrade the relevant package when I see something there that matters to me. Security fixes reach Unstable as fast or faster than they reach Stable and often aren't even relevant to Unstable since it is likely to have the newest release (which is where upstream usually fixes security bugs). I also scan debian-devel to keep any eye out for problems that might be a reason *not* to upgrade. Those have been very rare in recent years. I often update packages rather than doing a full upgrade. I always do a test update or upgrade and review the proposed changes looking closely at any proposed removals. Often when Apt can't find a workable update or upgrade path Aptitude can. Might be nice if there was a Debian deriviative based on this policy. Perhaps there is. -- John Hasler jhas...@newsguy.com Elmwood, WI USA
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
I think Debian Testing would fit you very well It is like a rock, honestly. == I demand stability. My machines Must work 24/7 without intervention. for this reason I do have Debian Stable installed and operational on all machines (Mate desktop). However, on the other hand I love Mate, and the continuing new features... and we don't get them in Stable. And I am impatient and want the Latest And Greatest shiny new things in Mate!!! My solution: I keep a Debian Sid Mate (unstable) as default on on several machines, and I update daily +/- In my experience, IF there is something buggy in Sid, it gets patched withing 12 hours, maybe as long as 24. AND, I can just reboot to Stable and got to work without any issues. My Wife is kinda a "Luddite that uses computers" so she has Debian Mate Stable... and I update it for her on occasion (days, weeks sometimes) and she is happy. Happy Spouse = Happy Me. Same for the office computers: the have Only Stable installed. Mind that all of my hardware is several years old at a minimum, so having the bleeding edge gizmos is a non issue (and Mate is always in a Stable condition, that team is aces!) On 2/25/20 7:55 AM, Sam wrote: Hello, I would like to hear opinions about the release cycle of the Stable Debian releases for a Desktop user. I love the Debian ideals and perks (its social contract, independence from big companies...) and understand to a certain extent the fundamentals on why keeping "old-ish" versions of packages with backports and the Shiny new stuff syndrome, but I fail to see how Debian can make a useful desktop distribution with the current release cycle. For example: My main PC is an already two years old ryzen-based system and a Vega graphics card from 2017, and the kernel used in Stable has regressions which cause complete, unrecoverable system hangups on Vega cards which were not alleviated until kernel 5.3 onwards (and they still keep happening, though rarely!). This means that to ensure stability on a Debian installation I would need a backported kernel, or use Debian Testing or Sid, which IMO collides with the point of a Stable release. I also see everyday many announcements about performance (GNOME) and usability (KDE Plasma) improvements which are not exactly new features. This is obviously happening on more recent releases, which Debian may not see (unless these changes are also backported, which I would find extremely cumbersome?) until approximately two years have passed since that. All this makes me think that while Debian is a fantastic distribution, its Desktop, common user-facing side of things would greatly benefit from something like a separate yearly Stable release. Thanks, Sam
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Sam wrote: > Hello, > > I would like to hear opinions about the release cycle of the Stable Debian > releases for a Desktop user. > > I love the Debian ideals and perks (its social contract, independence from > big > companies...) and understand to a certain extent the fundamentals on why > keeping "old-ish" versions of packages with backports and the Shiny new stuff > syndrome, but I fail to see how Debian can make a useful desktop distribution > with the current release cycle. > > For example: My main PC is an already two years old ryzen-based system and a > Vega graphics card from 2017, and the kernel used in Stable has regressions > which cause complete, unrecoverable system hangups on Vega cards which were > not alleviated until kernel 5.3 onwards (and they still keep happening, > though > rarely!). This means that to ensure stability on a Debian installation I > would > need a backported kernel, or use Debian Testing or Sid, which IMO collides > with the point of a Stable release. > > I also see everyday many announcements about performance (GNOME) and > usability > (KDE Plasma) improvements which are not exactly new features. This is > obviously happening on more recent releases, which Debian may not see (unless > these changes are also backported, which I would find extremely cumbersome?) > until approximately two years have passed since that. > > All this makes me think that while Debian is a fantastic distribution, its > Desktop, common user-facing side of things would greatly benefit from > something like a separate yearly Stable release. for those who are willing to put some time into understanding how debian works, running debian testing and/or bits of unstable can be an acceptable risk. i do not recommend this to just anyone though as once in a while you may have something break. this is why i also have a separate stable partition for those rare times when i need it. the main issue with running from testing is that during the freeze running up to the stable release the packages allowed into testing may pause enough that you aren't being kept as current as you'd otherwise like. so during that time i might pull some things in from unstable as needed. i don't do this on many things and i'm trying to be careful about how many and what so i know what is going on. mainly i like to keep up with the most recent firefox releases. running etckeeper and git on a system can find out all sorts of interesting things. :) my other philosophical remarks would be an aside so i will leave them off. songbird
Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
I install testing on all my machines*. It is very usable. Sid has given me problems in the past, so I stay clear. *While it is true I install testing, I should clarify that I continue to use it as it moves into stable and then old-stable. Eventually, I hit some kind of "you can't get there from here" state with apt, at which point I install testing again. John Cunningham On Tue, Feb 25, 2020 at 1:06 PM Sam wrote: > Thanks for your points of view! I agree that Stable comes at a cost, and > of > course if I ever were to set up a server Debian would probably be my > choice. > > Regarding derivatives, I know about Ubuntu, Mint, etc., but I don't > exactly > like distributions tied to or ultimately dependant on commercial entities > (I > want a change of air after going through Ubuntu, openSUSE...) > > I have also seen independent Debian derivatives (MX Linux comes to mind), > but > they either used backports or the Testing distribution. > > I would happily consider using Debian Testing for example, but wherever I > see > someone asking about it I always find someone discouraging from using it > due > to the possibility of having broken or unsecure packages for a long time > due > to it being automated. Is it actually usable for a Workstation? The same > would > apply to Sid, I can no longer allow myself to fix big breakages after > broken > updates (I don't know if that really happens often in Sid) > > Thanks, > Sam > > >
Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Tue, Feb 25, 2020 at 06:48:21PM +0100, Sam wrote: > Thanks for your points of view! I agree that Stable comes at a cost, and of > course if I ever were to set up a server Debian would probably be my choice. > > Regarding derivatives, I know about Ubuntu, Mint, etc., but I don't exactly > like distributions tied to or ultimately dependant on commercial entities (I > want a change of air after going through Ubuntu, openSUSE...) > > I have also seen independent Debian derivatives (MX Linux comes to mind), but > they either used backports or the Testing distribution. > There are literally dozens (hundreds?) of Debian derivatives out there. You might find that one or another suits your needs better than the rest: https://wiki.debian.org/Derivatives/Census > I would happily consider using Debian Testing for example, but wherever I see > someone asking about it I always find someone discouraging from using it due > to the possibility of having broken or unsecure packages for a long time due > to it being automated. Is it actually usable for a Workstation? The same > would > apply to Sid, I can no longer allow myself to fix big breakages after broken > updates (I don't know if that really happens often in Sid) > On strategy would be to run testing and not update too frequently. The important thing there would be to monitor the -user and -devel mailing lists to ensure that when you do update it isn't in the middle of a known "trouble spot". The trade there is that you must invest the effort in keeping up with what is going on at a fairly low level and you won't be getting timely security support. The approach that I take is to run stable on my workstations/laptops and then use chroots, containers, and/or VMs for when I need a "newer" environment. For instance, I need to run the lintian utility on my packages before I upload them to the Debian archive. For this to be a useful check it must be performed with the latest lintian from unstable. I have an unstable chroot environment which has (among other things) lintian installed in it at the latest available version so that I have it always available when I need it. If the environment breaks because of a bad update or bug in a package or whatever, I have others that I can use instead. For containers and VMs, taking a snapshot before upgrading to allow roll-back is trivially easy. Something similar may work for you. Regards, -Roberto -- Roberto C. Sánchez
Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Thanks for your points of view! I agree that Stable comes at a cost, and of course if I ever were to set up a server Debian would probably be my choice. Regarding derivatives, I know about Ubuntu, Mint, etc., but I don't exactly like distributions tied to or ultimately dependant on commercial entities (I want a change of air after going through Ubuntu, openSUSE...) I have also seen independent Debian derivatives (MX Linux comes to mind), but they either used backports or the Testing distribution. I would happily consider using Debian Testing for example, but wherever I see someone asking about it I always find someone discouraging from using it due to the possibility of having broken or unsecure packages for a long time due to it being automated. Is it actually usable for a Workstation? The same would apply to Sid, I can no longer allow myself to fix big breakages after broken updates (I don't know if that really happens often in Sid) Thanks, Sam
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Tue, 25 Feb 2020 16:55:46 +0100 Sam wrote: > Hello, > > I would like to hear opinions about the release cycle of the Stable > Debian releases for a Desktop user. > > I love the Debian ideals and perks (its social contract, independence > from big companies...) and understand to a certain extent the > fundamentals on why keeping "old-ish" versions of packages with > backports and the Shiny new stuff syndrome, but I fail to see how > Debian can make a useful desktop distribution with the current > release cycle. > > For example: My main PC is an already two years old ryzen-based > system and a Vega graphics card from 2017, and the kernel used in > Stable has regressions which cause complete, unrecoverable system > hangups on Vega cards which were not alleviated until kernel 5.3 > onwards (and they still keep happening, though rarely!). This means > that to ensure stability on a Debian installation I would need a > backported kernel, or use Debian Testing or Sid, which IMO collides > with the point of a Stable release. > > I also see everyday many announcements about performance (GNOME) and > usability (KDE Plasma) improvements which are not exactly new > features. This is obviously happening on more recent releases, which > Debian may not see (unless these changes are also backported, which I > would find extremely cumbersome?) until approximately two years have > passed since that. > > All this makes me think that while Debian is a fantastic > distribution, its Desktop, common user-facing side of things would > greatly benefit from something like a separate yearly Stable release. > Software is always a trade-off between age and stability. If you want new software, you must accept that it will have more bugs than older software (providing it is widely used, and people report bugs). Some of these bugs will have security implications. After Debian Testing is frozen, it undergoes six months of concerted efforts to fix the bugs. But six months out of every year would mean the developers not doing all that much development. After release, only security bugs (pretty much) get fixed. Until the freeze, Testing is only about two weeks behind Unstable, so if you want the latest software, you could choose either, after the freeze, Testing will obviously fall further behind. Testing is generally a little less buggy than Unstable. I use both options: Stable for my server and netbook, Unstable for my workstation. I don't use Gnome or KDE desktops anywhere (though I use a few of their applications), I use Xfce on netbook and workstation, command line on the server. I'm really not bothered about whizzy window animations and other special effects. The applications run the same whatever the desktop, in fact a little bit quicker if you don't waste resources on visual gimmicks. Finally, the unique selling point of Debian Stable is that you can *always* do an in-place upgrade of one version to the next. That means a lot to people running servers, though they also like that their automation scripts don't break after routine upgrades. Windows hasn't done major version upgrades since Win 2000, (except the trivial 8/8a/10 upgrades) and I don't think many other Linux distributions offer it. It was originally hoped to release at one-year intervals, and the current roughly two-year interval is not set in stone, it's just the way things have worked out. It seems to be a good ratio of development time to bug-fixing time. Given a large number of new (unpaid) developers, the cycle could be faster. -- Joe
Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
On Tue, Feb 25, 2020 at 04:55:46PM +0100, Sam wrote: > Hello, > > I would like to hear opinions about the release cycle of the Stable Debian > releases for a Desktop user. > > I love the Debian ideals and perks (its social contract, independence from > big > companies...) and understand to a certain extent the fundamentals on why > keeping "old-ish" versions of packages with backports and the Shiny new stuff > syndrome, but I fail to see how Debian can make a useful desktop distribution > with the current release cycle. > Debian's stable release does make a useful desktop distribution. I use it on every single one of my laptops/desktops. That said, your definition of "useful" may differ from mine. Though, on my current "main" laptop I had to run Debian testing at first because of the hardware support I needed from the newer kernel. > For example: My main PC is an already two years old ryzen-based system and a > Vega graphics card from 2017, and the kernel used in Stable has regressions > which cause complete, unrecoverable system hangups on Vega cards which were > not alleviated until kernel 5.3 onwards (and they still keep happening, > though > rarely!). This means that to ensure stability on a Debian installation I > would > need a backported kernel, or use Debian Testing or Sid, which IMO collides > with the point of a Stable release. > > I also see everyday many announcements about performance (GNOME) and > usability > (KDE Plasma) improvements which are not exactly new features. This is > obviously happening on more recent releases, which Debian may not see (unless > these changes are also backported, which I would find extremely cumbersome?) > until approximately two years have passed since that. > > All this makes me think that while Debian is a fantastic distribution, its > Desktop, common user-facing side of things would greatly benefit from > something like a separate yearly Stable release. > I am not sure what you are getting at. Gnome and KDE are notoriously complex and extraordinarily difficult to integrate. That integration happens in unstable and testing. The fact remains that you have two basic choices. If you must have the "latest and greatest" features, hardware support, etc., then you are better off with testing/unstable. If you can do without those things or if timely security support is more important to you than those things, then you are better off with Debian stable. Also, for administrators of large collections of systems (e.g., workstations across and enterprise, data centers, server farms, etc.) too much change too often is a major pain. Those wanting more change more often can easily switch to testing and/or unstable. But if the main stable distribution changes too often, that makes it difficult for those who need a slower rate of change. By the way, there are also lots of Debian derivatives (like Linux Mint, Ubuntu, and so on) which may be more what you are looking for in terms of meeting your specific needs. Have you considered any alternatives? Regards, -Roberto -- Roberto C. Sánchez
Understanding the two-year release cycle as a desktop user (and a Debian newcomer)
Hello, I would like to hear opinions about the release cycle of the Stable Debian releases for a Desktop user. I love the Debian ideals and perks (its social contract, independence from big companies...) and understand to a certain extent the fundamentals on why keeping "old-ish" versions of packages with backports and the Shiny new stuff syndrome, but I fail to see how Debian can make a useful desktop distribution with the current release cycle. For example: My main PC is an already two years old ryzen-based system and a Vega graphics card from 2017, and the kernel used in Stable has regressions which cause complete, unrecoverable system hangups on Vega cards which were not alleviated until kernel 5.3 onwards (and they still keep happening, though rarely!). This means that to ensure stability on a Debian installation I would need a backported kernel, or use Debian Testing or Sid, which IMO collides with the point of a Stable release. I also see everyday many announcements about performance (GNOME) and usability (KDE Plasma) improvements which are not exactly new features. This is obviously happening on more recent releases, which Debian may not see (unless these changes are also backported, which I would find extremely cumbersome?) until approximately two years have passed since that. All this makes me think that while Debian is a fantastic distribution, its Desktop, common user-facing side of things would greatly benefit from something like a separate yearly Stable release. Thanks, Sam
