Re: [9fans] porting projects...
On 04/09/2021, hiro <23h...@gmail.com> wrote: > it's worth doing the plan9 specific protocol anyway. > mainly bec. it could be very simple to implement, between multiple > plan9, given that /dev/mouse is already network transparent. I can't think how Plan 9 would work as a server (as in, the machine with the mouse plugged in) for this (either for Synergy or an invented-here thing). /dev/mouse doesn't emit when you're off the screen. Maybe this is even the reason cinap never did a server, only a client. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M0feff3e2659e016d8f423fa9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
it's worth doing the plan9 specific protocol anyway. mainly bec. it could be very simple to implement, between multiple plan9, given that /dev/mouse is already network transparent. also, when you want other systems, with drawterm the /dev/mouse of the alien OS window is already made available. should be easy enough to extend this and allow a full-screen mouse grab... On 9/4/21, Steve Simon wrote: > > i was going to mention barrier but couldn’t remember it’s name. as far as > the plan9 code goes they should both work - the only difference being the > initial handshake message. > > current synergy supports many new features but plan9 is not interested. > > the problem is really the lack of documentation, the best info is a very > simple example client, but even that has bugs it seems. > > i even considered writing a new plan9 specific protocol but that would mean > delving into the internals of osx to hook it in… > > -Steve > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M5f0eaa770713abcbe3549725 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
i was going to mention barrier but couldn’t remember it’s name. as far as the plan9 code goes they should both work - the only difference being the initial handshake message. current synergy supports many new features but plan9 is not interested. the problem is really the lack of documentation, the best info is a very simple example client, but even that has bugs it seems. i even considered writing a new plan9 specific protocol but that would mean delving into the internals of osx to hook it in… -Steve -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M214a2733c8807d89a1923923 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
https://github.com/debauchee/barrier > On Sep 4, 2021, at 9:19 AM, hiro <23h...@gmail.com> wrote: > > >> >> i tried and faild to get cinap’s historic synergy client to work with a >> current synergy server on windows/linux/osx etc. > > the guy behind synergy at some point tried to convert his free > software project into a startup for making money. > even before that transition he was a hell to send patches to. i don't > recommend depending on this rude person in any form at all. > > instead maybe there's a synergy fork somewhere based on the older free > code. that should be no big deal to keep around forever. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-Mfff2322174718698f16e019a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
> i tried and faild to get cinap’s historic synergy client to work with a > current synergy server on windows/linux/osx etc. the guy behind synergy at some point tried to convert his free software project into a startup for making money. even before that transition he was a hell to send patches to. i don't recommend depending on this rude person in any form at all. instead maybe there's a synergy fork somewhere based on the older free code. that should be no big deal to keep around forever. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M6295cc17a8a74981f4a3bb04 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
On Sat, Sep 4, 2021 at 10:04 AM Philip Silva via 9fans <9fans@9fans.net> wrote: > > Not sure if it's wasted/duplicate effort but I had been interested in porting > QuickJS (it has ES 2020 support) Eventually I stopped doing this since there > is Duktape (within Netsurf) and Goja now support some of the most common ES6 > features. Also my C knowledge/porting experience is quite limited. https://git.sr.ht/~ft/quickjs I have not finished it, ofc, but it successfully ran a few scripts on 9front amd64. Quickjs uses uint128_t which makes everything much more complicated. I don't know if kencc should support 128 bit _just_ to make JS work. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-Ma50a2d9f9260f8529c866dfa Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
Quoth Conor Williams : > anyone got a list/one project to work on... > i'm not too shoddy at the auld porting etc...cw Find something you want to use, and make it work. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-Me2c1e9564408f21d43f3534b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
i will bite i tried and faild to get cinap’s historic synergy client to work with a current synergy server on windows/linux/osx etc. the biggest pain is the wireshark disector is buggy and there is no real documentation for the protocol. not really selling it am i? -Steve -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M0f403a613eac464f4c7615a3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] porting projects...
Not sure if it's wasted/duplicate effort but I had been interested in porting QuickJS (it has ES 2020 support) Eventually I stopped doing this since there is Duktape (within Netsurf) and Goja now support some of the most common ES6 features. Also my C knowledge/porting experience is quite limited. Philip -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M067fe527d54128af356daf61 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9hybrid on T61 - work in progress (small beginnings?)
On 4 September 2021 08:27:21 CEST, Lucio De Re wrote: > The combination of (IBM/Lenovo ThinkPad) T60 chassis and T61 mother > board is known as FrankenPad, I learnt since I bought a none too well > refurbished Lenovo T61 7659-CTO laptop for a moderate price. I had > long wished I could get a T61, so that was some impulsive buying. > > Maybe I should have spent the money (my guess is around $ 100 US) on a > brand new Raspberry Pi I've also been wishing for, but I could not > resist. > > The 9front fraternity may be pleased to hear that this new addition to > my stable of obsolete equipment is currently capable of running both > 32-bit and 64-bit versions of 9front - I just realised I'll need to > compile executables for both architectures indefinitely, I wonder how > many times that will bite me? > > To run under 32 bits I resorted to network booting (from my long > suffering traditional Plan 9 network server), but that won't load the > 64-bit kernel, complaining that it is too big. I tried compressing it, > but netbooting no longer supports compression. I paired down the > kernel a bit, but seemingly not enough. I presume 9front has ways to > netboot a 64-bit kernel, but it isn't critical, yet - it would just > fill what is a rather obvious hole that 9front and 9legacy (for want > of a more suitable moniker - 9pf doesn't seem right) seem to suffer > from differently. > > And, yes, this could be the start of a long, offline whinge about > differences, I have long evolved a flameproof skin for this particular > purpose. But first, let me tell my cautionary tale, it was quite an > adventure and I am happy to act as proxy for those who may want to go > in a similar direction. > > I had the idea to install both 9front and 9legacy on the T61 and > thought I might run cwfs in the former case after discovering then > that 9front has enhanced cwfs - which I have never used, but did for a > long time use kenfs standalone - so I followed their lead for that. > For 9legacy, I'm fine with fossil/venti, it has saved my bacon a few > times and I respect its capabilities fully. > > So, where should I have started? Obviously, this being the > non-deterministic world of New Computing (TM), I followed my head and > installed 9front - no one argues that it is the one most likely to > work on a T61. > > I can't quite recall how, but I managed to do something that in > retrospect was not a great idea: I set up two Plan 9 primary > partitions using Linux Mint off a USB stick - Windows was just not an > option, in my experience, for editing partition tables. I left Windows > 7 Professional installed, but shrank the partition to a safe, much > smaller size - that left some scar tissue, incidentally, but > irrelevant to this tale. > > The 9front installation completed without any memorable trouble and I > left the boot loader unchanged (as instructed). Somehow, boot > selection didn't work as I wished and I blamed the double partition > for my woes. Time to start again, this time with the 9legacy bootstrap > that I was in any case more comfortable with and only one, combined > Plan 9 partition. It looks as if 9front used the same partitioning > scheme as 9legacy. > > I got some idea of partition allocations to "other", "fscache" and > "fsworm" from a recent disk/prep display, so I decided to configure > the drive with fossil and venti partitions, leaving enough space for > 9front, when I would eventually re-install it. > > The 9legacy installation almost, almost worked. I assigned half the > plan9 partition to fossil, arenas, isect and bloom and left space for > 9front. I assumed that nvram and 9fat would need to be shared. > > Except I got some spurious errors in the very last stage of writing > the bootstrap loader and what looked like an otherwise happy > installation simply could not be completed. I could not get past the > final stage of 9legacy installation. The complaint was that 9fat could > not be created, or perhaps something could not be written to that > partition - from memory, it was the error one encounters after a > server connection has failed. At that point only a reboot made sense > to me. > > Of course, rebooting with the plan9 partition active didn't do > anything useful. It's likely that this is when I also discovered that > the Windows partitions were no longer recognised as bootable. That > lost me the Windows recovery capability on the drive, but that was > never an essential, no regrets. > > With a partially complete 9legacy installation, the time had come to > see what 9front was good for. So I repeated that installation. When > the time came to allocate disk space, however, 9front installation had > no record of the previous content of the plan9 partition. As I had > started to keep track of such things, I just proceeded with manual > partitioning (not as wisely as I imagined, I am only now discovering). > > I set up all the partitions I could think of - and made a few > judgemental
[9fans] 9hybrid on T61 - work in progress (small beginnings?)
The combination of (IBM/Lenovo ThinkPad) T60 chassis and T61 mother board is known as FrankenPad, I learnt since I bought a none too well refurbished Lenovo T61 7659-CTO laptop for a moderate price. I had long wished I could get a T61, so that was some impulsive buying. Maybe I should have spent the money (my guess is around $ 100 US) on a brand new Raspberry Pi I've also been wishing for, but I could not resist. The 9front fraternity may be pleased to hear that this new addition to my stable of obsolete equipment is currently capable of running both 32-bit and 64-bit versions of 9front - I just realised I'll need to compile executables for both architectures indefinitely, I wonder how many times that will bite me? To run under 32 bits I resorted to network booting (from my long suffering traditional Plan 9 network server), but that won't load the 64-bit kernel, complaining that it is too big. I tried compressing it, but netbooting no longer supports compression. I paired down the kernel a bit, but seemingly not enough. I presume 9front has ways to netboot a 64-bit kernel, but it isn't critical, yet - it would just fill what is a rather obvious hole that 9front and 9legacy (for want of a more suitable moniker - 9pf doesn't seem right) seem to suffer from differently. And, yes, this could be the start of a long, offline whinge about differences, I have long evolved a flameproof skin for this particular purpose. But first, let me tell my cautionary tale, it was quite an adventure and I am happy to act as proxy for those who may want to go in a similar direction. I had the idea to install both 9front and 9legacy on the T61 and thought I might run cwfs in the former case after discovering then that 9front has enhanced cwfs - which I have never used, but did for a long time use kenfs standalone - so I followed their lead for that. For 9legacy, I'm fine with fossil/venti, it has saved my bacon a few times and I respect its capabilities fully. So, where should I have started? Obviously, this being the non-deterministic world of New Computing (TM), I followed my head and installed 9front - no one argues that it is the one most likely to work on a T61. I can't quite recall how, but I managed to do something that in retrospect was not a great idea: I set up two Plan 9 primary partitions using Linux Mint off a USB stick - Windows was just not an option, in my experience, for editing partition tables. I left Windows 7 Professional installed, but shrank the partition to a safe, much smaller size - that left some scar tissue, incidentally, but irrelevant to this tale. The 9front installation completed without any memorable trouble and I left the boot loader unchanged (as instructed). Somehow, boot selection didn't work as I wished and I blamed the double partition for my woes. Time to start again, this time with the 9legacy bootstrap that I was in any case more comfortable with and only one, combined Plan 9 partition. It looks as if 9front used the same partitioning scheme as 9legacy. I got some idea of partition allocations to "other", "fscache" and "fsworm" from a recent disk/prep display, so I decided to configure the drive with fossil and venti partitions, leaving enough space for 9front, when I would eventually re-install it. The 9legacy installation almost, almost worked. I assigned half the plan9 partition to fossil, arenas, isect and bloom and left space for 9front. I assumed that nvram and 9fat would need to be shared. Except I got some spurious errors in the very last stage of writing the bootstrap loader and what looked like an otherwise happy installation simply could not be completed. I could not get past the final stage of 9legacy installation. The complaint was that 9fat could not be created, or perhaps something could not be written to that partition - from memory, it was the error one encounters after a server connection has failed. At that point only a reboot made sense to me. Of course, rebooting with the plan9 partition active didn't do anything useful. It's likely that this is when I also discovered that the Windows partitions were no longer recognised as bootable. That lost me the Windows recovery capability on the drive, but that was never an essential, no regrets. With a partially complete 9legacy installation, the time had come to see what 9front was good for. So I repeated that installation. When the time came to allocate disk space, however, 9front installation had no record of the previous content of the plan9 partition. As I had started to keep track of such things, I just proceeded with manual partitioning (not as wisely as I imagined, I am only now discovering). I set up all the partitions I could think of - and made a few judgemental mistakes, it turns out, but I didn't notice, so I could actually continue. The completed 9front installation this time included the 9front boot loader - which I will have to become more familar with, for obvious reasons. I have accepted that
