On 2024-06-13 22:15:05 +0200, Javier Barroso wrote:
> Hello,
>
> El jue., 13 jun. 2024 20:48, Vincent Lefevre escribió:
>
> > On 2024-06-13 14:43:25 -0400, Greg Wooledge wrote:
> > > On Thu, Jun 13, 2024 at 07:57:59PM +0200, Vincent Lefevre wrote:
> > > > The "whois" package has "Priority:
On 2024-06-13 14:43:25 -0400, Greg Wooledge wrote:
> On Thu, Jun 13, 2024 at 07:57:59PM +0200, Vincent Lefevre wrote:
> > The "whois" package has "Priority: standard".
>
> hobbit:~$ apt-cache show whois | grep Priority
> Priority: optional
qaa:~> apt-cache show whois | grep Priority
Priority:
Hello,
El jue., 13 jun. 2024 20:48, Vincent Lefevre escribió:
> On 2024-06-13 14:43:25 -0400, Greg Wooledge wrote:
> > On Thu, Jun 13, 2024 at 07:57:59PM +0200, Vincent Lefevre wrote:
> > > The "whois" package has "Priority: standard".
> >
> > hobbit:~$ apt-cache show whois | grep Priority
> >
On Thu, Jun 13, 2024 at 07:57:59PM +0200, Vincent Lefevre wrote:
> The "whois" package has "Priority: standard".
hobbit:~$ apt-cache show whois | grep Priority
Priority: optional
On 4/8/24 16:54, Stefan Monnier wrote:
If I have a hot-pluggable device (SD card, USB drive, hot-plug SATA/SAS
drive and rack, etc.), can I put LVM on it such that when the device is
connected to a Debian system with a graphical desktop (I use Xfce) an icon
is displayed on the desktop that I can
> If I have a hot-pluggable device (SD card, USB drive, hot-plug SATA/SAS
> drive and rack, etc.), can I put LVM on it such that when the device is
> connected to a Debian system with a graphical desktop (I use Xfce) an icon
> is displayed on the desktop that I can interact with to display the
On 4/8/24 14:08, Stefan Monnier wrote:
David Christensen [2024-04-08 11:28:04] wrote:
Why LVM?
Personally, I've been using LVM everywhere I can (i.e. everywhere
except on my OpenWRT router, tho I've also used LVM there back when my
router had an HDD. I also use LVM on my 2GB USB rescue
Am 08.04.2024 um 23:08 schrieb Stefan Monnier:
> David Christensen [2024-04-08 11:28:04] wrote:
>> Why LVM?
>
> Personally, I've been using LVM everywhere I can (i.e. everywhere
> except on my OpenWRT router, tho I've also used LVM there back when my
> router had an HDD. I also use LVM on my 2GB
On Mon, Dec 18, 2023 at 09:05:22AM -0500, Stefan Monnier wrote:
> > I would imagine that it's due to the FHS (Filesystem Hierarchy Standard)
> > which defines what the various directories on a "typical Linux system" are
> > for. "man hier", for example, tells me that:
> >
> > * /var/cache - Data
> I would imagine that it's due to the FHS (Filesystem Hierarchy Standard)
> which defines what the various directories on a "typical Linux system" are
> for. "man hier", for example, tells me that:
>
> * /var/cache - Data cached for programs.
>
> * /var/lib - Variable state information for
On 16/12/2023 15:59, Stefan Monnier wrote:
AFAICT, all of `/var/lib/apt/lists` is made of files fetched from
repositories, which APT will re-fetch if missing.
So, it sounds to me like it belongs in `/var/cache/apt/lists`, really.
What am I missing? Or is it just a historical accident?
>> That was a typo. it's `/var/cache/plocate/plocate.db`, sorry.
> My plocate.db is in /var/lib/plocate/, as is bookworm's.
> Is that changing in the future?
Hmm... I could swear that I saw it in /var/cache but every machine
I look at has it in /var/lib, indeed.
[ GNU locate puts its DB in
On Sun 17 Dec 2023 at 15:33:30 (-0500), Stefan Monnier wrote:
> >> That seems similar to things like `locate` failing if you remove
> >> `/var/log/plocate/plocate.db` (until that DB is rebuilt).
> >
> > It's tricky to discern your point as /var/log/ is not involved.
>
> That was a typo. it's
>> That seems similar to things like `locate` failing if you remove
>> `/var/log/plocate/plocate.db` (until that DB is rebuilt).
>
> It's tricky to discern your point as /var/log/ is not involved.
That was a typo. it's `/var/cache/plocate/plocate.db`, sorry.
Stefan
On Sun 17 Dec 2023 at 01:06:28 (-0500), Stefan Monnier wrote:
> > Some packages will stay the same for years, but in the past week
> > I can see four occasions when changes in list contents have occurred
> > on oldstable. So there's little similarity.
>
> The question is not really whether
> Some packages will stay the same for years, but in the past week
> I can see four occasions when changes in list contents have occurred
> on oldstable. So there's little similarity.
The question is not really whether "apt/lists" is similar to
"apt/archives", but whether the content of
On Sat 16 Dec 2023 at 12:50:51 (-0500), Stefan Monnier wrote:
> David Wright [2023-12-16 11:30:01] wrote:
> > On Sat 16 Dec 2023 at 10:59:48 (-0500), Stefan Monnier wrote:
> >> AFAICT, all of `/var/lib/apt/lists` is made of files fetched from
> >> repositories, which APT will re-fetch if missing.
Max Nikulin [2023-12-17 09:10:29] wrote:
> On 16/12/2023 22:59, Stefan Monnier wrote:
>> AFAICT, all of `/var/lib/apt/lists` is made of files fetched from
>> repositories, which APT will re-fetch if missing.
>> So, it sounds to me like it belongs in `/var/cache/apt/lists`, really.
> APT running by
On 16/12/2023 22:59, Stefan Monnier wrote:
AFAICT, all of `/var/lib/apt/lists` is made of files fetched from
repositories, which APT will re-fetch if missing.
So, it sounds to me like it belongs in `/var/cache/apt/lists`, really.
APT running by a regular user is unable to write to
David Wright [2023-12-16 11:30:01] wrote:
> On Sat 16 Dec 2023 at 10:59:48 (-0500), Stefan Monnier wrote:
>> AFAICT, all of `/var/lib/apt/lists` is made of files fetched from
>> repositories, which APT will re-fetch if missing.
>> So, it sounds to me like it belongs in `/var/cache/apt/lists`,
On Sat 16 Dec 2023 at 10:59:48 (-0500), Stefan Monnier wrote:
> AFAICT, all of `/var/lib/apt/lists` is made of files fetched from
> repositories, which APT will re-fetch if missing.
> So, it sounds to me like it belongs in `/var/cache/apt/lists`, really.
> What am I missing? Or is it just a
On 12/11/23, Greg Wooledge wrote:
> 1) Many implementations of echo will interpret parts of their argument(s),
>in addition to processing options like -n. If you want to print a
>variable's contents to standard output without *any* interpretation,
>use printf.
>
> printf %s
Albretch Mueller wrote:
> echo "abc123" > file.txt
> ftype=$(file --brief file.txt)
> echo "// __ \$ftype: |${ftype}|"
> ftypelen=${#ftype}
> echo "// __ \$ftypelen: |${ftypelen}|"
>
> # removing spaces ...
> ftype2=$(echo "${ftype}" | tr --complement --squeeze-repeats
> '[A-Za-z0-9.]' '_');
>
On Mon, Dec 11, 2023 at 09:55:54AM -0500, Greg Wooledge wrote:
[...]
Greg, your analyses are always impressive. And enjoyable.
Thanks for this
cheers
--
t
signature.asc
Description: PGP signature
On Mon, Dec 11, 2023 at 02:00:49PM +, Albretch Mueller wrote:
> Ach, yes! I forgot echo by default appends a new line character at
> the end of every string it spits out. In order to suppress it you need
> to use the "n" option: "echo -n ..."
>
> _FL_TYPE=" abc á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ
On 11/12/2023 21:00, Albretch Mueller wrote:
// __ $_FL_TYPE: |abc á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere ¿ ¡
§ ASCII ä ö ü ß Ä Ö Ü Text|
// __ $_FL_TYPE:|abc_123_birdie_here_ASCII_Text|
https://pypi.org/project/Unidecode/
should be more friendly to languages other than English.
Ach, yes! I forgot echo by default appends a new line character at
the end of every string it spits out. In order to suppress it you need
to use the "n" option: "echo -n ..."
_FL_TYPE=" abc á é í ó ú ü ñ Á É Í Ó Ú Ü Ñ 123 birdiehere ¿ ¡ §
ASCII ä ö ü ß Ä Ö Ü Text"
echo "// __
On Mon, Dec 11, 2023 at 02:11:46PM +0100, to...@tuxteam.de wrote:
> On Mon, Dec 11, 2023 at 07:42:10AM -0500, Greg Wooledge wrote:
> > Looks like GNU tr in Debian 12 still doesn't handle multibyte characters
> > correctly:
> >
> > unicorn:~$ echo 'mañana' | tr ñ X
> > maXXana
>
> Hey,
On Mon, Dec 11, 2023 at 07:42:10AM -0500, Greg Wooledge wrote:
> On Mon, Dec 11, 2023 at 09:37:42AM +0100, to...@tuxteam.de wrote:
> > 2. This is tr, not regexp, so '[A-Za-z0-9.]' isn't doing what you
> >think it does. It will match '[', 'A' to 'Z', 'a' to 'z','.' and
> >']'. I guess you
On Mon, Dec 11, 2023 at 09:37:42AM +0100, to...@tuxteam.de wrote:
> 2. This is tr, not regexp, so '[A-Za-z0-9.]' isn't doing what you
>think it does. It will match '[', 'A' to 'Z', 'a' to 'z','.' and
>']'. I guess you want to say 'A-Za-z0-9.'
Well spotted.
> 3. As a convenience, tr has
On Mon, Dec 11, 2023 at 11:25:13AM +, Albretch Mueller wrote:
> In the case of: "ASCII text"
> what should come out of it is: "ASCII_text"
> not: "ASCII_text_"
> no underscore at the end. That is the question I have.
OK, here's my guess.
The lines of code that you showed us are not
On Mon, Dec 11, 2023 at 11:25:13AM +, Albretch Mueller wrote:
> "tr --complement --squeeze-repeats ..." makes sure that the replaced
> characters only appear once (that it doesn't immediately repeat). Say
> you have something like " " (two spaces) or "?$|" (three characters)
> which will be
"tr --complement --squeeze-repeats ..." makes sure that the replaced
characters only appear once (that it doesn't immediately repeat). Say
you have something like " " (two spaces) or "?$|" (three characters)
which will be replaced by just an underscore.
In the case of: "ASCII text"
what should
On Mon, Dec 11, 2023 at 08:04:06AM +, Albretch Mueller wrote:
> On 12/11/23, Greg Wooledge wrote:
> > Please tell us ...
>
> OK, here is what I did as a t-table
[...]
Your style is confusing, to say the least. Why not play with minimal
examples and work your way up from that?
> the two
On 12/11/23, Greg Wooledge wrote:
> Please tell us ...
OK, here is what I did as a t-table
echo "abc123" > file.txt # obvious text file
ftype=$(file --brief file.txt) # got its type as reported by the "file" utility
echo "// __ \$ftype: |${ftype}|"
ftypelen=${#ftype} # length of the string
On Mon, Dec 11, 2023 at 02:53:07AM +, Albretch Mueller wrote:
> echo "abc123" > file.txt
> ftype=$(file --brief file.txt)
> echo "// __ \$ftype: |${ftype}|"
> ftypelen=${#ftype}
> echo "// __ \$ftypelen: |${ftypelen}|"
>
> # removing spaces ...
> ftype2=$(echo "${ftype}" | tr --complement
On Mon 20 Nov 2023 at 11:12:03 (+0100), Vincent Lefevre wrote:
> On 2023-11-18 23:43:34 -0600, David Wright wrote:
> > On Sat 18 Nov 2023 at 23:33:59 (+0100), Vincent Lefevre wrote:
> > > On 2023-11-18 09:18:56 -0500, Greg Wooledge wrote:
> > > > The "6.1.0-" part comes from the upstream release
On 2023-11-18 23:43:34 -0600, David Wright wrote:
> On Sat 18 Nov 2023 at 23:33:59 (+0100), Vincent Lefevre wrote:
> > On 2023-11-18 09:18:56 -0500, Greg Wooledge wrote:
> > > The "6.1.0-" part comes from the upstream release series. All the
> > > kernel images containing "6.1.0-" in this section
On Sat 18 Nov 2023 at 23:24:25 (+0100), Vincent Lefevre wrote:
> On 2023-11-18 00:20:25 -0600, David Wright wrote:
> > On Fri 17 Nov 2023 at 13:30:32 (+0100), Vincent Lefevre wrote:
> > > On 2023-11-16 14:04:29 -0600, David Wright wrote:
> > > > On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent
On Sat 18 Nov 2023 at 23:33:59 (+0100), Vincent Lefevre wrote:
> On 2023-11-18 09:18:56 -0500, Greg Wooledge wrote:
> > The "6.1.0-" part comes from the upstream release series. All the
> > kernel images containing "6.1.0-" in this section should come from the
> > same upstream series (6.1.x),
On Sat 18 Nov 2023 at 15:29:51 (+0100), steve wrote:
> Le 18-11-2023, à 09:18:56 -0500, Greg Wooledge a écrit :
> > On Sat, Nov 18, 2023 at 12:24:30AM -0600, David Wright wrote:
> > > On Fri 17 Nov 2023 at 14:07:54 (+), Tixy wrote:
> > > > At time of writing, that depended on package in stable
On Tue, 14 Nov 2023, Vincent Lefevre wrote:
To my surprise, reportbug asks me to use bullseye-backports
(= oldstable-backports) on my bookworm (= stable) machine:
Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of date.
The following newer release(s) are available in
On 2023-11-18 09:18:56 -0500, Greg Wooledge wrote:
> The "6.1.0-" part comes from the upstream release series. All the
> kernel images containing "6.1.0-" in this section should come from the
> same upstream series (6.1.x), and should have basically the same feature
> set, with no major changes.
On 2023-11-18 00:20:25 -0600, David Wright wrote:
> On Fri 17 Nov 2023 at 13:30:32 (+0100), Vincent Lefevre wrote:
> > On 2023-11-16 14:04:29 -0600, David Wright wrote:
> > > On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent Lefevre wrote:
> > > > In any case, if a package is renamed (which
Thanks Greg for the precise explanation. I would suggest to put it in the
Debian Wiki for futur reference.
Le 18-11-2023, à 09:18:56 -0500, Greg Wooledge a écrit :
On Sat, Nov 18, 2023 at 12:24:30AM -0600, David Wright wrote:
On Fri 17 Nov 2023 at 14:07:54 (+), Tixy wrote:
> At time of
On Sat, Nov 18, 2023 at 12:24:30AM -0600, David Wright wrote:
> On Fri 17 Nov 2023 at 14:07:54 (+), Tixy wrote:
> > At time of writing, that depended on package in stable is called
> > 'linux-image-6.1.0-13-amd64' and the version of that package is
> > '6.1.55-1'. This is the kernel installed
On Fri 17 Nov 2023 at 14:07:54 (+), Tixy wrote:
> On Thu, 2023-11-16 at 14:04 -0600, David Wright wrote:
> > On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent Lefevre wrote:
> > > On 2023-11-15 13:54:51 -0600, David Wright wrote:
> > > > On Wed 15 Nov 2023 at 20:01:20 (+0100), Vincent Lefevre
On Fri 17 Nov 2023 at 13:30:32 (+0100), Vincent Lefevre wrote:
> On 2023-11-16 14:04:29 -0600, David Wright wrote:
> > On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent Lefevre wrote:
> > > In any case, if a package is renamed (which particularly applies to
> > > unstable, I don't know about
On Thu, 2023-11-16 at 14:04 -0600, David Wright wrote:
> On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent Lefevre wrote:
> > On 2023-11-15 13:54:51 -0600, David Wright wrote:
> > > On Wed 15 Nov 2023 at 20:01:20 (+0100), Vincent Lefevre wrote:
> > > > On 2023-11-15 18:06:45 +, Tixy wrote:
> > >
On 2023-11-16 14:04:29 -0600, David Wright wrote:
> On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent Lefevre wrote:
> > In any case, if a package is renamed (which particularly applies to
> > unstable, I don't know about backports), I would expect reportbug
> > to also consider the new name for a
On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent Lefevre wrote:
> On 2023-11-15 13:54:51 -0600, David Wright wrote:
> > On Wed 15 Nov 2023 at 20:01:20 (+0100), Vincent Lefevre wrote:
> > > On 2023-11-15 18:06:45 +, Tixy wrote:
> > > > On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
>
On 2023-11-15 13:54:51 -0600, David Wright wrote:
> On Wed 15 Nov 2023 at 20:01:20 (+0100), Vincent Lefevre wrote:
> > On 2023-11-15 18:06:45 +, Tixy wrote:
> > > On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
[...]
> > > > But the bookworm-backports kernel is even newer.
> > > > So
On 2023-11-15 13:54:51 -0600, David Wright wrote:
> On Wed 15 Nov 2023 at 20:01:20 (+0100), Vincent Lefevre wrote:
> > On 2023-11-15 18:06:45 +, Tixy wrote:
> > > On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> > > > On 2023-11-15 16:39:15 -, Curt wrote:
> > > > > On
On Wed 15 Nov 2023 at 20:01:20 (+0100), Vincent Lefevre wrote:
> On 2023-11-15 18:06:45 +, Tixy wrote:
> > On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> > > On 2023-11-15 16:39:15 -, Curt wrote:
> > > > On 2023-11-14, Vincent Lefevre wrote:
> > > > >
> > > > > The base
On 2023-11-15 18:06:45 +, Tixy wrote:
> On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> > On 2023-11-15 16:39:15 -, Curt wrote:
> > > On 2023-11-14, Vincent Lefevre wrote:
> > > >
> > > > The base number is the same, but I would have thought that this other
> > > > kernel
On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> On 2023-11-15 16:39:15 -, Curt wrote:
> > On 2023-11-14, Vincent Lefevre wrote:
> > >
> > > The base number is the same, but I would have thought that this other
> > > kernel might have additional patches.
> > >
> > > > That's why
On 2023-11-15 16:39:15 -, Curt wrote:
> On 2023-11-14, Vincent Lefevre wrote:
> >
> > The base number is the same, but I would have thought that this other
> > kernel might have additional patches.
> >
> >> That's why I suggested ignoring the message.
> >
> > Then why does reportbug mention
On 2023-11-15 08:50:50 +0100, didier gaumet wrote:
> I don't know why particularly a Bullseye-backports kernel is promoted here
> in a mixed stable/unstable context but perhaps (I have not tested it) you
> could set check-available to 0 in /etc/reportbug.conf (1) to avoid to be
> proposed a newer
On 2023-11-15 10:15:35 +0700, Max Nikulin wrote:
> On 15/11/2023 05:01, Vincent Lefevre wrote:
> > > On Tue, Nov 14, 2023 at 10:21:13PM +0100, Vincent Lefevre wrote:
> > > > # $ wget -qO-
> > > >
On 2023-11-14, Vincent Lefevre wrote:
>
> The base number is the same, but I would have thought that this other
> kernel might have additional patches.
>
>> That's why I suggested ignoring the message.
>
> Then why does reportbug mention the bullseye-backports kernel?
>
Because it kind of looks
Le 14/11/2023 à 23:01, Vincent Lefevre a écrit :
[...]
Then why does reportbug mention the bullseye-backports kernel?
[...]
Hello,
I don't know why particularly a Bullseye-backports kernel is promoted
here in a mixed stable/unstable context but perhaps (I have not tested
it) you could set
On 15/11/2023 05:01, Vincent Lefevre wrote:
On Tue, Nov 14, 2023 at 10:21:13PM +0100, Vincent Lefevre wrote:
# $ wget -qO-
'https://qa.debian.org/madison.php?package=emacs=on=oldstable,stable,testing,unstable,experimental=source,all,x86_64'
The same request without s=... returns versions
On 2023-11-14 16:34:18 -0500, Greg Wooledge wrote:
> On Tue, Nov 14, 2023 at 10:21:13PM +0100, Vincent Lefevre wrote:
> > On 2023-11-14 23:54:31 +0700, Max Nikulin wrote:
> > > On 14/11/2023 19:00, Vincent Lefevre wrote:
> > > > To my surprise, reportbug asks me to use bullseye-backports
> > > >
On Tue, Nov 14, 2023 at 10:21:13PM +0100, Vincent Lefevre wrote:
> On 2023-11-14 23:54:31 +0700, Max Nikulin wrote:
> > On 14/11/2023 19:00, Vincent Lefevre wrote:
> > > To my surprise, reportbug asks me to use bullseye-backports
> > > (= oldstable-backports) on my bookworm (= stable) machine:
> >
On 2023-11-14 23:54:31 +0700, Max Nikulin wrote:
> On 14/11/2023 19:00, Vincent Lefevre wrote:
> > To my surprise, reportbug asks me to use bullseye-backports
> > (= oldstable-backports) on my bookworm (= stable) machine:
>
> Might it happen that you have bullseye-backports in apt sources.list?
On 14/11/2023 19:00, Vincent Lefevre wrote:
To my surprise, reportbug asks me to use bullseye-backports
(= oldstable-backports) on my bookworm (= stable) machine:
Might it happen that you have bullseye-backports in apt sources.list?
apt policy
apt policy linux-image-amd64
On Tue, Nov 14, 2023 at 01:00:47PM +0100, Vincent Lefevre wrote:
> To my surprise, reportbug asks me to use bullseye-backports
> (= oldstable-backports) on my bookworm (= stable) machine:
>
> Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of
> date.
> The following newer
On Tue, Aug 15, 2023 at 05:02:49AM +, Albretch Mueller wrote:
> site="download.gluonhq.com"
> date
> time ping "${site}" -c 4
> time traceroute "${site}"
>
> $ site="download.gluonhq.com"
> date
> time ping "${site}" -c 4
> time traceroute "${site}"
> Mon 14 Aug 2023 11:54:19 PM UTC
> PING
On Fri, 2023-08-11 at 14:45 +0200, to...@tuxteam.de wrote:
> On Fri, Aug 11, 2023 at 01:30:13PM +0100,
> debian-u...@howorth.org.uk wrote:
>
> [...]
>
> > One other consideration that I haven't seen mentioned elsewhere in
> > this
> > thread is what happens if you back up filesystems to
On Fri, Aug 11, 2023 at 01:30:13PM +0100, debian-u...@howorth.org.uk wrote:
[...]
> One other consideration that I haven't seen mentioned elsewhere in this
> thread is what happens if you back up filesystems to filesystems?
I never use the backup's medium top-level dir as a target. In my
wrote:
> On Thu, Aug 10, 2023 at 03:42:01PM -0400, Default User wrote:
> > Hi!
> >
> > When backing up my system I have been using this exclusions list:
> >
> > /dev/*
> > /proc/*
> > /sys/*
> > /tmp/*
> > /run/*
> > /mnt/*
> > /media/*
> > /lost+found
> >
> > There are many sources online
On Thu, Aug 10, 2023 at 03:42:01PM -0400, Default User wrote:
> Hi!
>
> When backing up my system I have been using this exclusions list:
>
> /dev/*
> /proc/*
> /sys/*
> /tmp/*
> /run/*
> /mnt/*
> /media/*
> /lost+found
>
> There are many sources online that suggest that "/lost+found" should
On Thu, Aug 10, 2023 at 09:15:31PM -0400, Default User wrote:
> Fortunately, since my lost+found directories are all empty, I have no
> "raw material" to practice extraction on.
There's no "extraction". If a file is there, it will be a file. It
will have a meaningful owner, group and
On Thu, 2023-08-10 at 22:03 +, Minecraftchest1 wrote:
> This post on the U Stack Exchange sitr summs it up fairly well.
> https://unix.stackexchange.com/a/18157.
>
> In short, `lost+found` is a place for fscheck to link filesystem
> entries that don't have an entry anywhere on the file
On Thu 10 Aug 2023 at 15:52:02 (-0700), Bob McGowan wrote:
> On 8/10/23 03:03 PM, Nicolas George wrote:
> > Default User (12023-08-10):
> > > > > And, if /lost+found should be excluded, then shouldn't "lost+found"
> > > > > in any other directories be excluded from backups as well? Why/why
> > > >
On 8/10/23 03:03 PM, Nicolas George wrote:
Default User (12023-08-10):
And, if /lost+found should be excluded, then shouldn't "lost+found"
in any other directories be excluded from backups as well? Why/why
not?
Unfortunately, I regret to say that I did not find that the answer to
the
On Fri, Aug 11, 2023 at 12:03:26AM +0200, Nicolas George wrote:
> Default User (12023-08-10):
> > > > And, if /lost+found should be excluded, then shouldn't "lost+found"
> > > > in any other directories be excluded from backups as well? Why/why
> > > > not?
>
> > Unfortunately, I regret to say
Default User (12023-08-10):
> > > And, if /lost+found should be excluded, then shouldn't "lost+found"
> > > in any other directories be excluded from backups as well? Why/why
> > > not?
> Unfortunately, I regret to say that I did not find that the answer to
> the question(s) about lost+found in
On Thu, 2023-08-10 at 21:45 +0200, Nicolas George wrote:
> Default User (12023-08-10):
> > And, if /lost+found should be excluded, then shouldn't "lost+found"
> > in
> > any other directories be excluded from backups as well? Why/why
> > not?
>
> Before anybody answers all your question, there
Default User (12023-08-10):
> And, if /lost+found should be excluded, then shouldn't "lost+found" in
> any other directories be excluded from backups as well? Why/why not?
Before anybody answers all your question, there is something that needs
checking:
Do you know what lost+found is for?
If
Thank davidson! i've switched to bookworm. Thanks anyway!
On Mon, 7 Aug 2023 hlyg wrote:
> it used to work
>
> to make troubleshooting easy, i change to 30 from default 600
>
> xset dpms 30 30 30
>
> xset q
>
> ...
>
> Screen Saver:
> prefer blanking: yes allow exposures: yes
> timeout: 0 cycle: 600
>
> ...
>
> DPMS (Energy Star):
>
On 15/07/2023 01:32, digitalmailing wrote:
Is there a reason why GRUB_DISABLE_OS_PROBER=false
in /etc/default/grub is commented by default after
installation of bookworm or grub?
After posting some links and references to Debian bugs in
Re: os-prober Just a Rant. Fri, 26 May 2023 09:38:37
On Fri 14 Jul 2023 at 21:41:39 +0300, Teemu Likonen wrote:
> * 2023-07-14 20:32:41+0200, digitalmail...@gmx.de wrote:
>
> > Is there a reason why GRUB_DISABLE_OS_PROBER=false in
> > /etc/default/grub is commented by default after installation of
> > bookworm or grub?
>
> Yes. Release notes
Hi,
On Fri, Jul 14, 2023 at 08:32:41PM +0200, digitalmailing wrote:
> I find this very annoying and inconvenient to change
> [GRUB_DISABLE_OS_PROBER] back again after some updates.
Others have explained the "why". To stop your changes being
overwritten you can re-enable it in a .cfg file in
digitalmailing wrote:
> Is there a reason why GRUB_DISABLE_OS_PROBER=false
> in /etc/default/grub is commented by default after
> installation of bookworm or grub?
Yes. It's a new change, mentioned in the upgrade notes.
* 2023-07-14 20:32:41+0200, digitalmail...@gmx.de wrote:
> Is there a reason why GRUB_DISABLE_OS_PROBER=false in
> /etc/default/grub is commented by default after installation of
> bookworm or grub?
Yes. Release notes document tells about it briefly:
5.1.11. GRUB no longer runs os-prober by
Stefan Monnier wrote:
> > The first generation was hybrid 16/32 bit internally, and came in
> > variants selected for cost vs performance: 8, 16 or 32 bit external bus.
>
> I've never heard of a version of the 68000 with a 32bit external bus.
You're right. I was misremembering the 68012, which
On Fri, 07 Jul 2023 16:08:44 -0500
John Hasler wrote:
Hello John,
>That processor was targeted at embedded systems and it made sense in
>some applications. I don't understand why anyone would put it in a
>desktop.
Cost.
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
> Motorola's 68000 line had an internal 32 bit architecture, which made
> the CPU both performant and expensive.
Hmm... it had a (non-internal) 32bit instruction set architecture
(i.e. programmers could directly manipulate 32bit entities), but
internally it manipulated only 16bit at a time (e.g.
On Fri, 07 Jul 2023 23:10:01 +0200 John Hasler wrote:
> Bret writes:
>
>> With bits and bytes, one strange thing that I remember, is that, in
>> 1985, in Australia, a particular computer was introduced, that had a
>> 32 bit processor with 8 bit buses. It was a Motorola 68008 CPU, and,
>> I
On 7/7/23 17:24, Dan Ritter wrote:
Bret Busby wrote:
With bits and bytes, one strange thing that I remember, is that, in 1985, in
Australia, a particular computer was introduced, that had a 32 bit processor
with 8 bit buses. It was a Motorola 68008 CPU, and, I could not understand
why a
On Fri 07 Jul 2023 at 16:08:44 (-0500), John Hasler wrote:
> Bret writes:
> > With bits and bytes, one strange thing that I remember, is that, in
> > 1985, in Australia, a particular computer was introduced, that had a
> > 32 bit processor with 8 bit buses. It was a Motorola 68008 CPU, and, I
> >
* On 2023 07 Jul 12:59 -0500, to...@tuxteam.de wrote:
> There is lots of cross-pollination, though. Before the advent of Clang
> there weren't many credible alternatives to the GCC toolchain; I don't
> think any BSD sysadmin worth their salt would renounce using rsync just
> because it's GPL.
Bret Busby wrote:
>
> With bits and bytes, one strange thing that I remember, is that, in 1985, in
> Australia, a particular computer was introduced, that had a 32 bit processor
> with 8 bit buses. It was a Motorola 68008 CPU, and, I could not understand
> why a company would produce a 32 bit
Bret writes:
> With bits and bytes, one strange thing that I remember, is that, in
> 1985, in Australia, a particular computer was introduced, that had a
> 32 bit processor with 8 bit buses. It was a Motorola 68008 CPU, and, I
> could not understand why a company would produce a 32 bit CPU wit 8
>
On 8/7/23 03:30, mick.crane wrote:
On 2023-07-07 19:19, to...@tuxteam.de wrote:
Thr rest, is, as they say...
.."A thirty-two bit extension and graphical shell to a sixteen bit patch
to an eight bit operating system originally coded for a four bit
microprocessor which was written by a
On 7/7/23 13:33, Charlie Gibbs wrote:
On Fri Jul 7 09:59:56 2023 fxkl4...@protonmail.com wrote:
>> Microsoft for good or bad has made major advances in software
Yup. Like surveillance, flakiness, and an endless merry-go-round
of forced upgrades into ever-increasing bloatware.
>> and is
jeremy ardley wrote:
> On 7/7/23 19:28, debian-u...@howorth.org.uk wrote:
> >
> > That may be or not, but is irrelevant. Accurate attribution of
> > quotes is important, IMHO, and not difficult to do. So doubling
> > down on your mistake instead of a simple mea culpa means you move
> > further
On 2023-07-07 19:19, to...@tuxteam.de wrote:
Thr rest, is, as they say...
.."A thirty-two bit extension and graphical shell to a sixteen bit patch
to an eight bit operating system originally coded for a four bit
microprocessor which was written by a two-bit company that can't stand
one bit
1 - 100 of 6064 matches
Mail list logo
