Re: 32 versus 64 bit reading list suggestions

[deloptes]

Andrew Cater wrote:

> 32 bit Intel/AMD will likely disappear from the kernel if it becomes too
> hard to support. I've just had a quick look at the Fit-PC site - all of
> them look to be 64 bit capable. You want something low power - 64 bit ARM?
> There does come a point when 32 bit x86 really isn't viable - that's round
> about now in my humble estimation, if it wasn't actually two years ago.
> Crucially, the boost library is hard to build - Firefox is built on 64 bit
> to work on 32 bit - and those are the obvious ones. If you want the
> distributions to spend time building on 64 bit for you to run on 32 bit
> hardware which is significantly old you do need to show a demonstrable
> need and perhaps find sponsors for a toolchain and permanent build at this
> point.

I alaready looked for a replacement. Surprisingly the devices with 3 or 4
network cards cost > 400,- US$ and consume more power. I do not see a
reason why I should throw away a device that is working and will be
working. There was nothing ARM based, I could find.
I checked yesterday - as Charles Curley said the demand is near to the base
system - no fancy browser or whatever 372 packages 279 of which are i386.
So indeed the question is about the toolchain. I have no experience in
finding sponsors or whatever. For me it will be sufficient if I could build
those packages locally. I'll put it on the list for the next year. 
Help and advise how to proceed is appreciated.

Re: how to test disk for bad sector

[David Wright]

On Sun 30 Aug 2020 at 08:02:24 (+1000), David wrote:
> On Sat, 29 Aug 2020 at 19:51, Long Wind  wrote:
> 
> > sudo smartctl -A /dev/sda1
> [...]
> > 188 Command_Timeout 0x0032 100 068 000 Old_age Always - 403733086445
> 
> That result does not look good. It should be a low number.

I wouldn't take that number at face value. First, convert it into hex
and take another look. I've seen several postings on the web with
>>> hex(4295032833)
'0x1 0001 0001' ← I added the spaces
and I have a drive with
188 Command_Timeout -O--CK   100   099   000-12885098499
>>> hex(12885098499)
'0x3 0003 0003'
and another with
188 Command_Timeout -O--CK   100   096   000-137441116198
>>> hex(137441116198)
'0x20 0021 0026'
so the OP should look at
>>> hex(403733086445)
'0x5e 005e 00ed'
and ponder what they could mean.

Moral: always see what very large numbers look like in hex.

Cheers,
David.

Re: keyboard configuration stops working

[David Wright]

On Thu 20 Aug 2020 at 09:17:08 (-0400), Henning Follmann wrote:
> 
> I have a strange one here.
> I do have in my /etc/default/keyboard this option line:
> 
> XKBOPTIONS="lv3:menu_switch,compose:ralt,terminate:ctrl_alt_bksp,ctrl:nocaps"
> 
> for some time this works fine. I am talking about the last option.
> I do not want the caps lock, so I mapped it to ctrl.
> 
> But it forgets. I cannot describe it any other way.
> Then I do a dpk-reconfigure again (say "no" when it comes to
> if I want to keep the options), go edit the /etc/default/keyboard
> to add ctrl:nocaps, and it works again. ... for a while.
> Then it doesn't. I have ABSOLUTELY no idea why.

I'm not sure why you're doing things in that order.

You should edit /etc/default/keyboard to include the options
you want (which you can't get from the questions Debian asks,
then run   dpkg-reconfigure keyboard   and say YES.
After all, if you don't want to keep them, why bother to
type them in?)

Then, it's recommended that you reboot.

Cheers,
David.

Re: Trouble with upgrading debian 7 (wheezy)

[David Wright]

On Thu 27 Aug 2020 at 19:44:56 (-0500), R. Ramesh wrote:
> I finally decided to move from debian 7 to 10. As a first step I
> wanted to upgrade to debian 8 (jesse)
> 
> I changed all ftp.us.debian.org part in /etc/apt/sources.list to
> archive.debian.org and tried aptitude update and got the following
> error
> > W: GPG error: http://archive.debian.org wheezy Release: The
> > following signatures were invalid: KEYEXPIRED 1587841717
> > KEYEXPIRED 1587841717 KEYEXPIRED 1587841717 KEYEXPIRED 1587841717
> > KEYEXPIRED 1587841717 KEYEXPIRED 1557241909 The following
> > signatures couldn't be verified because the public key is not
> > available: NO_PUBKEY 7638D0442B90D010
> > W: GPG error: http://archive.debian.org wheezy-backports Release:
> > The following signatures were invalid: KEYEXPIRED 1587841717
> > KEYEXPIRED 1587841717 KEYEXPIRED 1587841717 KEYEXPIRED 1587841717
> > KEYEXPIRED 1587841717 The following signatures couldn't be
> > verified because the public key is not available: NO_PUBKEY
> > 7638D0442B90D010
> 
> So I proceeded to update the keys. I did the following
> > sudo apt-key list | grep expired
> > pub 4096R/B98321F9 2010-08-07 [expired: 2017-08-05]
> > pub 4096R/46925553 2012-04-27 [expired: 2020-04-25]
> > pub 4096R/65FFB764 2012-05-08 [expired: 2019-05-07]
> 
> After that I did
> > foreach i (B98321F9 46925553 65FFB764)
> > apt-key adv --keyserver keys.gnupg.net --recv-keys $i
> > end
> 
> It updated the keys, but even after that I got the same error and the
> dates on the expired keys do not change anymore.
> 
> What am I missing?

AFAICT those keys look like one for squeeze and two for wheezy,
and you appear to be updating your wheezy distribution, which
I would expect that you've been keeping up to date.

You need to replace "wheezy" with "jessie" in your sources list
and then update/upgrade. I think you probably have at least
version 2014.3 of debian-archive-keyring, which has a jessie key

/etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg
---
pub rsa4096 2013-08-17 [SC] [expires: 2021-08-15]
75DD C3C4 A499 F1A1 8CB5  F3C8 CBF8 D6FD 518E 17E1
uid [ unknown] Jessie Stable Release Key 

Cheers,
David.

Re: Possible bug with my laptop built-in keyboard after update

[David Wright]

On Sat 05 Sep 2020 at 09:04:48 (+), Jose Mojada wrote:
> It is the first time that I have a problem with debian that I have not been 
> able to solve by searching for information on the web.
> 
> After the last system updates at the end of August, the built-in keyboard of 
> my laptop "Chuwi minibook" has stopped working. In the Grub menu it works 
> correctly, but once you start the system it stops works, and there is no 
> other way to get to use the PC than with a USB keyboard.

If you normally boot directly into a DM, does the keyboard work when you
boot into single-user mode? (ie could this be an X/Wayland problem?)

Cheers,
David.

Re: Help - How to paste from host (Debian) to Virtual machine (Win10)

[Kushal Kumaran]

Dennis Wicks  writes:

> Greetings!
>
> Is there any way that I can copy and paste from Deb host to VM Win10
> and vice versa?
>

Assuming you are using qemu-kvm to run your VM, the search keyword would
be SPICE.

You need to have the appropriate devices attached to the VM (a spice
channel at the minimum), and the corresponding driver software installed
in the VM.

https://www.spice-space.org/spice-user-manual.html#agent
https://www.spice-space.org/download.html#windows-binaries

-- 
regards,
kushal

Help - How to paste from host (Debian) to Virtual machine (Win10)

[Dennis Wicks]

Greetings!

Is there any way that I can copy and paste from Deb host to 
VM Win10 and vice versa?


Many TIA!
Dennis

Printed page vs. computer screen (was: Re: 32 versus 64 bit reading list suggestions)

[rhkramer]

On Monday, September 07, 2020 03:46:39 PM D. R. Evans wrote:
> Sorry; I missed that. (I find it too easy to skim instead of actually
> /read/ on a computer screen.)

That's interesting, I'll say it this way first, then elaborate a little.

I tend to skim more on the printed page than on the computer screen.  (But, 
even then, I tend to skim somewhat, especially in long texts.

The elaboration : I also tend to read too fast, not catching the exact nuance 
of some of the words used on the computer screen (and on printed pages).

The computer screen has the advantage for me of being able to adjust (usually 
increase) the font size.

Re: [1/2 résolu] Erreur d'extraction de tarball

[David Sinquin]

Bonsoir,

je reproduis aussi avec Mate. Après avoir regardé de plus près, je
reproduis aussi avec:

workdir="$(mktemp --directory)"
mkdir -p $workdir/base/directory/
touch $workdir/base/directory/empty
ln -s directory $workdir/base/link
engrampa $workdir/base/ -a $workdir/archive.tar && echo OK
# OK
tar tvf $workdir/archive.tar base/link
# hrw-r--r-- user/user   0 2020-09-07 23:26 base/link/empty
# lrwxrwxrwx user/user   0 2020-09-07 23:26 base/link -> directory
rm -rf "$workdir"

Évidemment, le fait qu'il y ait dans l'archive à la fois la cible du lien
et un lien de même nom n'est pas du tout normal et c'est ce qui cause
l'erreur à l'extraction…

Au point où j'en étais, j'ai créé un rapport de bug :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969761
en espérant que ça permette de gagner l'autre moitié de la résolution :-)

Bonne soirée,
David

Re: 32 versus 64 bit reading list suggestions

[Andy Smith]

On Mon, Sep 07, 2020 at 09:37:47PM +, Andy Smith wrote:
> Basically there are already fewer upstream kernel developers that
> care about and understand 32-bit x86, and bug and even security
> fixes specific to 32-bit x86 lag behind those for amd64. KPTI fixes
> to address Meltdown and Spectre took an extra 6 months to reach
> 32-bit x86.
> 
> https://lwn.net/Articles/743265/
> 
> https://www.phoronix.com/scan.php?page=news_item=Linux-32-Bit-KPTI-Bug-Fix

Oh, and:


https://lwn.net/ml/oss-security/calcetrw1z0gclfjz-1jwj_wct3+axxkp_wocxy8jkbslzv8...@mail.gmail.com/

"To those of you who actually support x86_32: please either
consider stopping supporting it or finding and paying someone to
give it serious upstream attention.  We need real CI resources
and we need developers to test things for real, fix what's
broken, and generally keep it up to date. And the developers in
question should have an appropriate degree of nostalgic
adoration of segments, gates, and other delights from the i386
era."

Kind of suggests to me that changes specific to x86_32 aren't being
made, and when they are being made they aren't being tested except
by users in the wild. If you never upgrade your kernel and it's in a
more secure environment (e.g. device with only one user, not exposed
to public Internet, etc.) then it's obviously less of a worry, but…

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: 32 versus 64 bit reading list suggestions

[Kenneth Parker]

On Mon, Sep 7, 2020, 3:52 PM deloptes  wrote:

> Charles Curley wrote:
>
> > I hope so. All I need is console capabilities, security software
> > (firewall, etc.) and server software. I don't need an office suite or web
> > browser for those machines.
>
> Same here. So it means we have 2-4years to get ready.
> I guess one needs a bit more in order to compile the code ... you need at
> least the compiler and companions. I now compile only the kernel in chroot
> as it was pointed out because debian moved away from pure 586 and also
> there is a kind of magic combination of features for the Geode board I use,
> so that the stock kernel never worked past 2.13.
>
> So the question is (as we are already on the topic) when debian drops the
> support, what would be required to build the code.
> Are compilers going to stop supporting 386 arch?
> Is it going to disappear from the kernel completely?
> Is it going to get fixes and how?
>

I already have one machine that runs awesomely with Ubuntu 6.06 (vintage
2006!)

I have had mixed experiences with later releases, including a persistent
Black Screen with Debian Wheezy.  Stretch "kind of works" (with slow
Graphics).  So why do I keep it?  Best Sound System of  *any*  computer I
have  *ever*  owned! So it has two, basic Partitions:  One for Stretch and
one for Ubuntu 6.  (And yes, I don't regularly put Ubuntu 6 on the open
Internet).

Kenneth Parker

>

Re: 32 versus 64 bit reading list suggestions

[Andy Smith]

Hello,

On Mon, Sep 07, 2020 at 07:57:18PM +0100, Joe wrote:
> One practical point: it isn't possible to upgrade from a 32-bit
> installation to a 64-bit one, it's a reinstall job. I did actually have
> a go once, but quickly got bogged down with 'do A before B, and do B
> before A'.

I've done it successfully more than 10 times, but:

- It isn't officially supported

- I did it on virtual machines which by their nature had fewer
  packages installed and are much simpler than the typical desktop
  or "server that does everything" in a small office.

It is not for the faint of heart and on any moderately complex
install it is faster and certainly easier to just reinstall.

Basic process:

https://wiki.debian.org/CrossGrading

Do not do this if you aren't willing to possibly render your system
unbootable requiring a lengthy repair session before you get
frustrated and just reinstall anyway.

So far in this thread people have pointed out that upstream software
vendors are increasingly moving away from 32-bit x86 for various
reasons. What hasn't been mentioned yet is that one of the upstream
projects where 32-bit support is sub-optimal and getting worse is
the Linux kernel itself.

Basically there are already fewer upstream kernel developers that
care about and understand 32-bit x86, and bug and even security
fixes specific to 32-bit x86 lag behind those for amd64. KPTI fixes
to address Meltdown and Spectre took an extra 6 months to reach
32-bit x86.

https://lwn.net/Articles/743265/

https://www.phoronix.com/scan.php?page=news_item=Linux-32-Bit-KPTI-Bug-Fix

If your hardware supports it then you are best off planning to move
to it sooner rather than later. X86_32 is already in the critical
care ward.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: 32 versus 64 bit reading list suggestions

[Richard Owlett]

On 09/07/2020 02:19 PM, Felix Miata wrote:
 
For more reading, try the author's site:

https://smxi.org/docs/inxi-installation.htm#inxi-manual-install



I browsed some random pages in smxi.org . I think a more detailed read 
is in order. I suspect the tools there will answer questions I didn't 
have the background to ask properly.



Thank you

Looking for a generic drag and drop gui for custom commands

[Christoph K.]

Dear all,

I'd like to "automate" a couple of tasks that I (until now) do on the
command line manually. Examples include splitting of video files using
ffmpeg, run backups with specific parameters, display checksums(md5), etc.

I'm tired of typing the same long commands that I often need to look up
in my wiki and just replace one or two parameters, usually just the file
names.

So I was thinking about writing an application which will do just what I
want. But then I thought: Maybe someone did that already! ;-)

So that's my question:

Is there a kind of generic drag and drop gui for custom commands?

My idea is that I'd start up the gui and select a task (e. g. split a
video file). A command line will be loaded (maybe from a config file)
with placeholders for input, output and other parameters.
I will then drag some file on the gui and the filename will be used as a
parameter, in this case as the input file.
Then I will click some run button, which executes the command.
Ideally the output and exit code will be displayed.

Any hints will be appreciated.

Thanks,
Christoph

Re: bibliothèque pdf pour php[RESOLU]

[Dethegeek]

Parfait !

Si tu as d'autres librairies dans le projet, par cohérence, tu devrais les 
"convertir" à composer. Ton projet deviendra plus simple à maintenir.

Le 7 septembre 2020 22:30:55 GMT+02:00, Jose CHARTERS  a 
écrit :
>Le 07/09/2020 à 20:54, Dethegeek a écrit :
>> Donc, pour ton projet, commence par en faire une copie, ou mieux, gère le
>> avec git, si tu maîtrises ses bases.
>>
>> Ensuite installe composer en suivant la procédure disponible sur
>> http://getcomposer.org . Personnellement je
>> l'installe dans /usr/bin . Je ne descend pas composer depuis apt car il a
>> tendance à être un peu vieux.
>>
>> Une fous fait, vérifie que tu peux l'appeler comme n'importe quelle
>> commande :
>>
>> Composer --version
>>
>> Rends toi à la racine de ton projet, et tape
>>
>> composer init
>>
>> Il te posera quelques questions notamment pour des meta données (auteur,
>> licence, ...).
>>
>> À la racine de ton projet tu auras de nouveaux fichiers :
>> composer.json
>> composer. lock
>>
>> Et un dossier vendor.
>>
>> Installe ta librairie avec
>>
>> composer require setasign/fpdi
>>
>> La commande provient de cette page : 
>> https://packagist.org/packages/setasign/fpdi
>>
>> Note : http://packagist.org est le site qui sert de "magasin" de 
>> librairies.
>>
>> Une fois que composer a résolu les dépendances de ton projet et de ta 
>> nouvelle librairie tu pourras utiliser l'autoload que composer a 
>> préparé pour accéder à toutes tes librairies.
>>
>> Cela se fait en PHP avec
>>
>> require 'vendor/autoload.PHP'
>>
>> Enfin, adapte ton projet en fonction si tu utilisais une méthode 
>> d'autoload antédiluvienne. (Comme des include ou des require en masse 
>> un peu partout)
>Bonsoir,
>
>Merci, j'ai réussi à installer cette librairie.
>
>Par contre, j'ai installer composer avec apt-get, il ne voulait pas 
>autrement.
>
>Ensuite, j'ai un peu tatonner mais cela à fini par fonctionner.
>
>Bonne soirée,
>
>José Charters
>

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: bibliothèque pdf pour php[RESOLU]

[Jose CHARTERS]

Le 07/09/2020 à 20:54, Dethegeek a écrit :

Donc, pour ton projet, commence par en faire une copie, ou mieux, gère le
avec git, si tu maîtrises ses bases.

Ensuite installe composer en suivant la procédure disponible sur
http://getcomposer.org . Personnellement je
l'installe dans /usr/bin . Je ne descend pas composer depuis apt car il a
tendance à être un peu vieux.

Une fous fait, vérifie que tu peux l'appeler comme n'importe quelle
commande :

Composer --version

Rends toi à la racine de ton projet, et tape

composer init

Il te posera quelques questions notamment pour des meta données (auteur,
licence, ...).

À la racine de ton projet tu auras de nouveaux fichiers :
composer.json
composer. lock

Et un dossier vendor.

Installe ta librairie avec

composer require setasign/fpdi

La commande provient de cette page : 
https://packagist.org/packages/setasign/fpdi


Note : http://packagist.org est le site qui sert de "magasin" de 
librairies.


Une fois que composer a résolu les dépendances de ton projet et de ta 
nouvelle librairie tu pourras utiliser l'autoload que composer a 
préparé pour accéder à toutes tes librairies.


Cela se fait en PHP avec

require 'vendor/autoload.PHP'

Enfin, adapte ton projet en fonction si tu utilisais une méthode 
d'autoload antédiluvienne. (Comme des include ou des require en masse 
un peu partout)

Bonsoir,

Merci, j'ai réussi à installer cette librairie.

Par contre, j'ai installer composer avec apt-get, il ne voulait pas 
autrement.


Ensuite, j'ai un peu tatonner mais cela à fini par fonctionner.

Bonne soirée,

José Charters

Re: 32 versus 64 bit reading list suggestions

[Richard Owlett]

On 09/07/2020 02:03 PM, David Wright wrote:

On Mon 07 Sep 2020 at 12:49:36 (-0500), Richard Owlett wrote:

On 09/07/2020 09:51 AM, Felix Miata wrote:

Richard Owlett composed on 2020-09-07 08:44 (UTC-0500):


 2.What 32 bit utilities are there to identify the hardware capabilities
   of a particular machine?


inxi

For CPU bits specifically:

inxi -Cy

For all CPU capabilities:

inxi -Cay

i>

If these produce any errors, you're using an old inxi version. Upstream version
permits self upgrading thus:

inxi -U

It's been too long since I last used Debian's inxi package, so don't remember if
it's packaged to override -U capability.


inxi -V | head -n1

inxi 3.1.06-00 (2020-08-17)


Running Debian 9.8 I get
root@defaultinstall:/home/richard# inxi -V | head -n1
inxi 2.3.5-00 (2016-12-02)

It didn't like the "a" nor "y" parameters.

I did "apt update" then "apt upgrade" and am now running Debian 9.13
  inxi -V | head -n1 re still reports inxi 2.3.5-00 (2016-12-02)


What should I read before attempting "inxi -U"?


man inxi   on your buster installation. Then forget about manually
upgrading stretch's version: you're interested in what inxi tells
you about the machine hardware.


I also have the 64 bit flavor of Debian 10 on a separate partition.
I'll run them there and see what I'll get.

As time is available I'll attempt to install also the 32 bit Debian 10.


Perfect for the comparison you want.


I just did a net install of i386 Debian 10. A couple of things that run 
under i386 Debian 9 AND amd64 Debian 10 don't work right under i386 
Debian 10.


I've some trouble shooting to do. Suspect operator error of some sort.





For a more general display of hardware configuration:

inxi -by

And with more detail:

inxi -bay

The -y switch produces a format resulting in more lines and shorter line length,
so isn't needed, and isn't available in old inxi versions.


Cheers,
David.

Re: 32 versus 64 bit reading list suggestions

[Richard Owlett]

On 09/07/2020 01:57 PM, Joe wrote:

On Mon, 7 Sep 2020 10:12:11 -0500
Richard Owlett  wrote:




Answers I'm seem focused on too low levels. I'm interested in the
end-user experience.



One practical point: it isn't possible to upgrade from a 32-bit
installation to a 64-bit one, it's a reinstall job. I did actually have
a go once, but quickly got bogged down with 'do A before B, and do B
before A'.



For miscellaneous personal reasons I always do a full install when 
moving to a new version. Essentially it means I have a known fully 
functional install on its own partition to fall back on. /home is on a 
separate partition available to any release.

Re: 32 versus 64 bit reading list suggestions

[Andrew Cater]

32 bit Intel/AMD will likely disappear from the kernel if it becomes too
hard to support. I've just had a quick look at the Fit-PC site - all of
them look to be 64 bit capable. You want something low power - 64 bit ARM?
There does come a point when 32 bit x86 really isn't viable - that's round
about now in my humble estimation, if it wasn't actually two years ago.
Crucially, the boost library is hard to build - Firefox is built on 64 bit
to work on 32 bit - and those are the obvious ones. If you want the
distributions to spend time building on 64 bit for you to run on 32 bit
hardware which is significantly old you do need to show a demonstrable need
and perhaps find sponsors for a toolchain and permanent build at this point.

On Mon, Sep 7, 2020 at 7:52 PM deloptes  wrote:

> Charles Curley wrote:
>
> > I hope so. All I need is console capabilities, security software
> > (firewall, etc.) and server software. I don't need an office suite or web
> > browser for those machines.
>
> Same here. So it means we have 2-4years to get ready.
> I guess one needs a bit more in order to compile the code ... you need at
> least the compiler and companions. I now compile only the kernel in chroot
> as it was pointed out because debian moved away from pure 586 and also
> there is a kind of magic combination of features for the Geode board I use,
> so that the stock kernel never worked past 2.13.
>
> So the question is (as we are already on the topic) when debian drops the
> support, what would be required to build the code.
> Are compilers going to stop supporting 386 arch?
> Is it going to disappear from the kernel completely?
> Is it going to get fixes and how?
>
>
>
>
>
>

Re: 32 versus 64 bit reading list suggestions

[deloptes]

Charles Curley wrote:

> I hope so. All I need is console capabilities, security software
> (firewall, etc.) and server software. I don't need an office suite or web
> browser for those machines.

Same here. So it means we have 2-4years to get ready. 
I guess one needs a bit more in order to compile the code ... you need at
least the compiler and companions. I now compile only the kernel in chroot
as it was pointed out because debian moved away from pure 586 and also
there is a kind of magic combination of features for the Geode board I use,
so that the stock kernel never worked past 2.13.

So the question is (as we are already on the topic) when debian drops the
support, what would be required to build the code.
Are compilers going to stop supporting 386 arch?
Is it going to disappear from the kernel completely?
Is it going to get fixes and how?

Re: 32 versus 64 bit reading list suggestions

[D. R. Evans]

David Wright wrote on 9/7/20 12:53 PM:

> 
> That may be an unfair comparison as the OP has a 64-bit machine
> running the 32-bit software, rather than two machines of different
> generations.
> 

Sorry; I missed that. (I find it too easy to skim instead of actually /read/
on a computer screen.)

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

[1/2 résolu] Erreur d'extraction de tarball

[Olivier Humbert]

Le 2020-09-07 07:45, Fabien Roucaute a écrit :


Ça me fait plutôt penser à une erreur matérielle (type mémoire),
avez-vous modifié la fréquence de la RAM ?
Je demande car quand je faisais de l'overclocking dans ma jeunesse,
c'était le type d'erreur que j'avais quand je poussais la fréquence de
la mémoire trop haut.
À votre place que commencerais par vérifier l'intégrité de l'archive
avec "xz -t fogpad-port.tar.xz" et si l'extraction en ligne de commande
donne la même erreur apparaît, puis je testerais la mémoire avec 
"memtest".


Merci pour cette réponse Fabien.

Malheureusement (ou plutôt, heureusement pour mon budget !), ça n'est 
pas un problème de RAM corrompue car :
1. c'est reproductible tout le temps avec **certains** dossier que je 
fais moi même et pas d'autres

2. c'est reproductible sur d'autres machines

En fait, ça semble être un soucis lié à MATE car :
- un copain utilisant le même système que moi avec MATE a le même soucis
- un copain utilisant le même système que moi avec KDE n'a pas le même 
soucis





Basile a écrit :


Pourquoi n'utilisez vous pas la ligne de commande

tar xvf ficher.tar.xz


Merci pour cette piste de contournement. En utilisant la commande
 tar -cJvf archive.tar.xz mondossier/
alors ça fonctionne comme attendu et je peux extraire le fichier sans 
avoir de soucis.




Je mets un [1/2 résolu] dans l'objet.

Est-ce que quelqu'un aurait une idée de ce qui se passe pour moi ?
Une histoire de mauvaise gestion par Engrampa ?

Olivier


--
Site web : https://librazik.tuxfamily.org/
Donation : https://liberapay.com/LibraZiK/
Diaspora : 
https://framasphere.org/people/8c184af0c9450134f6682a053625

Mastodon : https://mastodon.xyz/@LibraZiK

Re: 32 versus 64 bit reading list suggestions

[Charles Curley]

On Mon, 07 Sep 2020 19:50:16 +0200
deloptes  wrote:

> > There are
> > already problems with some software that just won't build well in a
> > 32 bit environment.  
> 
> this would be unfortunate because I am sure there is enough 32bit
> hardware out there still working quite well - like mine Geode based
> firewall - it is running since 2008.

Hear, hear. I have a small herd of Fit-PC Is, which have been doing
yeoman duty as firewalls, servers, etc. I don't recall when I bought
them, but the release date on the BIOS is 2007.

They draw less than four watts each, except 5 watts when the hard drive
is spinning up. Has anyone got a 64 bit architecture machine
that frugal?


>
> I am sure even if debian drops the support of 32bit something else
> will take it over.

I hope so. All I need is console capabilities, security software
(firewall, etc.) and server software. I don't need an office suite or web 
browser for those machines.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: 32 versus 64 bit reading list suggestions

[Felix Miata]

David Wright composed on 2020-09-07 14:03 (UTC-0500):

> On Mon 07 Sep 2020 at 12:49:36 (-0500), Richard Owlett wrote:

>> What should I read before attempting "inxi -U"?

> man inxi   on your buster installation. Then forget about manually
> upgrading stretch's version: you're interested in what inxi tells
> you about the machine hardware.

If multibooting, better to put it where the inxi author suggests instead of 
using
a distro's version, as long as the various installations share that location. 
It's
merely a script, can go anywhere you please, in $PATH if you want, elsewhere if
you don't mind executing it via fullpathname.

>> I also have the 64 bit flavor of Debian 10 on a separate partition.
>> I'll run them there and see what I'll get.

>> As time is available I'll attempt to install also the 32 bit Debian 10.

> Perfect for the comparison you want.

+1

For more reading, try the author's site:
https://smxi.org/docs/inxi-installation.htm#inxi-manual-install
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Erreur d'extraction de tarball

[Fabrice BAUZAC-STEHLY]

Bonsoir,

Olivier Humbert writes:

> J'ai parfois un soucis d'extraction de paquet tar.xz.
>
> Pour reproduire :
> 1. dans le répertoire ~/Bureau/, j'effectue la commande suivante : git
> clone --recursive https://github.com/linuxmao-org/fogpad-port.git
> 2. ensuite, je clic-droit sur le dossier fogpad-port/ ->
> Compresser... -> fogpad-port.tar.xz
> 3. ensuite, je supprime le dossier fogpad-port/
> 4. maintenant, si j'essaie d'extraire le tarball ainsi compressé avec
> un clic-droit sur le fichier fogpad-port.tar.xz -> extraire ici,
> j'obtiens alors une fenêtre (voir
> https://pix.toile-libre.org/upload/original/1599437136.png ) qui
> apparaît et dont le message complet est :
> tar: fogpad-port/plugins/Fogpad/sources : open impossible: Le
> fichier existe
> tar: Arrêt avec code d'échec à cause des erreurs précédentes
> L'extraction s'arrête alors, et aucun fichier n'est extrait.
>
> Ça fait plusieurs fois que ceci m'arrive, et je ne parviens pas à
> résoudre le problème.
>
> Notes :
> - ceci se produit avec les extensions tar.bz2, tar.gz, tar.xz
> - ceci ne se produit pas avec les extensions a, ear, jar, tar,
> tar.lzma, tar.7z, war
> - plantage (sans raison donnée) avec les extensions 7z, cbz, exe, zip

Je ne reproduis pas l'erreur avec le gestionnaire de fichiers standard
de GNOME.

Essaie de verifier l'archive en ligne de commande:

tar -tf ~/Bureau/fogpad-port.tar.xz

La commande indique-t-elle une erreur?

Peux-tu m'envoyer (a mon adresse seulement, pour eviter de spammer la
mailing-list) le fichier afin que je regarde de mon cote?

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Re: 32 versus 64 bit reading list suggestions

[David Wright]

On Mon 07 Sep 2020 at 12:49:36 (-0500), Richard Owlett wrote:
> On 09/07/2020 09:51 AM, Felix Miata wrote:
> > Richard Owlett composed on 2020-09-07 08:44 (UTC-0500):
> > 
> > > 2.What 32 bit utilities are there to identify the hardware 
> > > capabilities
> > >   of a particular machine?
> > 
> > inxi
> > 
> > For CPU bits specifically:
> > 
> > inxi -Cy
> > 
> > For all CPU capabilities:
> > 
> > inxi -Cay
> i>
> > If these produce any errors, you're using an old inxi version. Upstream 
> > version
> > permits self upgrading thus:
> > 
> > inxi -U
> > 
> > It's been too long since I last used Debian's inxi package, so don't 
> > remember if
> > it's packaged to override -U capability.
> > 
> > > inxi -V | head -n1
> > inxi 3.1.06-00 (2020-08-17)
> 
> Running Debian 9.8 I get
> root@defaultinstall:/home/richard# inxi -V | head -n1
> inxi 2.3.5-00 (2016-12-02)
> 
> It didn't like the "a" nor "y" parameters.
> 
> I did "apt update" then "apt upgrade" and am now running Debian 9.13
>  inxi -V | head -n1 re still reports inxi 2.3.5-00 (2016-12-02)
> 
> 
> What should I read before attempting "inxi -U"?

man inxi   on your buster installation. Then forget about manually
upgrading stretch's version: you're interested in what inxi tells
you about the machine hardware.

> I also have the 64 bit flavor of Debian 10 on a separate partition.
> I'll run them there and see what I'll get.
> 
> As time is available I'll attempt to install also the 32 bit Debian 10.

Perfect for the comparison you want.

> > For a more general display of hardware configuration:
> > 
> > inxi -by
> > 
> > And with more detail:
> > 
> > inxi -bay
> > 
> > The -y switch produces a format resulting in more lines and shorter line 
> > length,
> > so isn't needed, and isn't available in old inxi versions.

Cheers,
David.

Re: 32 versus 64 bit reading list suggestions

[Joe]

On Mon, 7 Sep 2020 10:12:11 -0500
Richard Owlett  wrote:

>
> 
> Answers I'm seem focused on too low levels. I'm interested in the 
> end-user experience.
> 

One practical point: it isn't possible to upgrade from a 32-bit
installation to a 64-bit one, it's a reinstall job. I did actually have
a go once, but quickly got bogged down with 'do A before B, and do B
before A'.

-- 
Joe

Re: bibliothèque pdf pour php

[Dethegeek]

Bonsoir

Composer est un outil devenu incontournable pour un projet PHP un minimum 
moderne. Force est de constater qu'il rend bien service.

En gros, beaucoup de langages de programmation ont fini par avoir au moins 
un gestionnaire de paquet. Pour faire court, debian a apt, JavaScript a npm 
ou yarn, PHP a composer. J'ai mentionné apt car ça répond grosso modo au 
même besoin.

Donc, pour ton projet, commence par en faire une copie, ou mieux, gère le 
avec git, si tu maîtrises ses bases.

Ensuite installe composer en suivant la procédure disponible sur 
http://getcomposer.org . Personnellement je 
l'installe dans /usr/bin . Je ne descend pas composer depuis apt car il a 
tendance à être un peu vieux.

Une fous fait, vérifie que tu peux l'appeler comme n'importe quelle 
commande : 

Composer --version

Rends toi à la racine de ton projet, et tape

composer init

Il te posera quelques questions notamment pour des meta données (auteur, 
licence, ...).

À la racine de ton projet tu auras de nouveaux fichiers :
composer.json
composer. lock

Et un dossier vendor.

Installe ta librairie avec 

composer require setasign/fpdi

La commande provient de cette page : 
https://packagist.org/packages/setasign/fpdi

Note : http://packagist.org est le site qui sert de "magasin" de librairies. 

Une fois que composer a résolu les dépendances de ton projet et de ta nouvelle 
librairie tu pourras utiliser l'autoload que composer a préparé pour accéder à 
toutes tes librairies.

Cela se fait en PHP avec

require 'vendor/autoload.PHP'

Enfin, adapte ton projet en fonction si tu utilisais une méthode d'autoload 
antédiluvienne. (Comme des include ou des require en masse un peu partout)

N'hésite pas à demander si quelque chose n'est pas assez clair.

Le 7 septembre 2020 19:52:27 GMT+02:00, Jose CHARTERS  a 
écrit :
>Le 07/09/2020 à 05:36, Dethegeek a écrit :
>> Apparemment ta librairie est utilisable avec le gestionnaire de 
>> paquets composer et est compatible PHP 7
>>
>> https://packagist.org/packages/setasign/fpdi
>>
>> Basculer vers composer me semble un meilleur choix que s'appuyer sur 
>> des paquets de l'OS, tant que ton projet n'a pas vocation à être 
>> distribué comme paquet debian.
>
>Bonsoir,
>
>J'ai bien vu cette possibilité, mais je n'ai pas compris en quoi cela 
>consiste.
>
>Je vois bien l'utilisation mais je ne vois pas l'installation. J'ai dû 
>loupé quelque chose ou je n'ai rien compris.
>
>Cordialement,
>
>José Charters
>

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: 32 versus 64 bit reading list suggestions

[David Wright]

On Mon 07 Sep 2020 at 09:33:15 (-0600), D. R. Evans wrote:
> Richard Owlett wrote on 9/7/20 9:12 AM:
> > 
> > Answers I'm seem focused on too low levels. I'm interested in the 
> > end-user experience.
> > 
> > E.G. what end user observable difference would there be between 32 bit 
> > based browser and a 64 bit based browser?

As your bandwidth considerations seem to have taken a back seat (with
at least stretch, plus buster in two architectures), you'll be able
to form your own judgment in buster. You've brought up browsers,
and that's one area where the speed will show, because they're
highly interactive. Hopefully, you're not short on installed memory.

> The short version:
>   what Reco said.
> 
> The longer version:
> 
> 64-bit will be faster... not because 64-bit is intrinsically faster (although,
> depending on the optimisation settings in the compilation, it almost certainly
> will be faster, as has been pointed out, because of the additional CPU
> instructions available on 64-bit machines), but basically because the 64-bit
> CPU is likely to be newer and run at a higher clock rate, and hence faster for
> that reason alone.
> 
> I recently retired a debian stable 32-bit machine in favour of a debian stable
> 64-bit machine. All ordinary pre-built officially supported programs simply
> worked exactly the same (but /far/ faster: for example, a 10-minute code
> compile became less than 20 seconds).

That may be an unfair comparison as the OP has a 64-bit machine
running the 32-bit software, rather than two machines of different
generations.

> [I did have trouble with low-level sound in my own code, but that was entirely
> related to the fact that the sound hardware on the new machine supported only
> CD-quality sound, and it took quite a bit of digging, learning and a lot of
> print statements finally to get it to do what happened naturally on the old
> 32-bit machine when I needed low-quality sampling.]
> 
> The biggest reason to switch, if everything runs sufficiently quickly on the
> 32-bit machine, is probably that at some point 32 bits will stop being
> supported (I vaguely seem to remember that the decision to do that has already
> been taken by the debian project once, but was revoked).

If there's a bullseye LTS, then that deadline might be several years
away yet.

Cheers,
David.

Re: 32 versus 64 bit reading list suggestions

[deloptes]

Andrew Cater wrote:

> In reality - there's very little hardware newer than ten years old that's
> economic to run - x86_6r4 has been around for long enough that 64 bit
> hardware is cheap. The overhead of compiling _pure_ 32 bit is significant
> to keep going. It's not for nothing that Debian's 32 bit target has
> gradually moved from 386 to 586 to 686 - an early Geode is probably at the
> very end of its support lifestyle. pretty much everything else other than
> Debian has dropped full 32 bit support. It will be there for Bullseye but
> that will almost certainly be the last.
> 
> Ubuntu has already dropped 32 bit support once, reintroduced very limited
> support and it will probably go again. Maybe not before time - the laptop
> I'm typing this on is eight years old or so, the sort of thing you'd pull
> from a junk pile, has been rescued by adding a cheap SSD and ran 32 bit
> Windows originally. It's equivalent can probaby be picked up off the back
> shelf in any computer recycling shop.

Not good news from you - the hardware is good it consumes ~10Watt and works
perfectly. It might be I setup a local repository. The packages I use are
not hard to compile.
I understand the explanation, but this is industry grade hardware - I doubt
that it will break in the next 10y. As for productivity I do not see what
more I could want to have.
I looked recently for replacement, but newer hardware costs too much and
consumes slightly more power. OF course it's productivity might be much
higher, but it would be an overhead in the case here.

Thank you for the information anyway. It is very appreciated.

regards

Re: 32 versus 64 bit reading list suggestions

[Andrew Cater]

In reality - there's very little hardware newer than ten years old that's
economic to run - x86_6r4 has been around for long enough that 64 bit
hardware is cheap. The overhead of compiling _pure_ 32 bit is significant
to keep going. It's not for nothing that Debian's 32 bit target has
gradually moved from 386 to 586 to 686 - an early Geode is probably at the
very end of its support lifestyle. pretty much everything else other than
Debian has dropped full 32 bit support. It will be there for Bullseye but
that will almost certainly be the last.

Ubuntu has already dropped 32 bit support once, reintroduced very limited
support and it will probably go again. Maybe not before time - the laptop
I'm typing this on is eight years old or so, the sort of thing you'd pull
from a junk pile, has been rescued by adding a cheap SSD and ran 32 bit
Windows originally. It's equivalent can probaby be picked up off the back
shelf in any computer recycling shop.

On Mon, Sep 7, 2020 at 5:50 PM deloptes  wrote:

> Andrew Cater wrote:
>
> > Potentially zero difference - until the 32 bit browser just isn't there
> > any more / isn't patched. This is the sort of question that the debian-cd
> > team are also pondering: as the years go on, it is harder and harder to
> > justify 32 bit software at least for the x86 architecture. There are
> > already problems with some software that just won't build well in a 32
> bit
> > environment.
>
> this would be unfortunate because I am sure there is enough 32bit hardware
> out there still working quite well - like mine Geode based firewall - it is
> running since 2008.
> I am sure even if debian drops the support of 32bit something else will
> take
> it over.
>
>

Re: bibliothèque pdf pour php

[Jose CHARTERS]

Le 07/09/2020 à 05:36, Dethegeek a écrit :
Apparemment ta librairie est utilisable avec le gestionnaire de 
paquets composer et est compatible PHP 7


https://packagist.org/packages/setasign/fpdi

Basculer vers composer me semble un meilleur choix que s'appuyer sur 
des paquets de l'OS, tant que ton projet n'a pas vocation à être 
distribué comme paquet debian.


Bonsoir,

J'ai bien vu cette possibilité, mais je n'ai pas compris en quoi cela 
consiste.


Je vois bien l'utilisation mais je ne vois pas l'installation. J'ai dû 
loupé quelque chose ou je n'ai rien compris.


Cordialement,

José Charters

Re: 32 versus 64 bit reading list suggestions

[deloptes]

Andrew Cater wrote:

> Potentially zero difference - until the 32 bit browser just isn't there
> any more / isn't patched. This is the sort of question that the debian-cd
> team are also pondering: as the years go on, it is harder and harder to
> justify 32 bit software at least for the x86 architecture. There are
> already problems with some software that just won't build well in a 32 bit
> environment.

this would be unfortunate because I am sure there is enough 32bit hardware
out there still working quite well - like mine Geode based firewall - it is
running since 2008.
I am sure even if debian drops the support of 32bit something else will take
it over.

Re: 32 versus 64 bit reading list suggestions

[Richard Owlett]

On 09/07/2020 09:51 AM, Felix Miata wrote:

Richard Owlett composed on 2020-09-07 08:44 (UTC-0500):


2.What 32 bit utilities are there to identify the hardware capabilities
  of a particular machine?


inxi

For CPU bits specifically:

inxi -Cy

For all CPU capabilities:

inxi -Cay

i>

If these produce any errors, you're using an old inxi version. Upstream version
permits self upgrading thus:

inxi -U

It's been too long since I last used Debian's inxi package, so don't remember if
it's packaged to override -U capability.


inxi -V | head -n1

inxi 3.1.06-00 (2020-08-17)


Running Debian 9.8 I get
root@defaultinstall:/home/richard# inxi -V | head -n1
inxi 2.3.5-00 (2016-12-02)

It didn't like the "a" nor "y" parameters.

I did "apt update" then "apt upgrade" and am now running Debian 9.13
 inxi -V | head -n1 re still reports inxi 2.3.5-00 (2016-12-02)


What should I read before attempting "inxi -U"?

I also have the 64 bit flavor of Debian 10 on a separate partition. I'll 
run them there and see what I'll get.


As time is available I'll attempt to install also the 32 bit Debian 10.

More later.
Thanks








For a more general display of hardware configuration:

inxi -by

And with more detail:

inxi -bay

The -y switch produces a format resulting in more lines and shorter line length,
so isn't needed, and isn't available in old inxi versions.

Re: bibliothèque pdf pour php

[Jose CHARTERS]

Le 06/09/2020 à 23:22, ajh-valmer a écrit :

Tu es bien sous php5 ?

Il semble que Debian 9 = php5 et Debian 10 = php7.

Il n'y aurait pas un conflit entre les 2 versions de php ?
(donc de librairies php pas installables suivant la version de php
installée ?)


Bonsoir,

Je suis sous php7. Debian 9 est déjà avec php7 et ne contient plus le 
paquet php5. D'où le problème.


Cordialement,

José Charters

Nuevo curso disponible

[Galvatorix Torixgalva]

Hola,

queria decir que ya esta disponible un nuevo curso:   "Aprende a crear una
página web desde cero usando Joomla 3 en Debian 10"

https://www.tutellus.com/tecnologia/desarrollo-web/aprende-a-crear-una-pagina-web-desde-cero-usando-joomla-3-en-debian-10-30977

En dicho curso se aprende la instalacion del sistema operativo, la
gestionar el contenido de la web, la estructura de la web, temas de
administracion y temas de seguridad.

Posteriormente se creara la web desde cero, paso a paso. Veremos como
llevar a la practica la teoria.

Tambien veremos las distintas caracteristicas de un hosting, para saber que
nos estan ofreciendo cuando queremos contratar uno.

Espero que os guste.

Un saludo

-- 
Profesor de informática en Tutellus

Tutellus https://www.tutellus.com/perfil/230494/rafael-navarro



Libre
de virus. www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: booting details

[Thomas Pircher]

anthony gennard wrote:
> Is it possible to download an exact replica of the booting process which I
> see hurrying too fast to read it (at least it is for my tired eyes).

If you are using systemd and journald (I believe that is the default in
jessie), then you could also try

sudo journalctl -b0

Thomas

Re: 32 versus 64 bit reading list suggestions

[Richard Owlett]

On 09/07/2020 10:09 AM, Reco wrote:

Hi.

On Mon, Sep 07, 2020 at 10:01:42AM -0500, Richard Owlett wrote:

2.What 32 bit utilities are there to identify the hardware capabilities of 
a particular machine?


If you mean, "how do I check if my Intel/AMD CPU has that 64-bit
capability", then it's:

lscpu | grep -w lm


Will have to look up what each of the flags mean. That accomplish much
of what I wanted to accomplish what a "reading list" would have.


lm means "Long Mode", i.e. 64-bit support.
For the others, [1] is your best reference, table 2-27.

Reco

[1] https://software.intel.com/file/36945



I've downloaded it. Reading the per section overviews may the most 
relevant to why I titled thread as I did. Thanks.

Re: booting details

[Dan Ritter]

anthony gennard wrote: 
> Is it possible to download an exact replica of the booting process which I
> see hurrying too fast to read it (at least it is for my tired eyes). I am
> trying to get up to date with this aspect of debian. On this machine I have
> Jessie installed.

Look in /var/log/boot.log ; if it doesn't exist, install bootlogd and
reboot.

-dsr-

Re: 32 versus 64 bit reading list suggestions

[D. R. Evans]

Richard Owlett wrote on 9/7/20 9:12 AM:

>>
> 
> Answers I'm seem focused on too low levels. I'm interested in the 
> end-user experience.
> 
> E.G. what end user observable difference would there be between 32 bit 
> based browser and a 64 bit based browser?
> 

The short version:
  what Reco said.

The longer version:

64-bit will be faster... not because 64-bit is intrinsically faster (although,
depending on the optimisation settings in the compilation, it almost certainly
will be faster, as has been pointed out, because of the additional CPU
instructions available on 64-bit machines), but basically because the 64-bit
CPU is likely to be newer and run at a higher clock rate, and hence faster for
that reason alone.

I recently retired a debian stable 32-bit machine in favour of a debian stable
64-bit machine. All ordinary pre-built officially supported programs simply
worked exactly the same (but /far/ faster: for example, a 10-minute code
compile became less than 20 seconds).

[I did have trouble with low-level sound in my own code, but that was entirely
related to the fact that the sound hardware on the new machine supported only
CD-quality sound, and it took quite a bit of digging, learning and a lot of
print statements finally to get it to do what happened naturally on the old
32-bit machine when I needed low-quality sampling.]

The biggest reason to switch, if everything runs sufficiently quickly on the
32-bit machine, is probably that at some point 32 bits will stop being
supported (I vaguely seem to remember that the decision to do that has already
been taken by the debian project once, but was revoked).

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

Re: 32 versus 64 bit reading list suggestions

[Andrew Cater]

Hi Richard,

Potentially zero difference - until the 32 bit browser just isn't there any
more / isn't patched. This is the sort of question that the debian-cd team
are also pondering: as the years go on, it is harder and harder to justify
32 bit software at least for the x86 architecture. There are already
problems with some software that just won't build well in a 32 bit
environment.

On Mon, Sep 7, 2020 at 3:12 PM Richard Owlett  wrote:

> On 09/07/2020 09:28 AM, Jonathan Dowland wrote:
> > On Mon, Sep 07, 2020 at 05:22:20PM +0300, Georgi Naplatanov wrote:
> >> You'll be able to use more RAM, CPU's registers. On the other hand some
> >> software vendors do not support x86 anymore - example: Google Chrome
> >
> > Expanding on this a little bit: the 64 bit architecture has more CPU
> > registers which could greatly improve performance for some tasks. I
> > think that there are certain other CPU instructions that are not
> > available in 32 bit mode that your programs could take advantage of.
> >
> > Not only can you use more RAM (you can address >4GiB with 64 bit memory
> > addresses without requiring workarounds like PAE), but you will almost
> > certainly *use* more RAM too, since all native pointers are now twice
> > the size. And, since most of them will be pointing at addresses lower
> > than the 4GiB boundary, half of all the newly consumed RAM will be
> > zeroes.
> >
>
> Answers I'm seem focused on too low levels. I'm interested in the
> end-user experience.
>
> E.G. what end user observable difference would there be between 32 bit
> based browser and a 64 bit based browser?
>
>
>
>

booting details

[anthony gennard]

Is it possible to download an exact replica of the booting process which I
see hurrying too fast to read it (at least it is for my tired eyes). I am
trying to get up to date with this aspect of debian. On this machine I have
Jessie installed.

Thanks,
Anthony.

Re: 32 versus 64 bit reading list suggestions

[Richard Owlett]

On 09/07/2020 09:28 AM, Jonathan Dowland wrote:

On Mon, Sep 07, 2020 at 05:22:20PM +0300, Georgi Naplatanov wrote:

You'll be able to use more RAM, CPU's registers. On the other hand some
software vendors do not support x86 anymore - example: Google Chrome


Expanding on this a little bit: the 64 bit architecture has more CPU
registers which could greatly improve performance for some tasks. I
think that there are certain other CPU instructions that are not
available in 32 bit mode that your programs could take advantage of.

Not only can you use more RAM (you can address >4GiB with 64 bit memory
addresses without requiring workarounds like PAE), but you will almost
certainly *use* more RAM too, since all native pointers are now twice
the size. And, since most of them will be pointing at addresses lower
than the 4GiB boundary, half of all the newly consumed RAM will be
zeroes.



Answers I'm seem focused on too low levels. I'm interested in the 
end-user experience.


E.G. what end user observable difference would there be between 32 bit 
based browser and a 64 bit based browser?

Re: 32 versus 64 bit reading list suggestions

[Reco]

Hi.

On Mon, Sep 07, 2020 at 10:01:42AM -0500, Richard Owlett wrote:
> > >2.What 32 bit utilities are there to identify the hardware 
> > > capabilities of a particular machine?
> > 
> > If you mean, "how do I check if my Intel/AMD CPU has that 64-bit
> > capability", then it's:
> > 
> > lscpu | grep -w lm
> 
> Will have to look up what each of the flags mean. That accomplish much
> of what I wanted to accomplish what a "reading list" would have.

lm means "Long Mode", i.e. 64-bit support.
For the others, [1] is your best reference, table 2-27.

Reco

[1] https://software.intel.com/file/36945

Re: 32 versus 64 bit reading list suggestions

[Richard Owlett]

On 09/07/2020 09:17 AM, Reco wrote:

Hi.

On Mon, Sep 07, 2020 at 08:44:28AM -0500, Richard Owlett wrote:

I have two underlying questions:
   1. As everything I currently use runs fine, what would I gain by switching 
to amd64 flavor?


Short term - you'll gain nothing. Everything will work exactly the same, barring
third-party software (if any).

Long term - Debian is one of the last major distributions that keeps
i386 supported. Sooner or later Debian will follow the current trend of
dropping i386. It won't happen in bullseye though.


   2.What 32 bit utilities are there to identify the hardware capabilities of a 
particular machine?


If you mean, "how do I check if my Intel/AMD CPU has that 64-bit
capability", then it's:

lscpu | grep -w lm


Will have to look up what each of the flags mean. That accomplish much 
of what I wanted to accomplish what a "reading list" would have.




Otherwise your question is too broad.


My question is intrinsically broad. That is why my subject line 
specified a "reading list", expecting that the reading would stimulate 
asking focused [i.e. answerable questions].




Reco

Re: 32 versus 64 bit reading list suggestions

[Felix Miata]

Richard Owlett composed on 2020-09-07 08:44 (UTC-0500):

>2.What 32 bit utilities are there to identify the hardware capabilities
>  of a particular machine?

inxi

For CPU bits specifically:

inxi -Cy

For all CPU capabilities:

inxi -Cay

If these produce any errors, you're using an old inxi version. Upstream version
permits self upgrading thus:

inxi -U

It's been too long since I last used Debian's inxi package, so don't remember if
it's packaged to override -U capability.

> inxi -V | head -n1
inxi 3.1.06-00 (2020-08-17)

For a more general display of hardware configuration:

inxi -by

And with more detail:

inxi -bay

The -y switch produces a format resulting in more lines and shorter line length,
so isn't needed, and isn't available in old inxi versions.
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: 32 versus 64 bit reading list suggestions

[David Wright]

On Mon 07 Sep 2020 at 17:17:12 (+0300), Reco wrote:
> On Mon, Sep 07, 2020 at 08:44:28AM -0500, Richard Owlett wrote:
> > I have two underlying questions:
> >   1. As everything I currently use runs fine, what would I gain by 
> > switching to amd64 flavor?
> 
> Short term - you'll gain nothing. Everything will work exactly the same, 
> barring
> third-party software (if any).
> 
> Long term - Debian is one of the last major distributions that keeps
> i386 supported. Sooner or later Debian will follow the current trend of
> dropping i386. It won't happen in bullseye though.
> 
> >   2.What 32 bit utilities are there to identify the hardware capabilities 
> > of a particular machine?
> 
> If you mean, "how do I check if my Intel/AMD CPU has that 64-bit
> capability", then it's:
> 
> lscpu | grep -w lm
> 
> Otherwise your question is too broad.

The OP is notoriouly tight on bandwidth, so they might want to
stick with i386 until their final i386-only machine expires.
(Again, assuming they aren't swayed by third-party software.)

Cheers,
David.

Re: 32 versus 64 bit reading list suggestions

[Jonathan Dowland]

On Mon, Sep 07, 2020 at 05:22:20PM +0300, Georgi Naplatanov wrote:

You'll be able to use more RAM, CPU's registers. On the other hand some
software vendors do not support x86 anymore - example: Google Chrome


Expanding on this a little bit: the 64 bit architecture has more CPU
registers which could greatly improve performance for some tasks. I
think that there are certain other CPU instructions that are not
available in 32 bit mode that your programs could take advantage of.

Not only can you use more RAM (you can address >4GiB with 64 bit memory
addresses without requiring workarounds like PAE), but you will almost
certainly *use* more RAM too, since all native pointers are now twice
the size. And, since most of them will be pointing at addresses lower
than the 4GiB boundary, half of all the newly consumed RAM will be
zeroes.

--
Please do not CC me, I am subscribed to the list.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: 32 versus 64 bit reading list suggestions

[Georgi Naplatanov]

On 9/7/20 4:44 PM, Richard Owlett wrote:
> I switched from Windows when Squeeze was current and was working with a
> mix of 32 and 64 bit machines. To simplify my life I used and continue
> to use the i386 flavor of Debian.
> 
> I have two underlying questions:
>   1. As everything I currently use runs fine, what would I gain by
>  switching to amd64 flavor?

You'll be able to use more RAM, CPU's registers. On the other hand some
software vendors do not support x86 anymore - example: Google Chrome


>   2.What 32 bit utilities are there to identify the hardware capabilities
>     of a particular machine?
> 

lscpu
lspci
lsusb
lshw

HTH

Kind regards
Georgi

Re: 32 versus 64 bit reading list suggestions

[Reco]

Hi.

On Mon, Sep 07, 2020 at 08:44:28AM -0500, Richard Owlett wrote:
> I have two underlying questions:
>   1. As everything I currently use runs fine, what would I gain by switching 
> to amd64 flavor?

Short term - you'll gain nothing. Everything will work exactly the same, barring
third-party software (if any).

Long term - Debian is one of the last major distributions that keeps
i386 supported. Sooner or later Debian will follow the current trend of
dropping i386. It won't happen in bullseye though.

>   2.What 32 bit utilities are there to identify the hardware capabilities of 
> a particular machine?

If you mean, "how do I check if my Intel/AMD CPU has that 64-bit
capability", then it's:

lscpu | grep -w lm

Otherwise your question is too broad.

Reco

32 versus 64 bit reading list suggestions

[Richard Owlett]

I switched from Windows when Squeeze was current and was working with a 
mix of 32 and 64 bit machines. To simplify my life I used and continue 
to use the i386 flavor of Debian.


I have two underlying questions:
  1. As everything I currently use runs fine, what would I gain by
 switching to amd64 flavor?
  2.What 32 bit utilities are there to identify the hardware capabilities
of a particular machine?

I'm asking for recommended reading list to discover questions I should 
be aware of that I don't recognize I should be asking.


TIA

Re: AMD Radeon(TM) R2 en Jessie

[Camaleón]

El 2020-09-07 a las 15:16 +0300, Julián Daich escribió:

(mando a la lista)

> El 7/9/20 a las 14:50, Camaleón escribió:
> > El 2020-09-07 a las 14:05 +0300, Julián Daich escribió:
> > 
> > > El 6/9/20 a las 20:23, Camaleón escribió:
> > > > No recuerdo cuál era el motivo que te impedía instalar el controlador
> > > > propietario de ATI en Debian Jessie ¿por qué no lo puedes instalar desde
> > > > el repositorio de non-free? :-?
> > > > 
> > > 
> > > Está instalado en Jessie. Quiero ver la forma de poder seguir usando el
> > > controlador FGLRX en Stretch. Jessie ya no tiene soporte.
> 
> > Entonces supongo que la LiveCD sobre la que haces las pruebas es la
> > última versión estable (Buster) ¿no?
> > 
> 
> Hola,
> Np, Stretch.

Stretch ya es «oldstable». Obtendrás resultados más realistas con Buster, 
que tiene un kernel más moderno.

> > El paquete «deb» de AMD es para una versión concreta de Ubuntu, no te
> > servirá debido a la versión del kernel que tienes en Debian.
> > 
> 
> 
> Probé con la versión de Jessie.

No te sigo. Me refiero al paquete .deb que tienes en la web de AMD-ATI, 
no al .deb que tienes en el repo «non-free» de Debian.



> > Lo más factible sería compilar el driver que hay para Linux (x86_64) y
> > seleccionar la opción de generar el paquete específico para la
> > distribución, si fuera posible. Consulta las notas de instalación¹ para
> > ver los requisitos de esta opción.
> > 
> 
> Pide Xorg y por lo tanto xserver-xorg-core de Jessie
> 
> Estamos volviendo en bucle a lo que escribí antes.

No te sigo aquí tampoco.
El paquete .zip de AMD-ATI te pedirá Xorg, eso es normal, pero no una 
versión concreta sino que buscará la ruta del Xorg que tengas instalado 
en el sistema. Que funcione o no es otra cosa, por eso tienes que 
consultar los requisitos de instalación del controlador para ver qué 
necesita.

La única posibilidad de éxito que veo para tener el driver antiguo y 
propietario de ATI funcionando en una Debian moderna es compilando la 
última versión disponible del controlador que proporciona el fabricante
con el kernel que tengas instalado.

Si esa combinación no funciona, bien por problemas de dependencias de 
bibliotecas insatisfechas o versiones del sistema gráfico (Xorg) que no 
son admitidas por el controlador de ATI, entonces no veo otra solución 
para poner en marcha esa combinación concreta de tarjeta gráfica antigua
con driver antiguo en versiones recientes de Debian.

Saludos,

-- 
Camaleón 

Re: diskless system's limited dhcp support

[Dan Ritter]

Ross Boylan wrote: 
> On Sun, Sep 6, 2020 at 3:37 PM Dan Ritter  wrote:
> 
> > The usual way is:
> >
> > 1. DNS record tied to a static IP address
> > 2. IP address handed out by DHCP server based on MAC address of
> >the interface
> 
> 
> > This is especially normal when the root is served by NFS, so PXE
> > needs to figure out the right root to hand out -- PXE is
> > governed by MAC address, and then you really want the kernel's
> > conception of its IP address to remain the same.
> >
> I don't follow that last part.  I thought PXE was irrelevant once the
> system was up.  And the IP address of the root fs is distinct from the IP
> address of the client.

You made me double-check my belief here. I thought that the
kernel inherited the IP address from the PXE booter, but I
was wrong; there's no mechanism for that. It's an artifact of
my own setup, where individual MAC addresses are used to return
specific IP addreses.

I would still argue that this is a good practice, because it
makes debugging easier, but it's not necessary.

> > > bit of a hack.  Also, I'd like the DNS entry for the system to appear
> > only
> > > while it is up, and without the client sending a host name that's harder.
> >
> > That requires a server that listens to a dynamic DNS protocol,
> > and a dynamic DNS client on the client system.
> >
> My server is set for dynamic updates.  Since ipconfig sets up the
> interface, the usual dhcp client that manages such stuff doesn't come up.
> 
> > Why would you care about the DNS name not being available when
> > the machine isn't up?
> >
> Mostly because the machine might be up, but running a different OS
> instance.  This applies to non-diskless, non-PXE clients as well.  So the
> MAC address does not determine a unique system.  PXE booting (and grub for
> regular systems) provides a menu of possible systems from which to boot, so
> I may not know which of them is running until someone makes a selection
> from the menu.
> 
> I've been shooting for using the same IP regardless of the OS, but maybe
> that's inadvisable. OTOH, for PXE the machine gets an IP before the
> selection is made.

It depends on the semantics that you're assigning to names and
IPs and MACs. IMHO, the physical hardware is important because
if there's a problem, I need to know what piece of equipment I
will have to walk over to and debug.


-dsr-

Re: AMD Radeon(TM) R2 en Jessie

[Camaleón]

El 2020-09-07 a las 14:05 +0300, Julián Daich escribió:

> El 6/9/20 a las 20:23, Camaleón escribió:
> > No recuerdo cuál era el motivo que te impedía instalar el controlador
> > propietario de ATI en Debian Jessie ¿por qué no lo puedes instalar desde
> > el repositorio de non-free? :-?
> > 
> 
> Está instalado en Jessie. Quiero ver la forma de poder seguir usando el
> controlador FGLRX en Stretch. Jessie ya no tiene soporte.

Entonces supongo que la LiveCD sobre la que haces las pruebas es la 
última versión estable (Buster) ¿no?

El paquete «deb» de AMD es para una versión concreta de Ubuntu, no te 
servirá debido a la versión del kernel que tienes en Debian.

Lo más factible sería compilar el driver que hay para Linux (x86_64) y 
seleccionar la opción de generar el paquete específico para la 
distribución, si fuera posible. Consulta las notas de instalación¹ para 
ver los requisitos de esta opción.

¹

Saludos, 

-- 
Camaleón 

Re: AMD Radeon(TM) R2 en Jessie

[Julián Daich]

El 6/9/20 a las 20:23, Camaleón escribió:

No recuerdo cuál era el motivo que te impedía instalar el controlador
propietario de ATI en Debian Jessie ¿por qué no lo puedes instalar desde
el repositorio de non-free? :-?



Hola,

Está instalado en Jessie. Quiero ver la forma de poder seguir usando el 
controlador FGLRX en Stretch. Jessie ya no tiene soporte.


Saludos.

Julián


Saludos,


--
Julian Daich 

Re: xdg-mime

[Andrei POPESCU]

On Sb, 05 sep 20, 12:07:17, Rainer Dorsch wrote:
> Hi,
> 
> is there a way to find out where xdg-mime gets its configuration from?
> 
> I have
> 
> $ xdg-mime query default application/pdf
> gimp.desktop
> $ 
> 
> but I would have expected okular.
> 
> Just wondering if this is a wrong user configuration or if the problem is 
> system wide...

Poking around my system I found /etc/mime.types, it might give you a 
start.

xdg-mime(1) also mentions the "Shared MIME database specification", 
which I'm guessing will have all you need.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: E16 et la réorganisation des fenêtres

[didier gaumet]

Hello,

Peut-être que ce qui est évoqué ici pourra t'aider (je ne sais pas, j'utilise 
bêtement Gnome) :
 
https://thomashunter.name/posts/2019-01-27-treating-openbox-like-a-tiling-windowmanager
 
https://ideatrash.net/2019/06/organizing-and-tiling-your-windows-on-openbox-using-only-openbox.html

Re: VirtualBox - vboxpci

[Georgi Naplatanov]

On 9/7/20 2:03 AM, Keith Bainbridge wrote:
> On 6/9/20 8:27 pm, Georgi Naplatanov wrote:
>> On 9/6/20 12:17 PM, Klaus Jantzen wrote:
>>> Hi,
>>>
>>> I am trying to run VB 16.1.14 r140239 on my laptop under Debian Buster.
>>>
>>> After sucessfully signing vboxdrv, vboxnetflt and vboxnetadp I installed
>>> the extension package.
>>>
>>> Now I have to additionally sign vboxpci.
>>>
>>> However, this module was not installed. Where do I get it from?
>>>
>>
>>
>> Hi,
>>
>> I use Virtualbox 6.1 on my computer without any problems.
>>
>> I don't understand what your problem is.
>>
>> I have added the following line to /etc/apt//sources.list
>>
>> deb https://download.virtualbox.org/virtualbox/debian buster contrib
>>
>> HTH
>>
>> Kind regards
>> Georgi
>>
> 
> Good morning Georgi
> 
> 
> I am running buster with backports - by way of LMDE. As an example of
> the backports working, I have LibreOffice 7 installed as part of a
> recent upgrade.
> 
> My vbox is 6.1.12
> 
> When I run # apt install virtualbox   (immediately after # apt update)
> 
> I get:
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> virtualbox-6.1 is already the newest version (6.1.12-139181~Debian~buster).
> The following packages were automatically installed and are no longer
> required:  clipped
> 
> 
> I see VB 6.1.14 is available from the website. As it hasn't been added
> to buster, perhaps somebody at Oracle can help you?
> 

Hi Keith,

I have Virtualbox 6.1.14 on my computer.

When I run

# apt install virtualbox

the output is:

Reading package lists... Done
Building dependency tree
Reading state information... Done
Package virtualbox is a virtual package provided by:
  virtualbox-6.1 6.1.14-140239~Debian~buster
  virtualbox-6.0 6.0.24-139119~Debian~buster
  virtualbox-5.2 5.2.34-133893~Ubuntu~bionic
You should explicitly select one to install.

E: Package 'virtualbox' has no installation candidate

Kind regards
Georgi