Re: [9fans] Object Icon, drawterm, riox
they don't. On Mon, Jan 27, 2020, 11:00 PM Anthony Sorace wrote: > I get why someone might want those rio changes, even if they're not for me > (although some I'm curious about). But can anyone help me understand why > what they've done to drawterm is desirable? I can't say that resizing the > window to change the scale factor has ever seemed like something I'd want. > How do they use this? > > > On Jan 4, 2020, at 3:04 , Mark van Atten wrote: > > > > For whomever may find this of interest -- the Object Icon project, > > mentioned on this list in passing in August 2018, also caters to Plan > > 9: > > > > The Object Icon object-oriented programming language: > > http://objecticon.sourceforge.net/ > > > > Of wider use may be its version of drawterm > > http://objecticon.sourceforge.net/Drawterm.html > > and its (much) modified rio > > http://objecticon.sourceforge.net/Riox.html > > > > Mark. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T888cf1c8059b63ab-M071458b168c4aa7686ecc2ec Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Object Icon, drawterm, riox
I get why someone might want those rio changes, even if they're not for me (although some I'm curious about). But can anyone help me understand why what they've done to drawterm is desirable? I can't say that resizing the window to change the scale factor has ever seemed like something I'd want. How do they use this? > On Jan 4, 2020, at 3:04 , Mark van Atten wrote: > > For whomever may find this of interest -- the Object Icon project, > mentioned on this list in passing in August 2018, also caters to Plan > 9: > > The Object Icon object-oriented programming language: > http://objecticon.sourceforge.net/ > > Of wider use may be its version of drawterm > http://objecticon.sourceforge.net/Drawterm.html > and its (much) modified rio > http://objecticon.sourceforge.net/Riox.html > > Mark. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T888cf1c8059b63ab-M55c31e4cc43ac291fd03f75b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Getting git9 -- moved to github.
вс, 19 янв. 2020 г. в 20:04, : > I realized that a few people were still running the hg repo. > It's buggy and no longer maintained (and now, gone). Git9 is > self-hosting on github now. > > To bootstrap git9: > > hget https://github.com/oridb/git9/archive/master.tar.gz > > git9-master.tar.gz > tar xzf git9-master.tar.gz > cd git9-master > mk install > > If you want to get the bugfixes and new features > that will eventually show up (commit grafting, > https clone, stable ids on git/import, ...): > > git/clone git://github.com/oridb/git9 > cd git9 > mk install > > And then update occasionally with > > git/pull && mk install > -- С наилучшими пожеланиями Жилкин Сергей With best regards Zhilkin Sergey -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9c456b888b0c38ed-M703091162ae7a8a6fa7d4cb6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] factotum vs. SASL+TLS+applications
> The following is all hypothetical. I'm curious about how people > think auth(2)/factotum(4) could be adapted to support the use > case ... > > factotum was intended to handle the authentication dance on behalf > of network apps. But in the case of things like IMAP, it really > just stores the client's login/password, and provides a bit of > helper glue for CRAM-MD5. Similarly for ftpfs. > > I'm curious why upasfs and ftpfs are outliers in only using factotum > as a credential store, but leaving the actual authentication protocol > dance in the clients/servers. The "Security" paper (/sys/doc/auth) > strongly hints that these parts of the application protocols were > meant to be outsourced to factotum. Section 2.2 in particular > argues that the auth modules should be implemented once in factotum, > for consumption by the rest of the system. Probably simple expediency. > > > To require a specific SASL mechanism, add "sasl=scram-md5" (using > "sasl=*" as a default if you need to fall back for some reason). This all sounds fairly reasonable. I think that patches to this effect would be worth integrating. > Of course all of this needs to be glued into auth(2) in a way that > doesn't destroy the existing API. But it does need to handle > factotum replacing the underlying connection to the client/server > with one that has been pushtls()ed by factotum itself. I'm not sure how factotum can have this action at a distance. I think the pushtls is stuck in the client itself -- though, the auth code can probably return the parameters needed for this. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8154f8e7b95f1a8c-M16c4ed9e42454938bd4e69b7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
