1. What are the sid repos?
2. How do I permanently deactivate the screensaver in AntiX 12?
3. I have an external hard drive that has an on-off switch. Is it bad to unmount by turning it off?
thanks!
brian
topic title: 3 unrelated questions (Solved)
9 posts
• Page 1 of 1
-
Posts: 107
- Joined: 10 Sep 2011
#1
Last edited by brian on 11 Jun 2012, 09:20, edited 1 time in total.
-
Posts: 3
- Joined: 08 Jun 2012
#2
1. The Sid repos are the repos of Debian Sid. The current testing release of Debian.
2. I don't actually know
3. Yes. There's a chance of data corruption. You could better unmount it by the unmount command or a graphical mount manager.
2. I don't actually know
3. Yes. There's a chance of data corruption. You could better unmount it by the unmount command or a graphical mount manager.
-
nadir
Posts 0 nadir
#3
Trying to explain the"branch"-nature of Debian one can only fail...
I searched for a good explanation in the"Debian reference" and the"Debian FAQ"
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.debian.org/doc/"
linktext was:"http://www.debian.org/doc/"
====================================
but couldn't find it ( i know it is there)
Let me try:
Debian comes in three branches:
1) stable
2)testing
3)unstable, also called sid
stable is the actual Debian version.
When upstream (the people who do write software) offer new versions, they first get into unstable.
There they stay for ten days, and if no bugs are reported, they will get moved to testing.
This means that in sid you got the newest software, but it can contain bugs. They are often get solved fast
(but they can be rather tough, including no X or GUI, failure of boot, etc).
Testing usually hasn't got really tough bugs, the really ugly ones have already been found while the package was in sid.
But it might be the bugs won't get solved as fast as in Sid (it is too difficult for me to explain, but it makes sense, because not all packages get moved from Sid to testing after ten days, there are dependencies, etc.pp. The corrected version is in Sid, but due to dependency problems it can't be moved to testing)
Debian stable only gets security upgrades, else it stays as it is.
After a certain amount of time (ca 1.5 years), testing gets"frozen". No packages from sid are getting moved into testing anymore, and the focus is on making it bug free.
Once as many bugs as possible have been removed, testing will become stable. The old stable will now be called (ta-ta:) old-stable. It will get security upgrades for a bit more of time.
Antix is, as far i can tell, usually (per default) based on testing (i am rather sure, but would not bet, i mainly use it as a live-CD).
One can always upgrade to sid.
One can run a mixed testing and sid system
One can use antiX with the Debian stable repo. (One can run Debian stable too, sure)
Usually, in my opinion, it is not a good idea to mix stable with any of the other repos.
In my opinion it is also a good idea to stick to the default way a distribution runs (antiX in this case. But i would not say it is"not-default" to run it as Sid. I say do it the way others have good experience with -for a while. Then fiddle for yourself)
In short one could say that Sid is a ten-day-buffer for testing, and that after ca. 2 years testing will become the new (actual) Debian stable.
If i will find the link later i will send it (i hope someone else will have got it).
The above is as far i understand.
I searched for a good explanation in the"Debian reference" and the"Debian FAQ"
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.debian.org/doc/"
linktext was:"http://www.debian.org/doc/"
====================================
but couldn't find it ( i know it is there)
Let me try:
Debian comes in three branches:
1) stable
2)testing
3)unstable, also called sid
stable is the actual Debian version.
When upstream (the people who do write software) offer new versions, they first get into unstable.
There they stay for ten days, and if no bugs are reported, they will get moved to testing.
This means that in sid you got the newest software, but it can contain bugs. They are often get solved fast
(but they can be rather tough, including no X or GUI, failure of boot, etc).
Testing usually hasn't got really tough bugs, the really ugly ones have already been found while the package was in sid.
But it might be the bugs won't get solved as fast as in Sid (it is too difficult for me to explain, but it makes sense, because not all packages get moved from Sid to testing after ten days, there are dependencies, etc.pp. The corrected version is in Sid, but due to dependency problems it can't be moved to testing)
Debian stable only gets security upgrades, else it stays as it is.
After a certain amount of time (ca 1.5 years), testing gets"frozen". No packages from sid are getting moved into testing anymore, and the focus is on making it bug free.
Once as many bugs as possible have been removed, testing will become stable. The old stable will now be called (ta-ta:) old-stable. It will get security upgrades for a bit more of time.
Antix is, as far i can tell, usually (per default) based on testing (i am rather sure, but would not bet, i mainly use it as a live-CD).
One can always upgrade to sid.
One can run a mixed testing and sid system
One can use antiX with the Debian stable repo. (One can run Debian stable too, sure)
Usually, in my opinion, it is not a good idea to mix stable with any of the other repos.
In my opinion it is also a good idea to stick to the default way a distribution runs (antiX in this case. But i would not say it is"not-default" to run it as Sid. I say do it the way others have good experience with -for a while. Then fiddle for yourself)
In short one could say that Sid is a ten-day-buffer for testing, and that after ca. 2 years testing will become the new (actual) Debian stable.
If i will find the link later i will send it (i hope someone else will have got it).
The above is as far i understand.
-
Posts: 1,139
- Joined: 26 Apr 2008
#4
@nadir: Your explanation, at least for simple purposes, is accurate enough to use in a general way.
To get really specific, most packages actually come into an"Incoming" repository, and from there, depending on what the packages are, they are either moved to one of two places: Experimental (most commonly used for environments, such as a new desktop environment infrastructure or possibly a large development environment that has a lot of crucial libraries that affect dependencies elsewhere. The rest of the Incoming stuff moves to Sid.
The Sid archives are also known as"Unstable", simply because the package format and the package dependencies have not been completely verified by the time they get moved into Sid. The software itself, however, has generally had some unit testing, first by the developers who wrote the software, and then by the Debian package maintainer, so Sid software generally works. The main occasion when it does not work is when there are large chains of dependencies between applications and multiple libraries.
The Testing archives nearly always work. The exceptions to that are somewhat similar to the Sid archive. When there are large chains of dependencies, typically when introducing a primary library, such as libc or glibc, or a major desktop environment, it all has to come in as one cohesive, tested unit. If it arrives in pieces, there can be temporary inconsistencies. This can happen once or twice per Debian release, usually just after a stable release is introduced and Testing goes through a major import from Sid, and occasionally just before release, when last minute bug fixes create brief, temporary package regressions. The rest of the time, Testing is a really solid place for software.
Stable is nearly always super solid. There are only a modest number of security updates, and a very small number of bug fixes that somehow managed to squeeze through the fairly rigorous testing process. That's the good part of Stable; it is truly stable! The less appealing side to enthusiasts is that the software is often dated.
What to do then? Well, there are a number of approaches that you can take. Some people use only the Stable archive repositories, and they use Stable backports to get at least a few updates to their stable system; that gets them things like new multi media programs and newer versions of browsers, and other applications that are prone to more frequent releases.
Another approach, one that requires a much deeper level of understanding, is to take advantage of the priority and pinning system that is a part of the Debian apt schema. The general idea is to give highest priority to the stable package archives, but make the Testing, Unstable (Sid), and Experimental packages available as well. You can use package hold methods, in conjunction with priority pinning to achieve your own creative combination of stable and cutting edge software. That, however, requires a veteran level of understanding and is definitely not something the average individual should tackle, certainly not on their main system until they truly know what they are doing, and even then, only when there are backups and/or other alternatives available.
Regarding xscreensaver:
Try this:
In the file /etc/default/acpi-support
Change:
Quote:
LOCK_SCREEN=true
to:
Code:
LOCK_SCREEN=false
To get really specific, most packages actually come into an"Incoming" repository, and from there, depending on what the packages are, they are either moved to one of two places: Experimental (most commonly used for environments, such as a new desktop environment infrastructure or possibly a large development environment that has a lot of crucial libraries that affect dependencies elsewhere. The rest of the Incoming stuff moves to Sid.
The Sid archives are also known as"Unstable", simply because the package format and the package dependencies have not been completely verified by the time they get moved into Sid. The software itself, however, has generally had some unit testing, first by the developers who wrote the software, and then by the Debian package maintainer, so Sid software generally works. The main occasion when it does not work is when there are large chains of dependencies between applications and multiple libraries.
The Testing archives nearly always work. The exceptions to that are somewhat similar to the Sid archive. When there are large chains of dependencies, typically when introducing a primary library, such as libc or glibc, or a major desktop environment, it all has to come in as one cohesive, tested unit. If it arrives in pieces, there can be temporary inconsistencies. This can happen once or twice per Debian release, usually just after a stable release is introduced and Testing goes through a major import from Sid, and occasionally just before release, when last minute bug fixes create brief, temporary package regressions. The rest of the time, Testing is a really solid place for software.
Stable is nearly always super solid. There are only a modest number of security updates, and a very small number of bug fixes that somehow managed to squeeze through the fairly rigorous testing process. That's the good part of Stable; it is truly stable! The less appealing side to enthusiasts is that the software is often dated.
What to do then? Well, there are a number of approaches that you can take. Some people use only the Stable archive repositories, and they use Stable backports to get at least a few updates to their stable system; that gets them things like new multi media programs and newer versions of browsers, and other applications that are prone to more frequent releases.
Another approach, one that requires a much deeper level of understanding, is to take advantage of the priority and pinning system that is a part of the Debian apt schema. The general idea is to give highest priority to the stable package archives, but make the Testing, Unstable (Sid), and Experimental packages available as well. You can use package hold methods, in conjunction with priority pinning to achieve your own creative combination of stable and cutting edge software. That, however, requires a veteran level of understanding and is definitely not something the average individual should tackle, certainly not on their main system until they truly know what they are doing, and even then, only when there are backups and/or other alternatives available.
Regarding xscreensaver:
Try this:
In the file /etc/default/acpi-support
Change:
Quote:
LOCK_SCREEN=true
to:
Code:
LOCK_SCREEN=false
-
Posts: 107
- Joined: 10 Sep 2011
#5
Hi everyone, and thanks for the input.
Brian: I can try your suggestion. But isn't"lock-screen" different from screensaver? I use lock-screen when I'm away from the PC, but I don't want the screensaver activating on its own..
brian
Brian: I can try your suggestion. But isn't"lock-screen" different from screensaver? I use lock-screen when I'm away from the PC, but I don't want the screensaver activating on its own..
brian
-
Posts: 609
- Joined: 02 Jun 2008
#6
2. do you mean when the screen turns blank after 30 min or so?
edit as root /etc/X11/xorg.conf or create one with this lines
you change the values according to the number of minutes when you want it to take effect. (0 is off)
edit as root /etc/X11/xorg.conf or create one with this lines
Code: Select all
Section"ServerFlags"
Option"DontZap""Off"
Option"AllowMouseOpenFail""true"
Option"blank time""0"
Option"standby time""0"
Option"suspend time""0"
Option"off time""0"
EndSection
-
Posts: 107
- Joined: 10 Sep 2011
#7
Question: what do the"dont zap" and"allow mouse open fail" commands do?
brian
Thanks dark-D! Works just fine!dark-D wrote:2. do you mean when the screen turns blank after 30 min or so?
edit as root /etc/X11/xorg.conf or create one with this linesyou change the values according to the number of minutes when you want it to take effect. (0 is off)Code: Select all
Section"ServerFlags" Option"DontZap""Off" Option"AllowMouseOpenFail""true" Option"blank time""0" Option"standby time""0" Option"suspend time""0" Option"off time""0" EndSection
Question: what do the"dont zap" and"allow mouse open fail" commands do?
brian
-
Posts: 609
- Joined: 02 Jun 2008
#8
allowMouseOpenFail
Allow the server to start up even if the mouse device can't be opened or initialised. This is equivalent to the AllowMouseOpenFail XF86Config(5) file option.
Ctrl+Alt+Backspace
Immediately kills the server -- no questions asked. This can be disabled with the DontZap XF86Config file option.
Allow the server to start up even if the mouse device can't be opened or initialised. This is equivalent to the AllowMouseOpenFail XF86Config(5) file option.
Ctrl+Alt+Backspace
Immediately kills the server -- no questions asked. This can be disabled with the DontZap XF86Config file option.
-
Posts: 107
- Joined: 10 Sep 2011
#9
brian
Thanks dark-D! ---Always something to learn! __{{emoticon}}__dark-D wrote:allowMouseOpenFail
Allow the server to start up even if the mouse device can't be opened or initialised. This is equivalent to the AllowMouseOpenFail XF86Config(5) file option.
Ctrl+Alt+Backspace
Immediately kills the server -- no questions asked. This can be disabled with the DontZap XF86Config file option.
brian