Re: [9front] vncs: some clients report 'bad hextile data'

Re: [9front] vncs: some clients report 'bad hextile data'

[cinap_lenrek]

yeah... i tried a bunch of vnc client and server implementations on windows
when testing and each one seems to have something lacking. i had to try like
4 experimental builds of ultravnc until it started listening on ipv6 address
using obscure undocumented .ini settings.

the best working linux implementation seems to be tigervnc.

good luck.

--
cinap

Re: [9front] vncs: some clients report 'bad hextile data'

[Steve Simon]

i know its functionally a bit different but you could try remote desktop to windows.

i use rd(1) to talk to windows from plan9. it occasionally dies due to message decode failures, but a reconnect only takes 2 or 3 secs so i live with it.

-Steve


> On 1 Feb 2019, at 5:03 pm, cinap_lenrek@felloff.net wrote:
> 
> yeah... i tried a bunch of vnc client and server implementations on windows
> when testing and each one seems to have something lacking. i had to try like
> 4 experimental builds of ultravnc until it started listening on ipv6 address
> using obscure undocumented .ini settings.
> 
> the best working linux implementation seems to be tigervnc.
> 
> good luck.
> 
> --
> cinap

Re: [9front] vncs: some clients report 'bad hextile data'

[Ethan Gardener]

On Fri, Feb 1, 2019, at 5:03 PM, cinap_lenrek@felloff.net wrote:
> yeah... i tried a bunch of vnc client and server implementations on windows
> when testing and each one seems to have something lacking. i had to try like
> 4 experimental builds of ultravnc until it started listening on ipv6 address
> using obscure undocumented .ini settings.

This fits with my general experience of semi-obscure open source software.  I'm sure the extensibility of the VNC standard doesn't help.

> the best working linux implementation seems to be tigervnc.
> 
> good luck.

Thanks!


On Fri, Feb 1, 2019, at 6:36 PM, Steve Simon wrote:
> i know its functionally a bit different but you could try remote desktop 
> to windows.
> 
> i use rd(1) to talk to windows from plan9. it occasionally dies due to 
> message decode failures, but a reconnect only takes 2 or 3 secs so i 
> live with it.

I'm going the other way, using Windows for desktop and gaming.  Plan 9's interfaces are so free of unnecessary details that it's better as the remote box.  I suppose I 'should' be using drawterm, but I keep screwing up Plan 9's authentication.

At present, Plan 9 is this weird thing I can't live with and can't live without. (lol)  I very much don't have the right aptitudes to read the C code, and I've failed to find a work-around in 10 years.  Because of this, I can't understand the auth system.  Auth documentation is confusing and wrong, reading the source is the way to understand it.  At the same time, parts of the userspace are just so good that I can't do without them.  So is the dump filesystem.  

Maybe I should switch to Inferno because it relies less on C and has a different auth scheme.  The trouble is there are more bugs to fix.  And it always strikes me as a child that doesn't know what it wants to be when it grows up. :)  *And* most Inferno devs moved on to Go 7 years ago.  A new generation is starting to appear, but only starting.

I am starting to develop my own system which will suit me as much as I can make it do so, but I can't rely on vaporware even when I'm the one producing the vapor. ;)  It's possible I might be stymied by whatever fault prevents me understanding Plan 9's C code.  I do hope not. >:(

Re: [9front] vncs: some clients report 'bad hextile data'

[hiro]

well a lot has changed with dp9ik, but i really really like the idea
of the separate auth server. i wish more people would understand the
benefits.
if you cannot deal with it we have to become better. so please pester
us about it.

the rest is off-topic ramble:
otherwise we have to deal with "password changing days", where people
are supposed to login to dozens of websites and change dozens of
unique passwords, where every time you have to try 3 times, because
they are always too short, too long or containing to little or too
many special characters. (as if making dozens of unique passwords
wasn't hard enough).

in the best case this means MANUALLY copy&pasting something very
random from some password generator, in the worse case everybody
forgot most of their new passwords right away, or the password
manager's encrypted storage gets corrupted.

and the result is that regardless of how secure and unique those
passwords might be, everybody has to keep on clicking "forgot my
password" links anyway, resulting in all mails to be sent in plaintext
to some single-point-of-failure mail address.

every web service seems agree your mail address is the most trustable
thing ever. sadly, this means passwords are rendered mostly
irrelevant.

On 2/2/19, Ethan Gardener <eekee57@fastmail.fm> wrote:
> On Fri, Feb 1, 2019, at 5:03 PM, cinap_lenrek@felloff.net wrote:
>> yeah... i tried a bunch of vnc client and server implementations on
>> windows
>> when testing and each one seems to have something lacking. i had to try
>> like
>> 4 experimental builds of ultravnc until it started listening on ipv6
>> address
>> using obscure undocumented .ini settings.
>
> This fits with my general experience of semi-obscure open source software.
> I'm sure the extensibility of the VNC standard doesn't help.
>
>> the best working linux implementation seems to be tigervnc.
>>
>> good luck.
>
> Thanks!
>
>
> On Fri, Feb 1, 2019, at 6:36 PM, Steve Simon wrote:
>> i know its functionally a bit different but you could try remote desktop
>> to windows.
>>
>> i use rd(1) to talk to windows from plan9. it occasionally dies due to
>> message decode failures, but a reconnect only takes 2 or 3 secs so i
>> live with it.
>
> I'm going the other way, using Windows for desktop and gaming.  Plan 9's
> interfaces are so free of unnecessary details that it's better as the remote
> box.  I suppose I 'should' be using drawterm, but I keep screwing up Plan
> 9's authentication.
>
> At present, Plan 9 is this weird thing I can't live with and can't live
> without. (lol)  I very much don't have the right aptitudes to read the C
> code, and I've failed to find a work-around in 10 years.  Because of this, I
> can't understand the auth system.  Auth documentation is confusing and
> wrong, reading the source is the way to understand it.  At the same time,
> parts of the userspace are just so good that I can't do without them.  So is
> the dump filesystem.
>
> Maybe I should switch to Inferno because it relies less on C and has a
> different auth scheme.  The trouble is there are more bugs to fix.  And it
> always strikes me as a child that doesn't know what it wants to be when it
> grows up. :)  *And* most Inferno devs moved on to Go 7 years ago.  A new
> generation is starting to appear, but only starting.
>
> I am starting to develop my own system which will suit me as much as I can
> make it do so, but I can't rely on vaporware even when I'm the one producing
> the vapor. ;)  It's possible I might be stymied by whatever fault prevents
> me understanding Plan 9's C code.  I do hope not. >:(
>

Re: [9front] vncs: some clients report 'bad hextile data'

[cinap_lenrek]

not sure if this is really a issue with the hextile encoding. you could
comment out the EncHextile case in setencoding() in vncs.c to exclude it.

to really fix it you need to understand what realvnc's problem is... so
look there. then you can come up with a proper work arround.

--
cinap

Re: [9front] vncs: some clients report 'bad hextile data'

[Ethan Gardener]

On Thu, Jan 31, 2019, at 6:04 PM, cinap_lenrek@felloff.net wrote:
> not sure if this is really a issue with the hextile encoding. you could
> comment out the EncHextile case in setencoding() in vncs.c to exclude it.

I could try that.

> to really fix it you need to understand what realvnc's problem is... so
> look there. then you can come up with a proper work arround.

Yeess, but it's closed source. :<  

Ah!  I could run TightVNC on my new laptop, it's open source.  It's a little clunkier but it will do.  Just tried it, it works.  I think I'll stick with TightVNC because A: I won't be using it much, and B: RealVNC no longer have a link to download their viewer on their front page.

Anecdotally, I haven't been using TightVNC on my desktop because Windows makes it fuzzy.  If you tell Windows to increase font size, it blurrily scales the display of programs which don't support it.  (KHM, are you laughing? :)  My desktop is Win7 so I can mitigate the problem by selecting a theme that looks like Windows 95 *eye-roll* :) but that doesn't work for TightVNC.  My laptop is Win10, they cleaned up the theming, so I've just set the font scale to 100% and settled for having to peer at menus.  It won't be too bad because I won't be using it as much as the desktop.