Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #219430 > unrolled thread

Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)

Back to article view | Back to linux.debian.user

Contents

  Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer) Sam <debian@samueldgv.com> - 2020-02-25 19:10 +0100
    Re: Re: Understanding the two-year release cycle as a desktop user  (and a Debian newcomer) Roberto C. Sánchez <roberto@debian.org> - 2020-02-25 19:20 +0100
      Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer) John Hasler <jhasler@newsguy.com> - 2020-02-25 20:30 +0100
    Re: Re: Understanding the two-year release cycle as a desktop user  (and a Debian newcomer) John Cunningham <djohngo@gmail.com> - 2020-02-25 19:20 +0100
    Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer) Stefan Monnier <monnier@iro.umontreal.ca> - 2020-02-26 01:10 +0100
      Re: Understanding the two-year release cycle as a desktop user (and a  Debian newcomer) Keith Bainbridge <keithrbau@gmail.com> - 2020-02-26 07:10 +0100
        Re: Understanding the two-year release cycle as a desktop user (and  a Debian newcomer) Reco <recoverym4n@enotuniq.net> - 2020-02-26 14:40 +0100
        Re: Understanding the two-year release cycle as a desktop user (and a  Debian newcomer) Keith Bainbridge <keithrbau@gmail.com> - 2020-02-26 14:40 +0100
          Re: Understanding the two-year release cycle as a desktop user (and  a Debian newcomer) Charles Curley <charlescurley@charlescurley.com> - 2020-02-26 17:50 +0100
            Re: Understanding the two-year release cycle as a desktop user (and a  Debian newcomer) Keith Bainbridge <keithrbau@gmail.com> - 2020-02-26 23:20 +0100
              Re: Understanding the two-year release cycle as a desktop user (and a  Debian newcomer) Keith Bainbridge <keithrbau@gmail.com> - 2020-02-27 02:10 +0100
                Re: Understanding the two-year release cycle as a desktop user (and  a Debian newcomer) Charles Curley <charlescurley@charlescurley.com> - 2020-02-27 15:10 +0100
                  Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer) Stefan Monnier <monnier@iro.umontreal.ca> - 2020-02-27 15:40 +0100
                    Re: Understanding the two-year release cycle as a desktop user (and  a Debian newcomer) Joe <joe@jretrading.com> - 2020-02-27 16:40 +0100
              Re: Understanding the two-year release cycle as a desktop user (and  a Debian newcomer) Joe <joe@jretrading.com> - 2020-02-27 16:30 +0100
    Re: Understanding the two-year release cycle as a desktop user (and  a Debian newcomer) Didar Hossain <didar@purlo.in> - 2020-02-29 12:10 +0100

#219430 — 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

[toc] | [next] | [standalone]

#219431 — 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

[toc] | [prev] | [next] | [standalone]

#219437

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 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#219432 — Re: Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)

[Multipart message — attachments visible in raw view] — view raw

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 <debian@samueldgv.com> 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
>
>
>

[toc] | [prev] | [next] | [standalone]

#219445

> 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

[toc] | [prev] | [next] | [standalone]

#219451 — 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.3216@gmail.com
+61 (0)447 667 468

[toc] | [prev] | [next] | [standalone]

#219469 — 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

[toc] | [prev] | [next] | [standalone]

#219470 — Re: Understanding the two-year release cycle as a desktop user (and a Debian newcomer)

[Multipart message — attachments visible in raw view] — view raw

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

keithrbau@gmail.com

+61447 667 468

Sent from my Apad

On Wed., 26 Feb. 2020, 16:42 Keith Bainbridge, <keithrbau@gmail.com> 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.3216@gmail.com
> +61 (0)447 667 468
>

[toc] | [prev] | [next] | [standalone]

#219485 — 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 <keithrbau@gmail.com> 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/

[toc] | [prev] | [next] | [standalone]

#219510 — 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 <keithrbau@gmail.com> 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.3216@gmail.com
+61 (0)447 667 468

[toc] | [prev] | [next] | [standalone]

#219512 — 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.3216@gmail.com
+61 (0)447 667 468

[toc] | [prev] | [next] | [standalone]

#219548 — 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 <keithrbau@gmail.com> 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/

[toc] | [prev] | [next] | [standalone]

#219554

> 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

[toc] | [prev] | [next] | [standalone]

#219572 — 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 <monnier@iro.umontreal.ca> 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

[toc] | [prev] | [next] | [standalone]

#219570 — 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 <keithrbau@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#219644 — 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"!

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web