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@asmblr.net ----- Date: Wed, 2 Apr 2014 19:47:21 +0200 From: Amadeusz Sławiński amade@asmblr.net To: screen-devel@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 ;)
From fast comparing between source files:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
Am Mi den 2. Apr 2014 um 21:29 schrieb Axel Beckert:
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@Ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
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@debian.org] Sent: Wednesday, April 02, 2014 1:30 PM To: grml@ml.grml.org; debian-accessibility@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@asmblr.net ----- Date: Wed, 2 Apr 2014 19:47:21 +0200 From: Amadeusz Sławiński amade@asmblr.net To: screen-devel@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 ;)
From fast comparing between source files:
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@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
Don Raikes DON.RAIKES@ORACLE.COM wrote:
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.
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`
On Apr 2, 2014, at 4:38 PM, Jason White jason@jasonjgw.net wrote:
Don Raikes DON.RAIKES@ORACLE.COM wrote:
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@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://blog.grml.org/
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
Samuel Thibault samuel.thibault@gnu.org wrote:
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 samuel.thibault@gnu.org writes:
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*.
participants (7)
-
Axel Beckert -
Don Raikes -
Jason White -
John G. Heim -
Klaus Ethgen -
Mario Lang -
Samuel Thibault