Re: support for ancient peripherals

[Felix Miata]

Kleene, Steven (kleenesj) composed on 2022-11-05 23:21 (UTC):

> As you might understand, I'd like to replace my desktop, a 2006 Pentium 4
> with a 3-GHz processor.  It has always run Debian, and so will the new one.

> My concern is about support for three ancient peripherals that I like better
> than the modern equivalents:
> 1. A Northgate Omnikey 101 keyboard (from 2006) with a 5-pin DIN cable,
> currently going via an adapter to a PS/2 port in the desktop;
> 2. A Logitech M-MD15L three-button roller-ball serial mouse (from 2006); and
> 3. An HP LaserJet 5MP printer from 1995 with a parallel-port connector.

> Are desktops still available with PS/2, serial, or parallel ports?  If not,
> can these all be adapted to USB?  Are USB-A ports still common, or is USB-C
> taking over?  My question is of course not just about hardware but about
> software support for these devices in Debian.  They all work now in Buster
> (oldstable).  Thanks.

I wish my OmniKey didn't drop dead over a decade ago. Yet, I'm still using
keyboards with DIN-5 connectors and PS/2 adapters on nearly every boot of any of
my 40+ PCs. Intel tried to eliminate PS/2 support a decade ago, but the 
accessory
chip makers took it over, and most PC motherboards still provide them.

Serial and parallel went the other way. By far most recent motherboards have
neither on the back pane, but many still do have support via plugs on 
motherboards
that can be used to add-on serial and/or parallel ports. For those that don't it
usually doesn't matter, as PCIe expansion cards with those ports are available.

As to using them, I haven't tried a serial mouse in over a year, and a parallel
printer in over a decade. All my printers connect via ethernet or wireless.
Parallel ports probably don't get much testing by developers any more, but
probably don't need much, if any. Kernel devs OTOH seem to need serial now and
then for data capture. Likely they're mostly using USB adapters by now.

USB-A ports sometimes are reduced to two on the backpanes, but usually there are
plenty USB3 ports that can handle USB1 or 2 if you need more than 2 in back. 
OTOH,
quite some don't bother providing USB-C.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

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

Felix Miata

Re: support for ancient peripherals

[Stefan Monnier]

Kleene, Steven (kleenesj) [2022-11-05 23:21:38] wrote:
> My concern is about support for three ancient peripherals that I like better
> than the modern equivalents:
> 1. A Northgate Omnikey 101 keyboard (from 2006) with a 5-pin DIN cable,
> currently going via an adapter to a PS/2 port in the desktop;

AFAIK any old PS2 to USB adapter should do the trick.  They used to work
very reliably, so I can't think of any reason why they wouldn't work any more.

> 2. A Logitech M-MD15L three-button roller-ball serial mouse (from 2006); and

You can find serial to USB adapters, but it will require some manual
configuration, tho I suspect you already had to do that in Buster, so it
should keep working pretty much the same (except the serial device will
have a different name in `/dev/).

> 3. An HP LaserJet 5MP printer from 1995 with a parallel-port connector.

No idea about this one.  I know there are USB<->centronics adapters out
there, but I have no idea how well they will work with something like
a CUPS driver.


Stefan

support for ancient peripherals

[Kleene, Steven (kleenesj)]

As you might understand, I'd like to replace my desktop, a 2006 Pentium 4
with a 3-GHz processor.  It has always run Debian, and so will the new one.

My concern is about support for three ancient peripherals that I like better
than the modern equivalents:
1. A Northgate Omnikey 101 keyboard (from 2006) with a 5-pin DIN cable,
currently going via an adapter to a PS/2 port in the desktop;
2. A Logitech M-MD15L three-button roller-ball serial mouse (from 2006); and
3. An HP LaserJet 5MP printer from 1995 with a parallel-port connector.

Are desktops still available with PS/2, serial, or parallel ports?  If not,
can these all be adapted to USB?  Are USB-A ports still common, or is USB-C
taking over?  My question is of course not just about hardware but about
software support for these devices in Debian.  They all work now in Buster
(oldstable).  Thanks.

Re: Choosing neovim over vim as default

[Oliver Schoede]

Hello!

On Fri, 04 Nov 2022 20:30:51 +0530
Bharatvaj P H  wrote:

>vimscript9
> feels like a bad decision, it is incompatible with vimscript2 and
> does not match performance with lua.

Probably not many scripting languages do. But then I'm not sure
performance is the be-all and end-all when it comes to editor plugins.
Certainly not for the Vim folks and even though speed was one the
grounds for the change, as far as I'm aware it's not the most important.

>Until vim9 I thought vim as a slimmer version of neovim but 
>it's the opposite.

I've never heard this before. The whole point of Neovim was getting rid
of what those folks identify or consider as "legacy" baggage. It is
slimmer, hence maybe faster. That's good for Neovim, but not crucial
for all of us.

>Currently there is confusion among developers when
>writing a plugin whether to choose vimscript9 or lua. And the only
>point vimscript9 has is tha it is available in all distros. Is it time
>to switch over to neovim? Choosing lua over vimscript9 reduces the
>cognitive load of many people.

I'm not to answer, just a user, though I would strongly oppose it. We
also ship I believe quite a few emacs forks, clones or variations, I
guess no one is ever seriously about to consider changing the default.
Vim is Vim. Neovim is Neovim. Anyone is free to use whatever they
prefer, and that's surely more people than those who write their own
plugins, or need to adapt one, they may still care about what editor
they use. Once they have to, chances are they're going to learn a new
language anyway, because Lua isn't exactly popular.


Oliver

Re: Changes in the syslog date format?

[Greg Wooledge]

On Sat, Nov 05, 2022 at 05:12:40PM +0100, local10 wrote:
> Nov 5, 2022, 15:30 by g...@wooledge.org:
> 
> >> > > local10 wrote:
> >> > > 
> >> > > > Any ideas as to get the old syslog date format back?
> >>
> >
> > What caused a change?
> >
> 
> 
> Who knows? I suspect   [UPGRADE] rsyslog:amd64 8.2210.0-1 -> 8.2210.0-3 that 
> happened around November 4, 2022.

https://metadata.ftp-master.debian.org/changelogs//main/r/rsyslog/rsyslog_8.2210.0-3_changelog

rsyslog (8.2210.0-3) unstable; urgency=medium
[...]
  * Enable high precision timestamps with timezone information.
Use the default rsyslog file format, which provides several benefits
like:
- sortable
- time zone information
- sub-second time resolution

Testing and unstable users ought to expect changes, and they ought to
be self-aware enough to include "I'm running testing" in their emails.

[SOLVED] Re: Changes in the syslog date format?

[local10]

Nov 5, 2022, 14:53 by j...@k4vqc.com:

> On Sat, 2022-11-05 at 11:34 +0100, local10 wrote:
>
>> Nov 5, 2022, 09:55 by scdbac...@gmx.net:
>>
>> > Hi,
>> > 
>> > local10 wrote:
>> > 
>> > > Any ideas as to get the old syslog date format back?
>> > > 
>> > 
>> > The internet points to /etc/rsyslog.conf and in there:
>> > 
>> >  #
>> >  # Use traditional timestamp format.
>> >  # To enable high precision timestamps, comment out the following line.
>> >  #
>> >  $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
>> > 
>>
>>
>> Doesn't seem to work for me.
>>
>
> Didn't work for me earlier.  To fix this I had to add
>
> $template normal,"<%PRI%>%TIMESTAMP% %syslogtag%%msg%"
>


Got it working. Apparently, the $ActionFileDefaultTemplate directive is place 
sensitive and must be placed under the the GLOBAL DIRECTIVES section. Didn't 
work for me when it was placed at the end of rsyslog.conf file. Pretty strange.

###
 GLOBAL DIRECTIVES 
###

#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

## Enable old syslog date format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat



Thanks to everyone who responded.

Re: Changes in the syslog date format?

[Greg Wooledge]

> > > local10 wrote:
> > > 
> > > > Any ideas as to get the old syslog date format back?

What caused a change?  What version of Debian are you running?  What
happened on the date in question (November 4) -- were some packages
updated?  Which ones?

Here in Debian 11 (bullseye), I see no such change.


Nov  5 11:25:01 unicorn CRON[1581849]: (root) CMD (command -v debian-sa1 > 
/dev/null && debian-sa1 1 1)


My /etc/rsyslog.conf contains the incredibly long and awkward line
in question.


###
 GLOBAL DIRECTIVES 
###

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

Re: Changes in the syslog date format?

[Jim Popovitch]

On Sat, 2022-11-05 at 11:34 +0100, local10 wrote:
> Nov 5, 2022, 09:55 by scdbac...@gmx.net:
> 
> > Hi,
> > 
> > local10 wrote:
> > 
> > > Any ideas as to get the old syslog date format back?
> > > 
> > 
> > The internet points to /etc/rsyslog.conf and in there:
> > 
> >  #
> >  # Use traditional timestamp format.
> >  # To enable high precision timestamps, comment out the following line.
> >  #
> >  $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
> > 
> 
> 
> Doesn't seem to work for me.

Didn't work for me earlier.  To fix this I had to add

$template normal,"<%PRI%>%TIMESTAMP% %syslogtag%%msg%"


Who thought of adding "[localhost]" in the middle of all new syslog
lines, and why didn't they coordinate with the logcheck team?

-Jim P.

Re: Graphics Cards: Radeon RX 6000 Series on Debian-11 (Bullseye):

[piorunz]

On 28/07/2022 15:01, b...@iinet.net.au wrote:

Hi to all of you on the debian-user list.

Is anyone out there successfully running any of the Radeon RX 6000
Series graphics cards on Debian-11 (Bullseye) installations with *no*
backports?

I ask the above question because I can't see the required versions of
"Navi" firmware; namely "Navi 21" to "Navi 24", available in the package
"firmware-amd-graphics".  Probably a silly question, however I'm asking
anyhow.

Cheers in hope,
BRN.

I think you'll need backports, if I remember correctly. I have 6800 XT, 
been running stable with backports since I bought it, it's working very 
well. Card will work without backports but you may have no 3D 
acceleration. Adding backports repo and upgrading kernel + drivers is 
very easy.


Since then I've upgraded to Testing out of curiosity, but it was not 
necessary, it works just as well as before. Once Debian Bookworm is 
released, I most likely will stay with it during stable cycle, I prefer 
stability of the software over freshness (with extra bugs).


--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Changes in the syslog date format?

[local10]

Nov 5, 2022, 09:55 by scdbac...@gmx.net:

> Hi,
>
> local10 wrote:
>
>> Any ideas as to get the old syslog date format back?
>>
>
> The internet points to /etc/rsyslog.conf and in there:
>
>  #
>  # Use traditional timestamp format.
>  # To enable high precision timestamps, comment out the following line.
>  #
>  $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
>


Doesn't seem to work for me.


I didn't have "$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat" line 
in the /etc/rsyslog.conf file so I added it but it didn't change the syslog 
date format for some reason:

# cat /etc/rsyslog.conf 
...
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat



# systemctl restart rsyslog.service
#
# systemctl status  rsyslog.service
● rsyslog.service - System Logging Service
 Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; preset: 
enabled)
 Active: active (running) since Sat 2022-11-05 06:25:57 EDT; 5s ago
TriggeredBy: ● syslog.socket
   Docs: man:rsyslogd(8)
 man:rsyslog.conf(5)
 https://www.rsyslog.com/doc/
   Main PID: 157593 (rsyslogd)
  Tasks: 4 (limit: 8813)
 Memory: 2.7M
    CPU: 6ms
 CGroup: /system.slice/rsyslog.service 
 └─157593 /usr/sbin/rsyslogd -n -iNONE

Nov 05 06:25:57 tst systemd[1]: rsyslog.service: Deactivated successfully.
Nov 05 06:25:57 tst systemd[1]: Stopped System Logging Service.
Nov 05 06:25:57 tst rsyslogd[157593]: imuxsock: Acquired UNIX socket 
'/run/systemd/journal/syslog' (fd 3) from systemd.  [v8.2210.0]
Nov 05 06:25:57 tst systemd[1]: Starting System Logging Service...
Nov 05 06:25:57 tst rsyslogd[157593]: [origin software="rsyslogd" 
swVersion="8.2210.0" x-pid="157593" x-info="https://www.rsyslog.com";] start
Nov 05 06:25:57 tst systemd[1]: Started System Logging Service.



# cat /var/log/syslog
...
2022-11-05T06:25:57.617308-04:00 tst systemd[1]: Stopping System Logging 
Service...
2022-11-05T06:25:57.672637-04:00 tst systemd[1]: rsyslog.service: Deactivated 
successfully.
2022-11-05T06:25:57.672835-04:00 tst rsyslogd: [origin software="rsyslogd" 
swVersion="8.2210.0" x-pid="157518" x-info="https://www.rsyslog.com";] exiting 
on signal 15.
2022-11-05T06:25:57.672895-04:00 tst systemd[1]: Stopped System Logging Service.
2022-11-05T06:25:57.673264-04:00 tst rsyslogd: imuxsock: Acquired UNIX socket 
'/run/systemd/journal/syslog' (fd 3) from systemd.  [v8.2210.0]
2022-11-05T06:25:57.673332-04:00 tst systemd[1]: Starting System Logging 
Service...
2022-11-05T06:25:57.673386-04:00 tst rsyslogd: [origin software="rsyslogd" 
swVersion="8.2210.0" x-pid="157593" x-info="https://www.rsyslog.com";] start
2022-11-05T06:25:57.673437-04:00 tst systemd[1]: Started System Logging Service.



Regards,

Re: Changes in the syslog date format?

[Thomas Schmitt]

Hi,

local10 wrote:
> Any ideas as to get the old syslog date format back?

The internet points to /etc/rsyslog.conf and in there:

  #
  # Use traditional timestamp format.
  # To enable high precision timestamps, comment out the following line.
  #
  $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

In
  https://www.rsyslog.com/doc/v8-stable/configuration/templates.html
i read:
  RSYSLOG_TraditionalFileFormat - The “old style” default log file format
  with low-precision timestamps.


Have a nice day :)

Thomas

Re: loss of mbmon function

[gene heskett]

On 11/4/22 22:57, David Christensen wrote:

On 11/2/22 21:23, gene heskett wrote:

On 11/2/22 21:01, David Christensen wrote:

On 11/2/22 12:07, gene heskett wrote:

On 11/2/22 08:19, gene heskett wrote:

All 5 of the samsung SDD's in THIS machine have now been 
-test=long'd, all 5 report
with the -a option that the read test failed as seen below, but a 
-H says they are healthy.


Whats next?



I have found that smartctl(8) version 7.2 has trouble decoding some 
of the statistics for my Intel SSD 520 Series drives (Debian 
Stable), while smartctl(8) version 7.3 does a better job 
(FreeBSD-12.3-RELEASE-amd64). So, perhaps you are seeing bad 
information from smartctl(8) version 7.2.



Debian backports does not seem to offer smartmontools 7.3.


Debian Testing and Unstable have smartmontools 7.3.


Alternatively, Samsung does make software tools for their storage 
products.  Unfortunately, I believe the tools are Windows 
applications; so, they require a Windows installation.



Have you tried smartmontools 7.3 and/or Samsung tools?


AIUI you have a HBA/RAID card in that computer.  I suspect that you 
also have USB devices and/or other connected hardware.  What happens 
if you disconnect everything?  If the problem goes away, do a search 
and find the problem hardware.


Not a raid card, just another $20 6 port sata card, its software 
raid. There is no drive activity
of any kind when it hangs. The only indication of life at all is a 
row of color changing leds on
the front edge of the mobo are cycling the colors, possibly a little 
slower that they are right now.



I assume you understand that expansion cards can have extension 
firmware that runs during POST, which can delay or halt POST (?). 
Similarly, the motherboard firmware goes through a USB enumeration 
process during POST and connected USB devices must have compatible 
firmware; issues can cause delays and/or halt POST (?).



Does the boot process change when you disconnect all of the drives? 
When your remove the card?  If so, use a process of elimination to 
find the problem item(s).



This is new, in a system that has been booting just fine for about a year.


I've considered that disconnect as my usb tree looks like a 50 yo 
weeping willow.
Everything but the keyboard and mouse buttons can be disconnected by 
about 6 usb cables.
Getting these 88 yo knees down on the floor to see about plugging 
them back in is a

bit of a chore so they don't get disconnected very often.



That is why they invented knee pads and/or (great?) (grand?) children.

Knee pads are in the shop, out of mind. And while there are many 
great-grandchildren, they are all 2k miles west of me.


Does the boot process change when you disconnect all USB devices and 
connect the keyboard directly to the motherboard?  Different ports? 
Different keyboards?  If boot changes, use a process of elimination to 
identify the problem keyboard(s), port(s), and/or USB devices(s).
So far it has eventually rebooted, usually while I'm figuriing out what 
to disconnect next. The only thing new is a different sd card

adaptor,  I'll unplug it next time.

Thank you.
This is the main computer of a 7 machine home network that by the 
time they are done arguing
about who won next Teusday's election, might have 4 more bannana pi's 
to connect to.


I'd like to have bought rpi4b's w/8G's but their scarcity has ran the 
price above $300.
Much newer bananna pi's BPI-M5's with 4G are $90. And have faster usb 
as all 4 ports are usb3.1.


Do like I did with the rpi4b running my biggest cnc lathe, and move 
all the high traffic stuff
to a $30 SSD and get uptimes in years. I have an automatic 20kw 
standby and the pi has a small
ups. That made the pi into a workstation, building its own real-time 
kernel AND linuxcnc from a git pull if

the buildbot at linuxcnc.org gets a tummy ache.



All the more reason to figure out why the server is misbehaving and 
fix it.



David

.



Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: loss of mbmon function

[gene heskett]

On 11/4/22 22:57, David Christensen wrote:

On 11/2/22 21:23, gene heskett wrote:

On 11/2/22 21:01, David Christensen wrote:

On 11/2/22 12:07, gene heskett wrote:

On 11/2/22 08:19, gene heskett wrote:

All 5 of the samsung SDD's in THIS machine have now been 
-test=long'd, all 5 report
with the -a option that the read test failed as seen below, but a 
-H says they are healthy.


Whats next?



I have found that smartctl(8) version 7.2 has trouble decoding some 
of the statistics for my Intel SSD 520 Series drives (Debian 
Stable), while smartctl(8) version 7.3 does a better job 
(FreeBSD-12.3-RELEASE-amd64). So, perhaps you are seeing bad 
information from smartctl(8) version 7.2.



Debian backports does not seem to offer smartmontools 7.3.


Debian Testing and Unstable have smartmontools 7.3.


Alternatively, Samsung does make software tools for their storage 
products.  Unfortunately, I believe the tools are Windows 
applications; so, they require a Windows installation.



Have you tried smartmontools 7.3 and/or Samsung tools?

smartmontools is A: not found, but synaptic says 7.2-1. And B: no, 
synaptic won't let me fiddle with that.


AIUI you have a HBA/RAID card in that computer.  I suspect that you 
also have USB devices and/or other connected hardware.  What happens 
if you disconnect everything?  If the problem goes away, do a search 
and find the problem hardware.


Not a raid card, just another $20 6 port sata card, its software 
raid. There is no drive activity
of any kind when it hangs. The only indication of life at all is a 
row of color changing leds on
the front edge of the mobo are cycling the colors, possibly a little 
slower that they are right now.



I assume you understand that expansion cards can have extension 
firmware that runs during POST, which can delay or halt POST (?). 
Similarly, the motherboard firmware goes through a USB enumeration 
process during POST and connected USB devices must have compatible 
firmware; issues can cause delays and/or halt POST (?).



Does the boot process change when you disconnect all of the drives? 
When your remove the card?  If so, use a process of elimination to 
find the problem item(s).



I've considered that disconnect as my usb tree looks like a 50 yo 
weeping willow.
Everything but the keyboard and mouse buttons can be disconnected by 
about 6 usb cables.
Getting these 88 yo knees down on the floor to see about plugging 
them back in is a

bit of a chore so they don't get disconnected very often.



That is why they invented knee pads and/or (great?) (grand?) children.


Does the boot process change when you disconnect all USB devices and 
connect the keyboard directly to the motherboard?  Different ports? 
Different keyboards?  If boot changes, use a process of elimination to 
identify the problem keyboard(s), port(s), and/or USB devices(s).



This is the main computer of a 7 machine home network that by the 
time they are done arguing
about who won next Teusday's election, might have 4 more bannana pi's 
to connect to.


I'd like to have bought rpi4b's w/8G's but their scarcity has ran the 
price above $300.
Much newer bananna pi's BPI-M5's with 4G are $90. And have faster usb 
as all 4 ports are usb3.1.


Do like I did with the rpi4b running my biggest cnc lathe, and move 
all the high traffic stuff
to a $30 SSD and get uptimes in years. I have an automatic 20kw 
standby and the pi has a small
ups. That made the pi into a workstation, building its own real-time 
kernel AND linuxcnc from a git pull if

the buildbot at linuxcnc.org gets a tummy ache.



All the more reason to figure out why the server is misbehaving and 
fix it.



David

.



Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Changes in the syslog date format?

[local10]

Hi,

It looks like the syslog date format has changed for some reason (see below) 
and the change is definitely less readable for me. The change maybe related to 
the rsyslog upgrade that happened around November 4, 2022:

    [UPGRADE] rsyslog:amd64 8.2210.0-1 -> 8.2210.0-3

Any ideas as to get the old syslog date format back?

Regards,


Nov  4 03:26:23 [localhost] systemd[1]: Reloading.  ## how syslog records 
used to look
2022-11-04T03:26:24.151066-04:00 tst systemd[1]: Stopping System Logging 
Service... ## how syslog records look now
2022-11-04T03:26:24.297040-04:00 tst rsyslogd: [origin software="rsyslogd" 
swVersion="8.2210.0" x-pid="463" x-info="https://www.rsyslog.com";] exiting on 
signal 15.

Re: Trying to start Xorg on a vanilla bullseye on rpi4

[Tim Woodall]

On Fri, 4 Nov 2022, Tim Woodall wrote:


I've tried updating the kernel to bullseye-backports but that hasn't
helped.

It's using the modesetting driver. Putting nomodeset on the kernel
commandline and that doesn't work.

Forcing X11 to use the fbdev device does start but doesn't find any
outputs.



I tried switching to use the uefi boot - which has the nice feature that
grub works. But that is worse:

xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1920 x 1280, current 1920 x 1280, maximum 1920 x 1280
default connected 1920x1280+0+0 0mm x 0mm
   1920x1280 78.00*