[Grml] Some features may be dropped from GNU Screen in the future (including braille support)

[Jason White]

If you can't test Braille support, don't just remove it, ask for help
testing.
I would be happy to test Braille support on Linux, and I am sure there are
others who would be willing to test as well.

Actually, I think it's mostly used by people running FreeBSD, possibly OS X
and other operating systems, not by Linux users, because BRLTTY can directly
read the Linux console and hence the support in GNU Screen isn't needed in a
Linux environment.

the best place to find users would be the BRLTTY mailing list, I suspect.

[John G. Heim]

I don't think there is any reason to remove braille support from grml. I've been testing it every release up to the latest and reporting the results on the grml list. I know a version just came out a few weeks ago and I haven't tested it. It's just that I happen to be on vacation. They had a really quick release cycle andI just didn't have time to test it. I certainlhy hope grml doesn't do something as drastic as dropping braille support just because I happened to be on vacation.

Scent fwom my ipood`

Post by Jason White

If you can't test Braille support, don't just remove it, ask for help
testing.
I would be happy to test Braille support on Linux, and I am sure there are
others who would be willing to test as well.

Actually, I think it's mostly used by people running FreeBSD, possibly OS X
and other operating systems, not by Linux users, because BRLTTY can directly
read the Linux console and hence the support in GNU Screen isn't needed in a
Linux environment.
the best place to find users would be the BRLTTY mailing list, I suspect.
_______________________________________________
Grml mailing list - Grml at ml.grml.org
http://ml.grml.org/mailman/listinfo/grml
join #grml on irc.freenode.org
grml-devel-blog: http://blog.grml.org/

[Jason White]

What is being discussed is the tiny braille support embedded in the
screen package, which only supports a few TeleSensory and TSI hardware
in a quite basic way, and which has not been developped or maintained
for years. There is little wonder screen maintainers would rather
remove that part of the code: it is unmaintained, and brltty can already
access screen content another way, and is developped, maintained etc.

Agreed.

[Samuel Thibault]

Hello,

I'd like to emphasize that the braille feature which is discussed about
here is *not* general braille access through brltty.

What is being discussed is the tiny braille support embedded in the
screen package, which only supports a few TeleSensory and TSI hardware
in a quite basic way, and which has not been developped or maintained
for years. There is little wonder screen maintainers would rather
remove that part of the code: it is unmaintained, and brltty can already
access screen content another way, and is developped, maintained etc.

Samuel

[Mario Lang]

Post by Samuel Thibault
Hello,
I'd like to emphasize that the braille feature which is discussed about
here is *not* general braille access through brltty.
What is being discussed is the tiny braille support embedded in the
screen package, which only supports a few TeleSensory and TSI hardware
in a quite basic way, and which has not been developped or maintained
for years. There is little wonder screen maintainers would rather
remove that part of the code: it is unmaintained, and brltty can already
access screen content another way, and is developped, maintained etc.

I agree. I have found native screen support for braille displays a few
years ago basically by accident during a code browse. While it might
historically be interesting that the GNU screen package directly
support(s|ed) braille displays, I don't think many (if any) people
actually use that. At least on Linux, BRLTTY is superior regarding its
functionality and driver support, and everyone knows that. I am not
sure about other operating system kernels, but even if we considered
*BSDs whigh might be interested in such a feature natively provided by
GNU screen, there is virtually no support for current hardware models
in GNU screen. So dropping that part of the code seems like a sensible
thing to do. The alternative would be to improve it *a lot*.
--
CYa,
????? | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger mlang/key at db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 635 bytes
Desc: not available
URL: <http://ml.grml.org/pipermail/grml/attachments/20140404/3e0635c8/attachment.sig>

[Axel Beckert]

Hi,

on the GNU Screen development mailing list, there's currently a thread
which discusses how to get some drive in the GNU Screen development
again.

Amadeusz S?awi?ski (Cc'ed) has a git repo with some a little bit more
disruptive changes at https://github.com/amade/screen/tree/devel/src

In the following mail he describes what he changed and removed. (I've
shortened the mail. "[?]" show points where I removed parts. Full mail
at https://lists.gnu.org/archive/html/screen-devel/2014-04/msg00008.html)

One of the GNU Screen feature which are about to be dropped in the
future is Screen's braille support. (Which is not enabled in Debian's
screen package as far as I can see.)

I know that there are quite some visually handicapped Grml users, so I
send this mail to the debian-accessibility mailing list and the
general Grml mailing list. Reply-To is set to the screen-users mailing
list. (I don't read debian-accessibility, but both other lists.) I
also allowed myself to Bcc some other heavy screen users I know
personally.

So if you use Screen's braille features (whatever they are exactly) or
any other of the explicitly listed features in the mail below, and
want to continue to using them, please speak up now. Upstream is also
in need of someone testing (and maybe maintaining) that code.

One potentially to be removed screen feature which IIRC is used by
Grml by default is the nethack mode with a little bit more cryptic
screen messages than by default. Not sure how mission-critical that
one is. ;-)

----- Forwarded message from Amadeusz S?awi?ski <amade at asmblr.net> -----
Date: Wed, 2 Apr 2014 19:47:21 +0200
From: Amadeusz S?awi?ski <amade at asmblr.net>
To: screen-devel at gnu.org
Subject: Re: [screen-devel] screen maintainer

[?]

* new features (256 colors in hardstatus, hardstatus on top,
truecolor, ...)

[?]

* removal of ancient code (removed most of #ifdef for ancient
systems)

[?]

I fear that this may cause a lot of breakage. Linux(*) is by far not
the only platform for Screen out there.
(*) You wrote earlier that you only tested your code on Linux. Linux
is by far not the only platform, GNU Screen runs on.

That's why I warn before hand. Screen is project which accumulated more
then 25 years of code according to copyrights. And while it may be
interesting to historians, I think it's time source is stripped of
those workarounds and retested on machines people use, because it's
likely that it just works with far fewer hacks, than it had.

* removal of features which didn't seem useful or could be replaced

[?]

Please list which features you removed, so that people at least have a
chance to object.

[?]

That's why I want to talk about it before I do anything drastic, one of
reasons I tried to describe my changes at least a bit ;)
multiuser - seemed more like security risk to me
braille - couldn't test :(
utmp - seemed broken and there is also utmpx?
nethack - funny, but who really needs it?
zmodem - according to wiki some ancient file transfer protocol
there may be something else...

[?]

I want to make sure that screen stays as usable as it is to people who
use it, but also would like to see new stuff happening, that's why I
started this talk.

Amadeusz
----- End forwarded message -----

Regards, Axel

[Klaus Ethgen]

Hi,

I also allowed myself to Bcc some other heavy screen users I know
personally.

I am one of the Bcc-ed people. I heard from the feature drop directly
from Axel. As I am using screen for long time now and also some of the
questioned features, I would like to raise my voice against the removal.

multiuser - seemed more like security risk to me

I use this feature to have stuff run as root but allow the user (me) to
just look at the command output and close screen:
acladd klaus
aclchg klaus -wx "#?"
aclchg klaus +x "detach"
multiuser on

There might be other use cases I do not use but it is best to do as
little as possible as root and do all the rest from a normal user
account. (And no, I do not like sudo. ;-)

braille - couldn't test :(

Cannot say some about. But I don't like the idea to lock out handicap
people.

nethack - funny, but who really needs it?

No, please not! :-) It makes screen a bit more fun.

Well, not really a feature that is used for the functionality. But it
extends my life by making me smile some times.

Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <Klaus at Ethgen.de>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C

[Don Raikes]

Amadeusz,

If you can't test Braille support, don't just remove it, ask for help testing.

I would be happy to test Braille support on Linux, and I am sure there are others who would be willing to test as well.

I haven't ever used the screen package per se, but I am a strong proponent for ensuring things at least stay as accessible as they are if not improve.

-----Original Message-----
From: Axel Beckert [mailto:abe at debian.org]
Sent: Wednesday, April 02, 2014 1:30 PM
To: grml at ml.grml.org; debian-accessibility at lists.debian.org
Cc: Amadeusz S?awi?ski
Subject: Some features may be dropped from GNU Screen in the future (including braille support)

Hi,

on the GNU Screen development mailing list, there's currently a thread which discusses how to get some drive in the GNU Screen development again.

Amadeusz S?awi?ski (Cc'ed) has a git repo with some a little bit more disruptive changes at https://github.com/amade/screen/tree/devel/src

In the following mail he describes what he changed and removed. (I've shortened the mail. "[?]" show points where I removed parts. Full mail at https://lists.gnu.org/archive/html/screen-devel/2014-04/msg00008.html)

One of the GNU Screen feature which are about to be dropped in the future is Screen's braille support. (Which is not enabled in Debian's screen package as far as I can see.)

I know that there are quite some visually handicapped Grml users, so I send this mail to the debian-accessibility mailing list and the general Grml mailing list. Reply-To is set to the screen-users mailing list. (I don't read debian-accessibility, but both other lists.) I also allowed myself to Bcc some other heavy screen users I know personally.

So if you use Screen's braille features (whatever they are exactly) or any other of the explicitly listed features in the mail below, and want to continue to using them, please speak up now. Upstream is also in need of someone testing (and maybe maintaining) that code.

One potentially to be removed screen feature which IIRC is used by Grml by default is the nethack mode with a little bit more cryptic screen messages than by default. Not sure how mission-critical that one is. ;-)

----- Forwarded message from Amadeusz S?awi?ski <amade at asmblr.net> -----
Date: Wed, 2 Apr 2014 19:47:21 +0200
From: Amadeusz S?awi?ski <amade at asmblr.net>
To: screen-devel at gnu.org
Subject: Re: [screen-devel] screen maintainer

[?]

* new features (256 colors in hardstatus, hardstatus on top,
truecolor, ...)

[?]

* removal of ancient code (removed most of #ifdef for ancient
systems)

[?]

I fear that this may cause a lot of breakage. Linux(*) is by far not
the only platform for Screen out there.
(*) You wrote earlier that you only tested your code on Linux. Linux
is by far not the only platform, GNU Screen runs on.

That's why I warn before hand. Screen is project which accumulated more then 25 years of code according to copyrights. And while it may be interesting to historians, I think it's time source is stripped of those workarounds and retested on machines people use, because it's likely that it just works with far fewer hacks, than it had.

* removal of features which didn't seem useful or could be replaced

[?]

Please list which features you removed, so that people at least have a
chance to object.

[?]

That's why I want to talk about it before I do anything drastic, one of reasons I tried to describe my changes at least a bit ;)
multiuser - seemed more like security risk to me braille - couldn't test :( utmp - seemed broken and there is also utmpx?
nethack - funny, but who really needs it?
zmodem - according to wiki some ancient file transfer protocol there may be something else...

[?]

I want to make sure that screen stays as usable as it is to people who use it, but also would like to see new stuff happening, that's why I started this talk.

Amadeusz
----- End forwarded message -----

Regards, Axel
--
,''`. | Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5