Difference between Testing and Sid

[Member seaken64]

I am playing with my 32-bit systems today and on this machine when I look at the inxi report I see it says

base: Debian GNU/Linux bookworm/sid

and I am wondering what that actually means for this particular system. When I installed this system I used antiX-19 and the “testing” repos. I sometimes get confused about what I am running and have mentioned that I am running a “Sid” system in the past. But my repos are the “testing” repos and not “sid”. So, I thought I am actually running Debian and antiX Testing.

So, this report confuses me somewhat. Why is it reporting that it is “bookworm/sid”?

If my repos are Testing do I automatically update to Sid when the version changes from Debian 10 to Debian 11? I’ll do some research and try to read up on this myself. But this subject of testing and sid has always confused me. Does anyone care to give me an explanation of why the inxi report says Sid but my repos are Testing?

Thanks,
Seaken64

The inxi report:

inxi -Fxzr
System:
  Kernel: 4.9.212-antix.1-486-smp i686 bits: 32 compiler: gcc v: 9.2.1 
  Desktop: IceWM 2.9.1 
  Distro: antiX-19.2.1_386-base Hannie Schaft 29 March 2020 
  base: Debian GNU/Linux bookworm/sid 
Machine:
  Type: Desktop System: Dell product: Dimension 2400 v: N/A serial: <filter> 
  Mobo: Dell model: 0C2425 v: A00 serial: <filter> BIOS: Dell v: A03 
  date: 09/19/2003 
CPU:
  Info: Single Core model: Intel Celeron bits: 32 type: MCP 
  arch: Netburst Northwood rev: 9 cache: L2: 128 KiB 
  flags: pae sse sse2 bogomips: 4785 
  Speed: 2393 MHz min/max: N/A Core speed (MHz): 1: 2393 
Graphics:
  Device-1: Intel 82845G/GL[Brookdale-G]/GE Integrated Graphics 
  vendor: Dell Dimension 2400 driver: i915 v: kernel bus-ID: 00:02.0 
  Display: x11 server: X.Org 1.20.11 driver: loaded: intel 
  unloaded: fbdev,modesetting,vesa resolution: 1024x768 
  OpenGL: renderer: Mesa DRI Intel 845G x86/MMX/SSE2 v: 1.3 Mesa 21.2.6 
  direct render: Yes 
Audio:
  Device-1: Intel 82801DB/DBL/DBM AC97 Audio vendor: Dell Dimension 2400 
  driver: snd_intel8x0 v: kernel bus-ID: 00:1f.5 
  Sound Server-1: ALSA v: k4.9.212-antix.1-486-smp running: yes 
Network:
  Device-1: Broadcom BCM4401 100Base-T vendor: Dell Dimension 2400 
  driver: b44 v: 2.0 port: edc0 bus-ID: 01:09.0 
  IF-ID-1: eth0 state: up speed: 100 Mbps duplex: full mac: <filter> 
Drives:
  Local Storage: total: 45.15 GiB used: 8.41 GiB (18.6%) 
  ID-1: /dev/sda vendor: Western Digital model: WD400EB-75CPF0 
  size: 37.27 GiB 
  ID-2: /dev/sdb vendor: Quantum model: FIREBALL CR8.4A size: 7.87 GiB 
Partition:
  ID-1: / size: 15.34 GiB used: 8.41 GiB (54.9%) fs: ext4 dev: /dev/sda6 
Swap:
  ID-1: swap-1 type: partition size: 1023 MiB used: 108 KiB (0.0%) 
  dev: /dev/sda5 
Sensors:
  Message: No sensor data found. Is lm-sensors configured? 
Repos:
  Packages: 1550 
  Active apt repos in: /etc/apt/sources.list.d/antix.list 
  1: deb http://la.mxrepo.com/antix/testing testing main nosystemd nonfree
  No active apt repos in: /etc/apt/sources.list.d/buster-backports.list 
  No active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
  Active apt repos in: /etc/apt/sources.list.d/debian.list 
  1: deb http://ftp.us.debian.org/debian/ testing main contrib non-free
  2: deb http://security.debian.org testing-security main contrib non-free
  No active apt repos in: /etc/apt/sources.list.d/onion.list 
  No active apt repos in: /etc/apt/sources.list.d/various.list 
Info:
  Processes: 127 Uptime: 1d 1h 47m Memory: 999.2 MiB used: 128.1 MiB (12.8%) 
  Init: SysVinit runlevel: 5 Compilers: gcc: 11.2.0 Shell: Bash v: 5.1.12 
  inxi: 3.3.06 

[Moderator Brian Masinick]

Helpful

Up

0

::

This is an interesting one.

To a Debian 11 distribution, or one based on Debian 11, you would be running Debian 11 Testing software.

I suspect that the ‘Debian’ version listed in your configuration is Debian 10, because that is what is specified in antiX 19.2, but since it’s the test repo of Debian 11, though it’s now the current “test” repository, to your older ‘Base’ distribution, ‘it’ thinks that’s Sid.

That’s semantics; it’s actually the CURRENT Testing repo. Bottom line: you are fine.

--
Brian Masinick

[Member seaken64]

Helpful

Up

0

::

Ok, So I am on Testing? regardless of whether it’s antiX-19 or antiX-21 I will stay with testing as a “rolling” type of system?

I was thinking of upgrading to antiX-21 but is that necessary on Testing?

Again, this is still confusing to me and I am having a hard time understanding how to utilize Testing and Sid. I THINK I want to stay with “testing” on this machine but am not sure if I need to upgrade to Bullseye or not.

Thanks Brian,
Seaken64

[Forum Admin anticapitalista]

Helpful

Up

0

::

testing is sort of rolling.

It is ‘newer’ than bullseye since bullseye is now stable ie only receives security updates.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member sybok]

Helpful

Up

0

::

Hi,

my output of ‘lsb_release -a’ reports the same mix of ‘testing/sid’ (sid = unstable) though my repositories are all set to testing (except for MS Teams corresponding to ‘stable’ I need at work).

1) Upgrading to antiX-21 [based on Debian 11/Bullseye] is not needed on (rolling) testing.
2) Somebody pointed out that disadvantage of testing is delay of security updates when compared to stable or sid.
E.g. current version of firefox-esr [78.14] is rather old but this should improve once the new one [91-based] becomes available in stable.

Comment to 1):
Reinstall using antiX-21 and setting repositories to ‘testing’ may result into slightly different system since antiX-19 and antiX-21 are different.

[Moderator Brian Masinick]

Helpful

Up

0

::

To answer your question about stability, Testing is a good compromise between ultimate stability (Debian Stable) and reasonably current software (Debian Testing).

The only time to be concerned about package stability is right near a major Debian release. In those cases I recommend waiting until about 2 weeks after a major release, then resume updates. The reason? To make sure that numerous library changes don’t break major software applications. Nothing is perfect, but following these guidelines might allow you to maintain this aging Base system for years without having to reinstall.

Of course, backup the stuff you care about.

--
Brian Masinick

[Moderator Brian Masinick]

Helpful

Up

0

::

Regarding antiX 19 vs. antiX 21, to me both of them are solid, stable solutions and I have versions of both.

I tend to add the packages I most commonly use regardless of what version of software is installed. When I add a different application, it installs whatever packages and library software it needs.

People who have really old systems may have different hardware/software requirements, so what works best for you may differ.

--
Brian Masinick

[Member seaken64]

Helpful

Up

0

::

Ok, I think I understand now that I do not need to upgrade with antiX-21 like I do with my stable antiX-19 systems. I started with stable Debian 10 and then changed the repos to Testing. Even though I started with Debian 10/Buster I am now “rolling” on to “Bookworm” by way of keeping my repos set to “testing”.

When Debian starts to move on to another version (whatever comes after Bullseye, Bookworm?) I should wait a few weeks after the release to run my usual update/upgrade routine. That keeps me on the current testing and helps avoid some potential glitches leaking in to the system from not enough testing. Is that right?

Seaken64

[Moderator Brian Masinick]

Helpful

Up

0

::

Yes, just keep updating the software as long as it allows you to do so.

I think I have done that for 3-5 years in the past.

I also had an antiX Core setup many years ago that I used between 5-10 years until I retired the hardware. (That may have been stolen hardware).

Someone broke into my house sometime around 2009 and stole the systems that were at home. Otherwise I may have been able to run them even longer.

--
Brian Masinick

[Member h2]

Helpful

Up

0

::

You don’t want to overthink this one, inxi reports the system base as bookworm/sid because the system base is bookworm/sid.

Note that ‘sid’ is the constant essentially unnamed rolling release branch of Debian, aka, unstable. What is it a rolling release of? Next stable, aka, bookworm. What is testing? Testing is the debugging/stabilization pool for next stable, aka, bookworm. Sid is always based on testing, or more accurate, testing is always based off of sid, you can’t separate the two, so Debian calls [next stable]/sid bookworm/sid.

That’s all there is to it. If you do: cat /etc/issue, you’ll see:
Debian GNU/Linux bookworm/sid

If you cat /etc/os-release you get:

PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

If you cat /etc/debian_version you get:
bookworm/sid

This is because you are in fact running the pool called bookworm/sid. Testing and Sid are members of the set of bookworm/sid, so to speak.

One of the bigger headaches I had in fact doing smxi back in the day was actually identifying a sid only version of testing/sid, that required some convoluted hacks and logic, because the two are actually almost the same, with just a few small differences in terms of how quickly they get new packages.

I also run Testing by the way, with sid repos for occasional packages, but the system is pinned to testing always. Debian does not distinguish between next stable, aka testing, and sid aks unstable in this file, it just means that you are running next stable, which is currently in testing mode, receiving its packages after validation in sid. So even if you think you aren’t using sid because you don’t have sid sources enabled, you actually are, since all the packages in testing come from sid once they pass the bug and issue validation and are moved to testing.

For example, if inxi updates in sid (which it hasn’t because I asked unit193 to hold off because there is a MASSIVE CPU upgrade being completed in pinxi at the moment, almost ready to go, a day or two away if no further bugs are found/reported), when you get that new version of inxi, you’re just going to be a few days behind sid at that point, but it’s essentially the same pool, only testing is more peaceful and stable than sid.

Arch linux by the way uses a similar but completely rolling version of this logic, since they have no ‘stable’ branch, they do have a raw branch that is essentially the same as sid when sid/testing are not frozen for next stable release, but almost all Arch users run what is the basic equivalent of Debian Testing branch, roughly speaking. Manjaro also does that, but even more so, re having stable branches and unstable branches.

This is just how rolling release works. Sid > Testing > next stable > old stable. sid/testing is one branch, basically, though you can run sid separately and skip testing, or run testing and skip sid, but the stuff is the same more or less, just a matter of slightly more stable in testing than sid.

Someone broke into my house sometime around 2009 and stole the systems that were at home. Otherwise I may have been able to run them even longer.

The machine I’m typing this on had Debian installed early 2006, 32 bit, cross graded to 64 bit some years ago, but it’s technically the same install. A few motherboards later, new cpus, hardware, drives, but the same install. That was such a time consuming process that I skipped it on my other systems when I moved them from 32 to 64 bit. That’s continuous running of testing/sid now for about 15 years.

• This reply was modified 1 year, 4 months ago by h2.
• This reply was modified 1 year, 4 months ago by h2.
• This reply was modified 1 year, 4 months ago by h2.

inxi system information script (install info) :: inxi git

[Moderator Brian Masinick]

Helpful

Up

0

::

I think that the “bug validation” phase of Sid is the only significant difference here.

With antiX and Debian right now, I’m just running Stable and adding extra repo entries for anything I want “faster” than what the usual repo provides; otherwise, stuff like Firefox Release, Firefox Beta or Firefox Nightly I grab myself, keep them in their own private directory and update them using their own update mechanisms.

I do have an instance of siduction on my newest system. It runs using Sid. As h2 says, it’s similar to Testing, minus a completed “bug validation phase. My newest system has an NVME SSD, and siduction takes advantage of its capabilities better than anything else I’ve been able to install on it. Oddly, I haven’t been able to get an antiX USB to be bootable on this hardware. I did get MX Linux going, but ONLY their version with “AHS”, “Advanced Hardware Support”. I also was able to get PCLinuxOS and Endeavour OS running on it. All of them run well once loaded, but siduction easily boots in just over 5 seconds, at least twice as fast as the others. Sidux, aptosid and siduction have always run well on my systems, but siduction on my newest system is impressive. AntiX is the impressive one on my oldest systems because it’s the only one that runs really well on them!

• This reply was modified 1 year, 4 months ago by Brian Masinick.

--
Brian Masinick

[Member seaken64]

Helpful

Up

0

::

Thank you @h2, that was enlightening. While I’m still shaky in my understanding of Testing and Sid I think I am getting closer.

I plan on keeping the install of antiX-19 at Testing on this machine. But I just installed antiX-21 on another partition and was thinking I would use Sid. But what will Sid get me that Testing doesn’t, only a little behind the “roll”? Can I learn something from Sid that I can’t learn from Testing?

Seaken64

[Moderator Brian Masinick]

Helpful

Up

0

::

Sid gets packages a little bit sooner than Testing; otherwise they are the same. The packages go to Testing as soon as they pass the bug validation.

Otherwise Testing and Sid are the same thing; Testing has just passed additional validation. Also once a release finishes development, the code in both Sid and Testing freezes until the release.

That’s why I wait to upgrade after a new release because there are a lot of packages waiting to be updated; sometimes it takes a while to get the new dependent packages in place in Sid/Testing.

--
Brian Masinick

[Member seaken64]

Helpful

Up

0

::

I think I will proceed to use Sid on this new install.

When I switched to Testing with the antiX-19 install I followed a little guide made by anticapitalista and it worked fine. Should I use that same guide for Sid?

Ahh, never mind, I found it here: https://www.antixforum.com/forums/topic/antix-19-to-sid/#post-35011

Here goes nuthin!

Seaken64

[Moderator Brian Masinick]

Helpful

Up

0

::

seaken64 wrote:

I think I will proceed to use Sid on this new install.

When I switched to Testing with the antiX-19 install I followed a little guide made by anticapitalista and it worked fine. Should I use that same guide for Sid?

Ahh, never mind, I found it here: https://www.antixforum.com/forums/topic/antix-19-to-sid/#post-35011

Here goes nuthin!

Seaken64

Good luck!

--
Brian Masinick

[Author]

Posts