Re: [9fans] Autoexpand in sam

[Ethan Gardener]

On Wed, Sep 22, 2021, at 9:14 PM, revcomni...@gmail.com wrote:
> Is there a way to implement autoexpand and autocorrect in sam in any 
> way, i.e. for common spelling mistakes and commonly used phrases? 

I once wrote a script with several regexp substitutions, but gave up when I 
realised I'd need to implement an entire dictionary. I often typed 'ign' for 
'ing', but words legitimately ending in 'ign' are surprisingly common. I tried 
to make the regexp smarter, but ended up using it on individual words, 
double-clicking each incorrect word and running |ac . This was quick enough in 
Acme, perhaps not bad in Sam. I'd attach the script, but it's long since lost 
now.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T0e2541a723ce90e5-Mdd6a9a834feaa1e84d555c90
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] GSoC 2021 project ideas

[Ethan Gardener]

On Mon, Sep 20, 2021, at 12:05 PM, sirjofri wrote:
> 9front on pinephone is actually a project I'm interested in. I checked 
> out some details:
>
> The pinephone boot loader can boot from ext4 partition, so it seems 
> possible. We'd have to use some ext4 filesystem (eg the one made by 
> sigrid) and add it to the boot filesystem.
>
> With a bit of luck (and proper arm compatibility) we can then get a 
> 9front pinephone booting, maybe even with some screen. I expect many 
> things to not work (networking, touchscreen, WAN and lots of other phone 
> hardware stuff), but if we get the base system running and some 
> networking we already have something usable.

It'll be interesting to see how it goes. :) The pinephone's docking bar 
supports wired ethernet which will likely ease development.

> The most complex task is designing a proper plan 9-worthy touchscreen 
> interface and developing apps for that.

What do you think of p9p's support for multitouch as an alternative to chords? 
I recall it was well-received.

Ooh! Pine64 have announced they're developing a keyboard inspired by the Psion 
series 4. I was just thinking a keyboard would reduce the need for a clever 
interface.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T39aec8f3f9d8503d-Mb80f77bec7835ce3d65ad19f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] GSoC 2021 project ideas

[Ethan Gardener]

On Mon, Sep 20, 2021, at 9:23 AM, hiro wrote:
> i think the main reason people are willing to fall for the android
> platform is bec. there is no good long-term supply of updated phone
> hardware with backwards-compatible interfaces.

Probably, but when do Linux kernel interfaces remain backwards-compatible? :) 
I've seen the sysfs battery-monitoring files change beyond all recognition.

> a lot of qualcomm and mediatek chipsets are being built, but instead
> of documentation they only ship half-baked linux drivers, which are
> often not even mainlined.
>
> those linux drivers are already hard to make work on actual linux
> distributions, or even on android distributions.
>
> who wants to reverse-engineer the hardware over and over again based
> on such linux drivers...

Quite, but feeling such pressure may be based on a false perspective. I've had 
3 phones in the last 8 years, and I've upgraded to avoid falling too far behind 
with Android rather than carrier changes or hardware failures. The first of my 
3 phones is capable of 4G, so I could have upgraded only once or even not at 
all. It's still in perfect condition. If you're not concerned with keeping up 
with Android or feeding poor impoverished phone manufacturers and the many 
shareholders who depend on them, ;-) then upgrading once every 5 years is 
entirely fine and once every 10 years may be acceptable. I think that cuts down 
the workload a bit. :)

On the other hand, using parts of Android is a way to make use of hardware you 
already value. I keep trying to think of ways to use my 8 year old phone 
because it's the only phone I've ever had with adequate sound quality. Perhaps 
I should just ask about sound quality on... maybe XDA forums or something.

> On 9/20/21, Ethan Gardener  wrote:
>> tl;dr: forget inferno, port plan 9 to the pine phone.
>>
>> On Mon, Sep 20, 2021, at 6:43 AM, Dave Eckhardt wrote:
>>> > Anyone know if this project went anywhere?
>>> >
>>> > https://www.cs.cmu.edu/~412/lectures/L05_Purge_Proposal.pdf
>>
>> I had to laugh at one of the slides. Inferno running natively on "x86
>> supercomputer"? I think implementing multicore support would be a first
>> step, not to mention 64-bit! While it would be nice if those jobs were done,
>> they will take time and effort. Overall, if porting natively, I see little
>> sense in preferring Inferno to Plan 9, especially as Plan 9 already supports
>> 64-bit multicore.
>>
>>> Sadly, not.  One issue is that modern Android releases don't
>>> support 32-bit executables, and at the time that project was
>>> attempted Inferno was somewhat 32-bit (I haven't looked since).
>>
>> Recalling the issues Hellaphone had and the time it took, I'm of the opinion
>> that getting Inferno to work on any given phone's Linux kernel is hardly
>> more worthwhile than porting it directly to the hardware. The kernels have
>> undocumented interfaces.
>>
>> A current thread on OSdev (operating system development) forums is looking
>> at phones. It's a little rambly, but it reports on some encouraging things.
>> Lots of "baseband processors" (the phone-network communication subsystems)
>> have documented interfaces. There are at least 2 phones available now which
>> are fully open for operating system development: the PinePhone and the
>> Librem 5. (5 is the screen size.) Of the 2, the Pine Phone seems better, not
>> least because it can boot from the SD card; useful for testing.
>> https://forum.osdev.org/viewtopic.php?f=1=53251
>>
>> There's also the option of building your own phone out of components. The
>> thread has some info. I'm guessing most here would prefer a PinePhone.
>>
>>> But I think I saw some recent-ish Inferno-on-Android activity here:
>>>
>>>   https://github.com/bhgv/Inferno-OS-bhgv
>> 
>> That's probably a good source of code. bhgv is a freelance programmer who
>> was very interested in Inferno and made several improvements including
>> Truetype fonts. The last I heard was he tried to find paid work involving
>> Inferno but couldn't, so he didn't have time to work on it.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T39aec8f3f9d8503d-M0e0cfadb099e2b0cef59de10
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] GSoC 2021 project ideas

[Ethan Gardener]

tl;dr: forget inferno, port plan 9 to the pine phone.

On Mon, Sep 20, 2021, at 6:43 AM, Dave Eckhardt wrote:
> > Anyone know if this project went anywhere?
> >
> > https://www.cs.cmu.edu/~412/lectures/L05_Purge_Proposal.pdf

I had to laugh at one of the slides. Inferno running natively on "x86 
supercomputer"? I think implementing multicore support would be a first step, 
not to mention 64-bit! While it would be nice if those jobs were done, they 
will take time and effort. Overall, if porting natively, I see little sense in 
preferring Inferno to Plan 9, especially as Plan 9 already supports 64-bit 
multicore. 

> Sadly, not.  One issue is that modern Android releases don't
> support 32-bit executables, and at the time that project was
> attempted Inferno was somewhat 32-bit (I haven't looked since).

Recalling the issues Hellaphone had and the time it took, I'm of the opinion 
that getting Inferno to work on any given phone's Linux kernel is hardly more 
worthwhile than porting it directly to the hardware. The kernels have 
undocumented interfaces.

A current thread on OSdev (operating system development) forums is looking at 
phones. It's a little rambly, but it reports on some encouraging things. Lots 
of "baseband processors" (the phone-network communication subsystems) have 
documented interfaces. There are at least 2 phones available now which are 
fully open for operating system development: the PinePhone and the Librem 5. (5 
is the screen size.) Of the 2, the Pine Phone seems better, not least because 
it can boot from the SD card; useful for testing.
https://forum.osdev.org/viewtopic.php?f=1=53251

There's also the option of building your own phone out of components. The 
thread has some info. I'm guessing most here would prefer a PinePhone.

> But I think I saw some recent-ish Inferno-on-Android activity here:
> 
>   https://github.com/bhgv/Inferno-OS-bhgv

That's probably a good source of code. bhgv is a freelance programmer who was 
very interested in Inferno and made several improvements including Truetype 
fonts. The last I heard was he tried to find paid work involving Inferno but 
couldn't, so he didn't have time to work on it.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T39aec8f3f9d8503d-Mbb7a2eb707551c328b09736d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] UTF-8 characters in acme

[Ethan Gardener]

On Thu, Sep 9, 2021, at 1:46 PM, revcomni...@gmail.com wrote:
> I came to this impression after reading:
> "Sam edits uninterpreted ASCII text."
> http://doc.cat-v.org/plan_9/4th_edition/papers/sam/

Understandable, but you missed the last paragraph of the abstract, which reads, 
"This paper is reprinted from Software—Practice and Experience, Vol 17, number 
11, pp. 813-845, November 1987. The paper has not been updated for the Plan 9 
manuals. Although Sam has not changed much since the paper was written, the 
system around it certainly has. Nonetheless, the description here still stands 
as the best introduction to the editor." (You're not the only one to miss 
things like this, I do it all the time.)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T0d54d4b593281935-Meaf19165d007ceda21623d19
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] OAuth2 in factotum

[Ethan Gardener]

On Wed, Aug 18, 2021, at 10:18 AM, Keith Gibbs wrote:
> 
> And tools die or are replaced over time.  8 1⁄2 was the standard in Plan 9, 
> but due to it’s limitations and quirks, a new one was written from scratch. 
> Now we, 30 years later, are arguing that every line of code handed down from 
> our honoured and sainted forebears is gospel truth? Really? 

Oh dear! This old argument is getting heated again? I don't miss the old flame 
wars.  But I think the old wars had a somewhat different motive.  Some people 
argued furiously for the "One True Plan 9" and against forks, but as soon as 
the last Plan 9 maintainer left the remains of Bell Labs, most of them just 
stopped posting.  (So did some nicer people.)  They were evidently arguing for 
a maintained system, but they also seemed to be opposed to almost all change.  
Perhaps they were opposed to all change which didn't suit themselves, but the 
more I recall, the less rational these people seem to be.  Sometimes, they'd 
even be furious with someone for doing the very thing they'd told him to do.  
"If you want it, do it yourself," so the person would put a lot of effort in to 
do it, and then they'd be furious with him.  The earliest such incident I know 
of goes back to the very people who developed Plan 9.  With this history, I 
don't particularly want to honor the original Plan 9 and would hate to see the 
wars rekindled.

All the same, there is a surprising practical consideration:

> I think what you are confusing is that since I (and many others, whether on 
> the 9front side or no) want to see Plan 9 evolve and grow, that somehow that 
> will ruin *your* Plan 9.

Unfortunately, this is a more difficult issue than you might think.  If someone 
is reliant on a particular fork and doesn't have the time, energy, or skills to 
make alterations as needed, they can be hurt by changes, even surprisingly 
small changes.  Changing Rio's scrolling behaviour might be trivial, but at a 
time when I was heavily dependent on a particular scrolling behaviour, 9front 
changed it and I had no free time or energy to even think about how to change 
it back.  I switched to an older version of Rio, but then I missed a different 
fix 9front had made.

The more I think about it, the more I think I'd like 9legacy's approach of 
patches over a relatively static system, but I haven't actually tried it and I 
certainly wouldn't want to limit anyone else's choices.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T6899bf3f0654295d-M284a39c35a7dc1abec2c8cb8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] A few questions about sam

[Ethan Gardener]

On Thu, Jul 22, 2021, at 2:38 PM, revcomni...@gmail.com wrote:
> The sam window is not always responsive to commands. Under what specific 
> conditions is this the case?

For completeness, one specific case not mentioned is opening a huge file. For 
each file you open, Sam creates and initializes a temporary file several times 
larger. If you open a gigabyte-size file, the initialization takes a while. 
This may have been optimized away in 9front, but I don't know if they ever saw 
a need to. It's more of an issue in Acme. For instance, working with virtual 
machine files, I used to accidentally click on ISO or HD images instead of tiny 
Qemu launcher scripts and Acme would freeze for minutes.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T60b5c1929a63b077-Mada1f497c4007f10452d40de
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] sam label and rio snarf buffer

[Ethan Gardener]

On Tue, Jul 20, 2021, at 10:27 PM, Stuart Morrow wrote:
> You'll need to reinvent (or change, at least) plumbing if you want
> multiple editors, be it one
> per file or one per project.

I used to use one plumber per project window, where a project window was either 
an instance of acme or a subrio. It worked well for me. When I was setting it 
up, someone suggested some clever plumbing rules instead, but I couldn't 
understand them at the time. Their suggestion is in this list's archives, but I 
can't remember how many years ago it was.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc809ad6007ccd2bd-Mcf34fecc46674557471d7ce6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Alternative to fine-grained mouse usage?

[Ethan Gardener]

On Sun, Jul 4, 2021, at 12:19 AM, Dworkin Muller wrote:
> On Sat, 03 Jul 2021 22:33:07 +0100, "Ethan Gardener" 
>  wrote:
> eekee57> To be honest, it helps that the editor's source code is only
> eekee57> about 2.5KB. ;)
> 
> So you're using the Forth environment as your editor, not just using
> Forth to drive sam or acme?

Correct. The text to be edited is loaded into memory and various words 
(commands) work on that memory. Obviously, it can't handle extremely large 
files as Sam and Acme can.

Some Forths have a namespace system which can keep the editor's words from 
conflicting with others. The Forth I use now doesn't have one, but if I had 
more applications controlled from Forth, I'd want namespacing. One common 
scheme simply replaces the first-searched word list when you enter the name of 
another word list (AKA vocabulary). This is typically extended into something 
complicated; a full vocabulary stack which needs to be managed with care if you 
don't want to lose most of the language by accident, but I intend to keep it 
simple.

I've written an interactive editor too, but I only really use it for editing 
tables in overwrite mode. It would be more useful for writing prose, but you 
can't really do that in 1KB blocks. I actually wrote a command-based text-file 
editor before I started to use blocks, but its command language was awkward. I 
didn't really know the language at the time and I had overly high expectations 
of myself. I'm about ready to try again now.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T716c5aa0e2aa8a27-M5c40e333cc9c6440de1f3fe2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Alternative to fine-grained mouse usage?

[Ethan Gardener]

On Sat, Jul 3, 2021, at 5:32 PM, silas poulson wrote:
>> On 2 Jul 2021, at 19:06, Ethan Gardener  wrote:
>> 
>> This reminds me why I switched to Forth: I can program my editor properly
> 
> Could you expand on this point?
> 
> Vaguely aware of Forth, but no experience with forth editors

Sure. There's a few things.

I like and sometimes make use of the fact that the input language is a full 
systems language. I can access all the editor's variables and memory from the 
input prompt or from my own code. Sometimes it blows up because Forth has even 
fewer safeguards than C, but I soon learned how to avoid the explosions. It 
helps that I now use a Forth which displays the stack contents before each 
prompt; I do recommend that. All this can be summarized with a little misquote: 
"[Forth] does not prevent you doing stupid things because that would also 
prevent you doing clever things." ;) Sometimes I wish for type safety, but now 
I've learned to do without it, it's fine.

Other than that, I make some use of the data stack: I've written several words 
to leave string references on the stack for use by other words, chaining them 
together almost like a pipeline. Sam can do things like this so it's not too 
new, but I can chain anything I like and easily write new commands. I don't 
always chain them on the same line. If there's a memory copy or blank operation 
in there, I'll check the parameters look right first. The check doesn't take a 
second.

Where Sam executes commands in braces "at the same time," not allowing you to 
change the order, I've got full control of the order of execution. In Sam, I 
was never successful in changing text with commands in braces. Sam or Acme 
would always report something about multiple changes at the same time, and Sam 
would corrupt the text a bit. I don't remember exactly what I was trying to do, 
but I was sure it would have worked if my commands were executed in order. In 
Forth by contrast, there's nothing to get commands out of order. I may not be 
working on large files with complex commands any more, but I write sequences of 
simple commands all the time.

To be honest, it helps that the editor's source code is only about 2.5KB. ;) 
Some of that isn't even editor, it's block indexing and multi-block search, but 
I've replaced one and need to replace the other. Actually, I should rewrite the 
editor seeing as I don't want my code GPL-licensed and the editor probably is. 
("Probably"? There's no license in the editor itself, likely because it's hard 
to fit licensing boilerplate into 1KB blocks.)





--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T716c5aa0e2aa8a27-Mdaa9427b1343b7aa707c8979
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Alternative to fine-grained mouse usage?

[Ethan Gardener]

On Sat, Jul 3, 2021, at 3:29 AM, umbrati...@prosimetrum.com wrote:
> nothing's tying you to sam syntax:
> 
> ,|awk '{print NR "\t" $0}'
> 
> then undo.

Good points. I used to pipe through other tools often, and very often used to 
make temporary changes and undo them. Can't remember specific uses now, but I 
remember being very pleased with the temporary-change trick.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T716c5aa0e2aa8a27-M3bbf03fffc996275fbfae648
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Alternative to fine-grained mouse usage?

[Ethan Gardener]

On Fri, Jul 2, 2021, at 7:54 PM, Silas McCroskey wrote:
> > In any case, Plan 9's ed has a nice "browse" command which sam can't match. 
> > I used to issue "0bn", then just "b" once per page. Or, if you don't want 
> > line numbers, leave out the "n".
> 
> "+,+20p" does it. Doesn't work near the end of the file, though; not
> sure if that can be improved within the same expression or you just
> have to know to "+,$p" instead.

Good point, I'd forgotten about that. I used to do it or something like it, but 
hated having to change the expression for the last page, especially when I 
didn't know the last page was next.

> I agree with the camp that considers using line numbers (other than 0)
> in sam (and ed, for that matter) to be something of an anti-pattern,
> so I stopped letting the lack of 'n' bother me a long time ago. I'm
> sure that's not much help for someone who's admitted to giving up on
> regex though; you've got me curious how difficult it'd be to add it.

Yup. If I was entirely comfortable with regexes, I would never have mentioned 
line numbers.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T716c5aa0e2aa8a27-M169fdcccbdad2b6c481dfa4b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Alternative to fine-grained mouse usage?

[Ethan Gardener]

On Fri, Jul 2, 2021, at 4:03 PM, silas poulson wrote:
>> On 1 Jul 2021, at 18:48, Ethan Gardener  wrote:
>> sam -d can't display line numbers
> 
> You can sort of display them via
> 
> ,x {
> p
> }
> 
> Though it’s ugly and annoyingly can’t apply sam’s regex to remove the 
> character locations.

My mail client swallowed the line with the equals sign until I tried to reply. 
If that's happening to anyone else, it's on a line on its own between the 
opening brace and the p.

It does work, but yeah, it's a bit on the ugly side. I can get line & char 
numbers onto the same lines as the text, but only on the ends of the lines 
which is even uglier. It's this:

,x/.*/ {
p
}

The regexp selects whole lines without the newlines. Reversing the order of = 
and p has no effect.

(This reminds me why I switched to Forth: I can program my editor properly 
instead of being constrained by a domain-specific language. But part of the 
problem was I couldn't get my head around Sam's C code. It probably didn't help 
that I started with terminal-editor communication; that was likely the deep end 
of the pool.)

In any case, Plan 9's ed has a nice "browse" command which sam can't match. I 
used to issue "0bn", then just "b" once per page. Or, if you don't want line 
numbers, leave out the "n".
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T716c5aa0e2aa8a27-M93aa1a889014993c1e185d24
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Alternative to fine-grained mouse usage?

[Ethan Gardener]

I used to enjoy Acme, but had to give it up when I no longer had an ergonomic 
desk. Using the mouse hurt too much. In the way I work, often switching files, 
Sam's menus are practically worse than Acme. I tried sam -d (command-line only) 
and ed, but... well, I get in a muddle with regexps. Most people don't, and 
Plan 9's are more regular than most, so I recommend sam -d. It's a bit cleaner 
and more powerful than ed. The weakest point in sam -d is still switching 
files, you have to type whole filenames, but I think if you never use the 
plumber, you won't have to type any full pathnames. You could also use ed. It's 
one-file only, but sam -d can't display line numbers, ed can.

With a usable text editor, you can write temporary scripts to work around the 
issue of reissuing commands. For all but the simplest commands, I prefer that 
way of working to a regular command line. When I needed to write more than 
Acme/Rio features comfortably allowed, I'd name a temporary script tt or ss or 
something. If you don't want to make them in your working directory, you'll 
want a short path for them. Perhaps `bind -bc /tmp/bin /bin` and in sam, `B 
/bin/tt`.

Incidentally, I barely used the scrollbars. I used the up and down arrow keys, 
home and end, or sometimes if I was in a hurry, page up & page down. I did use 
the scrollbars for precise pagination when reading plain-text ebooks or 9front 
commit messages, but I didn't really need to.

As for Rio, from looking at your mail, am I right in saying you know how to 
have the riostart script open windows, and that you can reuse them? I wrote 
scripts to get the screen size and calculate the figures for the window 
corners. I don't know where they are now, but they were very short. The only 
catch is quoting can get funky in this one case of . It's not bad, just some 
surprising runs of ' every time you need a quote.

I'm tired today. I've only just now remembered some other options:

There's also a Vim port. I can't remember if it runs in vt(1) or stand-alone. I 
also can't remember if it's been updated. Perhaps ask in 9front channels, one 
of the regulars was/is a Vim user.

Speaking of vt, if you can find/port/make rlwrap, you could use rc under vt 
with command history and keyboard editing. These features are also nice with 
sam -d or ed. (Yes, Plan 9 purists, I was naughty enough to try it. ;)


On Thu, Jul 1, 2021, at 2:15 AM, Dworkin Muller wrote:
> I have physical issues with trying to perform fine-grained mouse
> operations (uncontrollable small hand tremors).  The net effect is
> that anything more much specific than window selection is difficult
> and takes several seconds - pretty much the antithesis of the study
> results that showed that editing using the mouse to point to where you
> want to type, select text, etc was as efficient as keyboard-driven
> edit.  To give an idea of the scale of the problem, it's difficult to
> get the mouse positioned into the scrollbars or the command bar of
> acme windows, let alone point between two specific characters for
> inserting new text.
> 
> So, my question is, are there any viable alternatives for use with
> Plan9?  Throwing special hardware at the problem unfortunately isn't
> all that viable mainly due to budgetary issues - all the other
> environments I use support keyboard short-cuts for just about
> everything, so it's hard to justify spending any significant amount of
> money for what is essentially a low-priority hobby.
> 
> If the answer is just to use sam, I can do that, but it doesn't really
> help the problem of needing to copy/paste previous commands in
> terminal windows, etc.
> 
> Hopefully I'm missing something obvious
> 
> Thanks.
> 
> Dworkin

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T716c5aa0e2aa8a27-M130b45cec16dbc1eaeb15846
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [OBORONA-SPAM] [9fans] Why is there no simple equivelent to plan9's pipes on linux?

[Ethan Gardener]

On Mon, Jun 28, 2021, at 8:41 PM, lego12...@yandex.ru wrote:
> On Wed, Jun 16, 2021 at 12:02:54PM -0400, Claude Noël wrote:
> > Plan 9 pipes:
> > - can be opened by multiple proccesses
> > - preserve write boundries
> > - will cache a single write
> > - 2 way
> > - simple to use
> > 
> > There's not really anything on linux that really compares to this.
> 
> May be. But what about unix domain sockets?

If you're thinking of purity here, "unix domain sockets" came from BSD and are 
very much unlike the clean design we expect from the authors of Unix. They were 
formerly called "BSD sockets".

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T127c618288a5cd57-Mca340a2ab91c9f58794ba629
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] full fossil follies

[Ethan Gardener]

On Fri, Jun 25, 2021, at 5:45 PM, adr via 9fans wrote:
> 
> In a multi-user environment you can make the file system do something
> similar when the system is full, but instead of starting a console
> session, delete the last file modified and presenting the user
> an error.

The last file modified could be the log file which documents what went wrong. 
;) I thought this through years ago, it's an annoying problem. I think the 
current situation isn't too bad. If I remember right, it's much better than 
CWFS, but I don't remember too clearly. I do remember my early Linux 
experience, trying to arrange several 100-200MB disks in such a way as to have 
both Emacs and X installed at the same time. (Impossible!) I was also root all 
the time because A: I didn't know what it was, and B: non-root authentication 
was broken in that release of that distro and I didn't know how to use the 
patch disks. My tiny disks inevitably filled up and somehow I managed to deal 
with them. (It helped that I had no data to lose, having just lost everything I 
wanted to keep from DOS, but it was still annoying.) It was harder than dealing 
with a full Fossil because Linux had no ramdisk at the time, I don't think 
there were any live CDs, and Linux didn't yet support `init=/bin/sh`. I don't 
think I understood how to start it in runlevel 1, or maybe I did everything in 
runlevel 1 so when that went wrong, I had to do something else. Sometimes, I 
had to unplug all the drives but the root, edit the boot config to make a 
recovery system, plug the drives back in... etc. By comparison, booting a Plan 
9 iso and mounting Fossil is very simple and easy! :D It's essentially the same 
as how I'd repair any OS with a full disk today. Wonderful things, live-CDs.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M0b4c16b88cb43f6182e94a8b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] p9f mention of 9front

[Ethan Gardener]

On Thu, Jun 24, 2021, at 9:51 PM, un...@cpan.org wrote:
> 
>  From
> what I can gather, there was a serious bug that was fixed in fossil
> after 9front forked, and yet there is no intention of including it
> back into 9front.

When I was involved with 9front, there was a dislike for Fossil because it's 
complicated. 9front core devs greatly valued being able to understand the 
entire system, but Fossil was a bit too much. Particularly, they didn't want to 
be responsible for maintaining a fork of Fossil too. Some people imported it & 
maintained it for themselves. Notably, mycroftiv ran quite a complex setup with 
a number of users on 9front+Fossil and was quite happy about it. I think he 
still does, but he no longer publishes CD-ROMs with his additions as he's 
changed his focus to the latest mathematical programming concepts.

mycrovtiv's... fork? I'm not sure it constitutes a fork, but there is quite a 
large set of namespace tools in addition to 9front+fossil.
"ANTS is no longer maintained and updated post 2020 but the iso is still 
available."
http://www.9gridchan.org/

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Md646adaede1124e9b486cf40
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] p9f mention of 9front

[Ethan Gardener]

On Thu, Jun 24, 2021, at 11:12 AM, Philip Silva via 9fans wrote:
> I wonder if this could be copied from how plan9port behaves on macOS 
> for instance. Using a single tap and then toggling/chording using alt 
> and command keys. Maybe on a multi-touch input the distance of the 2nd 
> and 3rd finger could help to identify which modifier/button it 
> translates to.

Doesn't P9P do something more than this on macOS already? I recall something 
about some multitouch arrangements as a replacement for chords. Some pro users 
liked it very much, but I've forgotten what the arrangements were. Caveat: it 
might have been optimized for Acme only.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M959527dd82998773b268d056
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] help

[Ethan Gardener]

But where are the nuklear wessels?

On Sun, Jun 20, 2021, at 4:32 PM, Marshall Conover wrote:
> The most recent humpback whale sighting I could find is this: 
> https://www.stuff.co.nz/environment/125480446/humpback-whales-put-on-spectacular-show-in-sounds
> 
> Live long and prosper,
> 
> Marshall
> 
> On Sun, Jun 20, 2021 at 10:55 AM Spock via 9fans <9fans@9fans.net> wrote:
> 
> 
> -- 
> Have a good day,
> 
> Marshall Conover
> *9fans * / 9fans / see discussions 
>  + participants 
>  + delivery options 
>  Permalink 
> 
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1bf00692daa5f082-Mc9658bb52fdb7e4a58dff080
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] the #cat-v channel has moved to oftc

[Ethan Gardener]

On Tue, Jun 15, 2021, at 10:56 AM, hiro wrote:
> freenode has deleted all channel and user accounts, including the
> #cat-v IRC channel.

I'm very sorry to hear about this. Freenode was a big part of my life for about 
10 years.

> we had already abandoned ship and moved to the oftc network instead,
> but now the /topic redirecting users to oftc got deleted.
> 
> our websites, the caches, the search indexes still reference freenode
> in many places, so i hope you can excuse this message to related
> groups to inform you that whatever happens on freenode, it is not us
> any more.
> 
> the people from #cat-v includes the (dp9ik) dissident plan9 irc kids,
> or more recently just the 9front community.
> 
> for some of us this is a sentimental moment as we had to also abandon
> uriel's IRC memorial. but maybe he would stay with us in other ways
> not involving silly computer protocols...

He absolutely will. I've never forgotten Uriel although I haven't been in 
#cat-v for years.

> uriel's nickserv password on freenode was "shitnode".
> 
> have a great day,
> hiro

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T443bc8b8132dd026-Ma3ca6c906986629a5c73ed21
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Foundation new releases question

[Ethan Gardener]

On Thu, Apr 8, 2021, at 3:39 PM, cinap_len...@felloff.net wrote:
> > Yep. I might be able to understand that change, but less so the later 
> > breaking change to 9p auth.
> 
> What 9p change for auth are you talking about?
> 
> The dp9ik implementation in 9front just uses p9any to negotiate
> it and p9sk1 is still supported; tho by default we have p9sk1
> disabled at the authentication server now to prevent the offline
> dictionary attack on the DES encrypted tickets that p9sk1 uses
> (tho it can be enabled by a flag in the authservers startup script).
> 
> The code changes to have both auth protocols work concurrently
> was actually the thing that took the most work and it took
> over a year of transition period until we could disable
> p9sk1 by default.
> 
> I'm not aware of anyone changing 9p.

I'm confused now. I'm sure someone official bypassed the existing mechanism to 
add a new auth protocol. I thought the existing mechanism was p9any, but 
perhaps I was wrong.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc472e4a0c0b6f084-Mdec75a41815793ccfe5cc9b4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Foundation new releases question

[Ethan Gardener]

On Sat, Apr 3, 2021, at 4:47 PM, Keith Gibbs wrote:
> It's almost as if the accusations that 9front in some way undermines the core
> philosophies of Plan 9 are not motivated by facts, 

There was a lot of grumpiness around when that accusation got started.


> On 21/04/03 05:39PM, hiro wrote:
> > btw everybody, remember how labs people added a syscall just for go?
> > and how that breaks compatibility for everybody?
> > 9front didn't like it. but I guess we prefer to stay as compatible as
> > feasible in addition to trying to prevent scenarios like these forced
> > upon us (by labs, ironic eh?)

Yep. I might be able to understand that change, but less so the later breaking 
change to 9p auth. There was no reason for it at all; p9any already allows 
different cyphers. Thankfully, it was easy to integrate without breaking dpi9k, 
but after all the care we'd taken to preserve 9p, I found it demoralizing. (I 
have this great idea for integrating file move into 9p, but "no, we do not 
break 9p!") And I got the impression that the 9p change was requested by the 
very people who accused 9front the most, but I wasn't really paying attention 
by then so I might very well be wrong about that.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc472e4a0c0b6f084-M6daae820c4155549c65c5709
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Foundation new releases question

[Ethan Gardener]

On Fri, Apr 2, 2021, at 5:20 AM, Lucio De Re wrote:
> I think that the "purity" (imaginary as it may be, it is an historical
> fact) of BL Plan 9 and the practicality of 9front should be discussed
> at a philosophical level 

To toss in my bit (although it's really more anecdote than philosophy): Years 
ago, I recall a strong devotion to purity of concept amongst core 9front 
developers. They didn't want to make changes for change's sake. I'm still 
amused/confused that 9fans at that time started accusing 9front of exactly what 
they weren't doing: making changes for change's sake! ;) But in the years since 
then, some small non-fix changes have been made.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc472e4a0c0b6f084-M0153a79925764b9754495ada
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Can compile Plan9 C compiler for windows10?

[Ethan Gardener]

On Sun, Mar 28, 2021, at 10:21 AM, Sean Hinchee wrote:
> Inferno 8c should work fine on Win10 :)

it runs and produces output. :) i didn't check if the output works; wasn't even 
sure how to produce a testable binary as it couldn't even find u.h.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-M364dfe22063fe61103dc1af6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Can compile Plan9 C compiler for windows10?

[Ethan Gardener]

On Sun, Mar 28, 2021, at 2:16 PM, saif.re...@outlook.com 
 wrote:
> uh inferno's 8c compiles .exe file?

no, 8c doesn't produce any executables, it leaves that to the linker, 8l. by 
default, 8l produces plan 9 executables, but the -H option can produce some 
other formats. the man page doesn't list windows exe but you could look in the 
source. look for "Nt"; inferno's name for windows, and "PE"; the executable 
format for modern ms windows, or "MZ" in case it still uses the old windows exe 
format.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-M1a23c459136d67944464c162
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] problem with installing plan9 from USB disk image

[Ethan Gardener]

On Fri, Mar 26, 2021, at 4:27 PM, Wes Kussmaul wrote:
> 
> On 3/26/21 12:18 PM, Kurt H Maier wrote:
> > On Fri, Mar 26, 2021 at 09:20:44AM -0400, Wes Kussmaul wrote:
> >> The replacement of legacy BIOS with UEFI had two consequences:
> >>
> >>   1. Dual booting is not possible
> >
> > This is false.  Dual-booting works just fine with UEFI; tools like
> > efibootmgr make it trivial and I do it all the time.  It's much nicer
> > than having to work with grub.
> 
> Then perhaps it wasn't just UEFI but something else in the system. I 
> recall trying to disable Secure Boot with no effect.
> 
> If I still had the laptop I would certainly try efibootmgr but as I said 
> I sent it back.
> 
> At any rate Lenovo had an incentive to make it work (preventing a 
> return/refund) and told me it couldn't be done.

There are broken UEFI implementations just like there were broken BIOS 
implementations in the 90s.

https://wiki.osdev.org/Broken_UEFI_implementations

It's certainly not a complete list. Lenovo appears twice, although one of the 
problems is just a boot logo thing. At least they're not Acer.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4a54d17e4c0f6c20-M3420177abee89f5720c281e5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] how to extract an .iso file using Inferno

[Ethan Gardener]

On Fri, Mar 26, 2021, at 11:48 AM, hiro wrote:
> it *is* extraction, on a per-file basis and on demand :)

You made me think for a moment. :) ISO-9660 images aren't compressed, so it's 
not extraction any more than any other disk-backed fileserver of Inferno or 
Plan 9. The read process is the same: find the region containing the desired 
data & copy it to the client. Just one of the wonders of Plan 9 & Inferno, or 
indeed any very clean design.

Of course, from a certain point of view, I'm sure any file read could be 
considered extraction. ;)

> 
> On 3/26/21, Ethan Gardener  wrote:
> > On Fri, Mar 26, 2021, at 9:56 AM, saif.re...@outlook.com
> > <mailto:saif.resun%40outlook.com> wrote:
> >> hello there!
> >>
> >> I want to extract an .iso file of plan9 operating system in Inferno
> >> system. Is there any command to do so?
> > % lookman cd-rom
> > man 4 dossrv # dossrv(4)
> > 
> > It's not actual extraction, but you can read & copy the files.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T00cb03faebe93c91-M4ac42af50946cb8b1c07d477
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] how to extract an .iso file using Inferno

[Ethan Gardener]

On Fri, Mar 26, 2021, at 9:56 AM, saif.re...@outlook.com 
 wrote:
> hello there!
> 
> I want to extract an .iso file of plan9 operating system in Inferno system. 
> Is there any command to do so?
% lookman cd-rom
man 4 dossrv # dossrv(4)

It's not actual extraction, but you can read & copy the files. 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T00cb03faebe93c91-M5a4a8f7f83047f23872a2b25
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] problem with installing plan9 from USB disk image

[Ethan Gardener]

On Fri, Mar 26, 2021, at 7:53 AM, saif.re...@outlook.com 
 wrote:
> I've uncompressed .bz2 but the problem is burning the .ISO file.

Following my guess at what's wrong:
You need to burn it as an image not a file. I think the default for most 
burners is to make a filesystem on the CD & put foo.iso into that filesystem as 
a file. How to do it will vary, but I'm pretty sure all burning software will 
have the option. If you've done it right, when you open the disk in Windows it 
should look have the same folders and files as the iso image. You'll see 
folders named 386 mips [other CPU names] mnt n bin dev sys lib adm cfg ...

Alternative #1:
If you can give a virtual machine access to a hard disk, you can use the 
virtual machine to install. You'd have to be careful not to harm Windows, but 
you would anyway. But if the iso won't boot when burned properly, I guess the 
installed system won't boot either.

Alternative #2:
Install 9front instead. Their iso image is USB-bootable. (You'll need to write 
the image to the raw device; not sure what tool but I think they document 
some.) It's almost the same as Plan 9, having some different fixes, some 
different drivers, and some other minor tweaks. (There's some work going on to 
share the changes as patches.) The biggest difference is 9front's website and 
documentation have... uh... a distinct flavour. ;) http://9front.org/

Huh.. 9front describe an alternative USB install process you might want to try 
if you can't get the others working. It's point 2 here:
http://fqa.9front.org/fqa4.html#4.2.2
For Plan 9, replace 9boot with 9load. You'll need to type the image name during 
boot as something like `sdC0!dos!9front.iso`. The letter C may be different. 
However, I'm not sure 9load has the necessary USB drivers. If it calls the 
BIOS, you'll be fine if your BIOS supports the right emulation; many do. (As a 
sort-of example: I have one laptop which emulates a USB floppy drive as a real 
floppy drive. It's great for old OSs which use the BIOS, but not so much for 
OSs which access the hardware directly.)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4a54d17e4c0f6c20-Md4324036853aba9a109175aa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation

[Ethan Gardener]

It occurs to me I thanked everyone but those who did the actual work. To fix 
that: I no longer use Plan 9 every day, but I have a huge soft spot for it and 
I've long been aware of license issues including the complexities of changing a 
license, so I know it wasn't easy. Awesome work, people, well done! :D
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M8f2928edaeeb1b74bef05bf7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] p9f.org https times out

[Ethan Gardener]

On Tue, Mar 23, 2021, at 3:33 PM, John Floren wrote:
> It's been quite responsive over http; I think the main issue is that
> people automatically write "https" in links these days and I'm not
> sure p9f.org ever had HTTPS set up. I remember trying it weeks back
> when Ron first announced it, wasn't able to connect with HTTPS back
> then either.

That makes sense, thanks John. It's working for me over http.

@fulton: Thanks! I might try to grab it with Inferno; don't have Plan 9 set up 
for that right now. (Just a couple of old VMs with no host access or drawterm, 
I don't think.)

@Jeff Sickel: You remind me of one of Sir Arthur Conan Doyle's works where his 
characters describe and praise the literal grave robbers who did such a lot for 
medical science and the training of doctors in the 19th century...

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T796b84dd486b2892-Ma3757fc3d44dd0d308d2381e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] p9f.org https times out

[Ethan Gardener]

https://p9f.org/ isn't responding; "The connection has timed out" according to 
Firefox. I've tried a few times in the last 15 minutes.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T796b84dd486b2892-Me8985d3c430223800befd325
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation

[Ethan Gardener]

On Tue, Mar 23, 2021, at 1:06 PM, a...@9srv.net wrote:
> We are thrilled to announce that Nokia has transferred the copyright of
> Plan 9 to the Plan 9 Foundation. This transfer applies to all of the
> Plan 9 from Bell Labs code, from the earliest days through their final
> release.
> 
> The most exciting immediate effect of this is that the Plan 9 Foundation
> is making the historical 1st through 4th editions of Plan 9 available
> under the terms of the MIT license. These are the releases as they
> existed at the time, with minimal changes to reflect the above.

That's a cause for celebration! :D


> 
> 1st and 2nd edition were never released as open source software, and
> both (but especially 1st edition) were only available to a very small
> number of people. 3rd and 4th were previously available as open source,
> but under a license which was problematic for some people (especially
> the 3rd edition). We think making these available under the MIT license
> is something that's going to be a significant benefit for all projects
> using Plan 9 code. While this doesn't automatically change the license
> on any downstream projects, and you're welcome to keep using the LPL if
> you like, you now have the option of switching to MIT, which we think
> most everyone will find preferable.
> 
> Obviously, for folks in the Plan 9 community, there isn't a way to say
> "thank you" to Bell Labs, and its various parent organizations, that's
> really adequate. None of us would be talking about any of this if it
> weren't for the work done there for decades. All of us here at the Plan
> 9 Foundation express our sincerest thanks to the team at Nokia who made
> this possible, the Plan 9 alumni who supported the effort, and the Plan
> 9 community who have kept kernels booting and the userland useful.
> 
> The historical releases are available right now at:
> https://p9f.org/dl/
> 
> You can read Nokia's press release on the transfer here:
> https://www.bell-labs.com/institute/blog/plan-9-bell-labs-cyberspace/
> 
> Thank you for your time,
> Anthony Sorace
> Plan 9 Foundation

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M95d1ac0ca2bdd3019821d901
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] patches from 9front

[Ethan Gardener]

On Sun, Mar 21, 2021, at 12:01 AM, kokam...@hera.eonet.ne.jp wrote:
> 
> I don't know what was occured when 9front was forked, and what kind 
> of antimode against 9front was made from that time...
> However I admire cinap who keeps 9front usable for a long time.
> I think he payed much effors!
> 

In the beginning, we were rebels. :) I didn't see what was wrong with that, but 
cinap & the others considered, "What do we really want?" and softened their 
attitude. On the other side there was a lot of pride and initially some 
confusion over 9front's licensing. The confusion was slowly cleared up and I 
guess the sad changes at Bell Labs had an impact too, but some still have a 
desire to use the original software. (I can understand that.) 9legacy provides 
for them by allowing them to choose which patches they apply, while 9front have 
a system they can be proud of.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc82939f1fda0e479-M46a44416aed63b5903351399
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 in Summer of Code

[Ethan Gardener]

On Thu, Mar 11, 2021, at 1:46 PM, hiro wrote:
> "Coraid used 9front" -> maybe you mean Coraid used 9atom?

Er... embarassing typo, thanks for catching it. I meant Plan 9. In those days, 
it seemed everyone who seriously used Plan 9 essentially maintained their own 
fork (and had the skills to do so). Erik Quanstrom was nice enough to package 
up Coraid's fork (or a variant) for the PC, and called it 9atom.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta35cde1382617430-Mb41b29025d48fb21c935c5c3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 in Summer of Code

[Ethan Gardener]

On Wed, Mar 10, 2021, at 8:20 AM, sirjofri wrote:
> Hey anths and community,
> 
> That's good news. 

It is. :)

> The p9f ideas page links to related projects, including 9atom and even 
> acme-sac. Could you also add the 9front pages to it?
> 
> http://fqa.9front.org/appendixg.html
> http://fqa.9front.org/appendixb.html
> 
> The bounties page might not be well suited for GSoC, but might act as 
> another source of inspiration.

Just to note: The bounties page contains some updates the GSoC page does not. 
Perhaps most notable is video playback which looks like it might be nearly done.

> Btw I never really met any 9atom guy, only 9front people who played 
> around with 9atom and wanted to port some 9atom stuff to 9front.

9atom development ceased years ago, possibly before 9legacy got started. It had 
one developer; he posts occasionally. 9atom was related to Coraid in some way. 
Coraid used 9front, but the board of directors made them switch to Solaris, and 
then, "proving the adge that companies who switch operating systems go 
bankrupt, they went bankrupt." This was about 2014 or 15.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta35cde1382617430-Md373848ed275e96f8df0783c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 2c/2l make sense, but why 1c/1l?

[Ethan Gardener]

On Wed, Feb 24, 2021, at 11:26 PM, Charles Forsyth wrote:
> I think they might have been there for some other reason and then was used 
> for Inferno, which they somewhat had going on a Palm Pilot in some form (not 
> necessarily as the native kernel).
> If I waded through a ton of archive material I could probably find the 
> latter, to see what it was, but I'm not sure it's really worthwhile now.

I know what you mean. I know I've read somewhere what that other reason was, 
but finding it is a historian's job, and I'm no good at being a historian. ;) I 
evidently didn't read it on 9fans, I just searched my email archive of it which 
goes back to late April 2011. 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf34475f1bb69674a-M9ab90f17db9f582994723878
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Ethan Gardener]

I forgot the EOF tokens, sorry for the noise. I shouldn't do this while tired, 
or maybe at all.

% for(n in _get*){echo 'cat >' $n '< _get_1_size < $dir^font
if(! ~ $status '') exit
fontsrv -p $name^$dir^font | 
ssam '1d
,x=.* =d
,s=.+=& > '^$dir^'&=g
,x=^=i=fontsrv -p '''^$name^$dir^'''=' | rc
EOF

cat > _get_all_sizes <[1=2]
mkdir -p $dir
fontsrv -p $name^$dir^font > $dir^font
fontsrv -p $name^$dir^font | 
ssam '1d
,x=.* =d
,s=.+=& > '^$dir^'&=g
,x=^=i=fontsrv -p '''^$name^$dir^'''=' | rc
}
EOF

cat > _get_all_sizes-noaa <[1=2]
mkdir -p $dir
fontsrv -p $name^$dir^font > $dir^font
fontsrv -p $name^$dir^font | 
ssam '1d
,x=.* =d
,s=.+=& > '^$dir^'&=g
,x=^=i=fontsrv -p '''^$name^$dir^'''=' | rc
}
}
EOF

cat > _get_all_sizes-prefix-version < $prefix^.font

fontsrv -p $name^$dir^font | 
ssam '1d
,x=.* =d
,s=.*=& > '^$prefix^'-&=g
,x=^=i=fontsrv -p '''^$name^$dir^'''=
' #| rc
}
EOF


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-M4b945fa58f69efff23098167
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Ethan Gardener]

Years ago, I used to convert fonts by copying from fontsrv -p. This was due to 
bugs fontsrv had at the time, but I guess it may still be useful. 

Here's the 4 scripts I used to use, for whatever they might be worth.

% for(n in _get*){echo 'cat >' $n '< _get_1_size < $dir^font
if(! ~ $status '') exit
fontsrv -p $name^$dir^font | 
ssam '1d
,x=.* =d
,s=.+=& > '^$dir^'&=g
,x=^=i=fontsrv -p '''^$name^$dir^'''=' | rc

cat > _get_all_sizes <[1=2]
mkdir -p $dir
fontsrv -p $name^$dir^font > $dir^font
fontsrv -p $name^$dir^font | 
ssam '1d
,x=.* =d
,s=.+=& > '^$dir^'&=g
,x=^=i=fontsrv -p '''^$name^$dir^'''=' | rc
}

cat > _get_all_sizes-noaa <[1=2]
mkdir -p $dir
fontsrv -p $name^$dir^font > $dir^font
fontsrv -p $name^$dir^font | 
ssam '1d
,x=.* =d
,s=.+=& > '^$dir^'&=g
,x=^=i=fontsrv -p '''^$name^$dir^'''=' | rc
}
}

cat > _get_all_sizes-prefix-version < $prefix^.font

fontsrv -p $name^$dir^font | 
ssam '1d
,x=.* =d
,s=.*=& > '^$prefix^'-&=g
,x=^=i=fontsrv -p '''^$name^$dir^'''=
' #| rc
}

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-M641c4f27e469e9cb1dff1426
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Ethan Gardener]

On Thu, Feb 18, 2021, at 9:04 AM, Skip Tavakkolian wrote:
> Plan9port has fontsrv. Any truetype you have on your system is usable.
> man fontsrv for details.

Yes. Fontsrv is why I was describing truetype fonts, I just forgot to mention 
fontsrv itself.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-M73a52eff1e0f6793bdbcbabf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Whats the default font in Acme?

[Ethan Gardener]

On Wed, Feb 17, 2021, at 7:14 PM, sirjofri wrote:
> 
> On 9front (and maybe on 9legacy?) It's the font you specify with font=, 
> which is vga by default.

It's almost always specified with font= so you can `echo $font` to see what it 
is. (If font isn't set, I think there might be a builtin default of `fixed`.)

As for the actual font, non-9front systems likely have Pelm or Lucida Sans 
[Mono] for their default font. Lucida is an old bitmap font, not the newer 
scalable Lucidux Sans. I don't see any sign of Pelm outside Plan 9 circles and 
I'm sure it's also a bitmap font by design. *However,* a quick web search for 
`"pelm" font` turned up a Hacker News page with opinions that Lucida Grande is 
very similar to Lucida, and "Go Mono is closer to (or a remake of) the Pelm 
font from Plan 9." Both of these are scalable.

The article it's commenting on announces the Go fonts, containing sample images:
https://blog.golang.org/go-fonts

HN subthread with cited/quoted opinions:
https://news.ycombinator.com/item?id=12973952
HN thread:
https://news.ycombinator.com/item?id=12973716

Personally, I'd like to see a scalable version of the old GEM font, although I 
liked it more for its style than its readability when I was a teenager. ;)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td0ab6c3112c95493-M0fb2746b097f413e3b279531
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: GSoC 2021 project ideas

[Ethan Gardener]

On Sun, Feb 7, 2021, at 10:59 PM, cigar562hfsp952f...@icebubble.org wrote:
> 
> That's a brilliant idea: a "Dis" assembler for Plan 9, to compile (well,
> assemble, really) Dis code to binaries for the host architecture.  The
> Dis architecture was specifically designed to make it easy to map the
> Dis machine to the underlying architecture.  But... the binary interface
> would have to be the Plan 9 one, so the proper place to do such assembly
> would be on Plan 9.  If it were an extension of Inferno's JIT, it would
> have to track changes made to Plan 9.  Since Dis is stable and
> standardized, it makes more sense for a Plan 9 tool to track Dis than
> the other way around.

Thanks! I'm far from being an expert in the generation of object files, so I'll 
bow to your knowledge there.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T39aec8f3f9d8503d-M1952db434f371b6dab1c94e3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9Front / cwfs64x and hjfs storage

[Ethan Gardener]

On Mon, Feb 8, 2021, at 1:35 AM, Ryan wrote:
> im not seeing how to unsubscribe from this on
> https://9fans.topicbox.com/groups/9fans/subscription

Me either. I can say the group admins don't respond to the sort of mail you'd 
send to an automated mailing list server. :p (I was a bit confused that day.) 
Personally, I'm no longer sure I want to unsubscribe.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc951a224dde6dde5-Mf68f8aed5459199f53f4ffd0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] GSoC 2021 project ideas (WAS: Re: Plan 9 Applying to GSoC 2021)

[Ethan Gardener]

On Mon, Feb 1, 2021, at 7:16 AM, cigar562hfsp952f...@icebubble.org wrote:
> Anthony Sorace  writes:
> 
> (6) Incorporating Inferno's Dis virtual machine into the Plan 9 kernel,
> so Plan 9 can run Dis binaries natively, without having to run the
> Inferno emulator (emu) as a user process.

This idea keeps popping up, but I just thought a Dis to native code compiler 
would achieve the same result without bloating the kernel. Perhaps it could 
even be built into Inferno, if the JIT compiler could be modified to output an 
object file instead of running the code. I'm not sure if that's reasonable; I 
was just thinking of avoiding duplication of a large, possibly hard to maintain 
component.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1c300cdbd9941edb-Ma8c141f7b291b014bcfcc676
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] GSoC 2021 project ideas (WAS: Re: Plan 9 Applying to GSoC 2021)

[Ethan Gardener]

On Tue, Jan 19, 2021, at 11:08 AM, pouya+lists.9f...@nohup.io wrote:
> [eeke...@fastmail.fm]
> > I specifically say "more popular" because popularity affects the
> number of developers available.
> 
> Off-topic and perhaps unpopular view, but I *like* the fact that Plan
> 9 is not (significantly) more popular.  Popularity has ruined many a
> promising creation.

Of course. I was talking about driver development only.

> Although please do not take this to mean that I don't value all the
> work that has been going into developing the community and continuing
> to evolve and move forward.  Luddites like me also greatly benefit
> from it.

Me too. :D

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1c300cdbd9941edb-Mff1d12674d60daf45f2d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] GSoC 2021 project ideas (WAS: Re: Plan 9 Applying to GSoC 2021)

[Ethan Gardener]

On Tue, Feb 2, 2021, at 8:29 AM, tlaro...@polynum.com wrote:
> > 
> > Plan 9-related:
> > 
> > (1) Porting the Plan 9 kernel to a microkernel architecture, such as
> > Mach.  This would give Plan 9 instant access to the whole range of
> > hardware supported by the underlying microkernel.

Apple's Mach is not a microkernel. The first pure microkernel version of the 
Mach architecture was 3.0. Apple have stuck with 2.5 all these years. The 
ability to use drivers from some more popular OS would be nice for users if it 
works, but there are a host of possible integration and maintenance problems. 
In fact, I know there are problems I don't quite understand related to 
differing OS designs. The parts I do understand indicate there could be a huge 
performance penalty in using drivers in OSs for which they were not designed.

I specifically say "more popular" because popularity affects the number of 
developers available. In those terms, 9front is already in the rarified 
stratosphere of well-developed hobby OSs. I'd put only 2 or 3 other OSs as its 
equal. In the next level up, (orbital space? ;) and not counting the BSDs, 
Haiku is the only one I can think of off the top of my head (but I have just 
woken up). We might yet see other OSs implementing 9p so they can use our 
drivers. :) 

> No. One should re-read the initial papers about Plan9. When Plan9 was
> designed, microkernels were "fashionable". If one reads carefully the
> paper, it's clear that there is a pun intended against microkernels that
> didn't achieve what they were supposed to do---disastrous efficiency
> leading to the rewrite of the microkernels as assembly---a very low
> signal/noise ratio. And a hint: "micro" kernels are usually _huge_, a
> clear sign that something went wrong.

Uh... these arguments are kind-of obsolete. Plan 9 is a hybrid on the 
macro-micro kernel scale. So are mainstream OSs, having arrived at that point 
by various routes from whatever their origin was. Microkernel QNX is tiny and, 
if I understand right, makes service development easier than Plan 9 does. I 
suggest the huge "microkernels" are really hybrids, but I'll omit reasoning on 
why.

> As drivers are concerned, there was once a kit supposed to give a wide
> range of kernels, drivers code---I don't know where it is now; I suppose
> it has vanished. And now probably UEFI drivers is a "better than nothing"
> solution.

Uh... UEFI boot services are typically available, but UEFI run-time services 
are a different thing. A long-time OS dev I know does not expect UEFI runtime 
services to ever be available on commercial-grade hardware. He is a terrible 
cynic and I can't remember quite how that debate ended, but in general, it 
looks like UEFI isn't significantly better than the old PC BIOS for 
compatibility. As they say on osdev.net, "Writing a bootloader which works on 
one computer is easy. Writing a bootloader which works on many computers is 
hard." Note this statement is only about features necessary for booting an OS, 
whether BIOS or UEFI. If those are bad, features not necessary for booting will 
be worse. And performance of the kind needed at run-time is hardly a 
consideration when booting. (I appologise for my poor sentence construction. 
I've just woken up.)

> My 2 cents,

Ain't the Internet wonderful? You get 2 cents back with a lot of interest! XD

Much of what I've posted here is condensed from osdev.net, especialy the 
forums. I'd suggest lurking there if you're interested in the difficulties (or 
otherwise) of driver development. It's not perfect by a long shot, but it is a 
better place for it than this list.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1c300cdbd9941edb-M1b3c27671fcffae2e5ffa604
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] GSoC 2021 project ideas (WAS: Re: Plan 9 Applying to GSoC 2021)

[Ethan Gardener]

On Mon, Feb 1, 2021, at 8:46 PM, Steve Simon wrote:
> 
> Inferno-related:

These should be posted to inferno-os too, but some are there already. (It's on 
Google Groups.) Note that they're starting work on a 64-bit DIS; Charles has 
just announced a fork for working on it.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1c300cdbd9941edb-M45dd636d66c8f4568519f90c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] GSoC 2021 project ideas

[Ethan Gardener]

On Mon, Feb 1, 2021, at 9:47 PM, sirjofri wrote:
> > (a) An Android "app" that presents an Android phone's telephone and SMS
> >     messaging facilities as a 9P filesystem.  This would enable Plan 9
> >     and Inferno applications to place/receive voice calls and
> >     send/receive text messages across a network.  This could be done by
> >     extending bhgv's existing Android port of Inferno, or as a
> >     separtate, stand-alone server app.

Yes. I recall some users of IoS Drawterm very much appreciated /dev/gps

> Also hellaphone might be interesting (maybe just for comparison). Afaik 
> they removed the whole java stuff from android and replaced it with dis. 
> They were able to do phone calls and I think they got rudimentary text 
> messages working, too, but both directly on the phone using inferno.

They did. Unfortunately, Linux is so bad at abstracting hardware interfaces 
that it only ever ran on one or two phones. Also, they never figured out how to 
make it ring. They did have /dev interfaces for sms and dialing.
http://jfloren.net/b/2015/8/18/2

(Should I be blaming Android hardware vendors for Linux interface 
inconsistency? I don't think so. I remember sysfs going from about 3 to over 10 
files just to represent battery state.)

> A native 9p interface for Android might also be a nice project. Android 
> supports adding new protocols like ftp or smb to its native filesystem 
> pool. I don't know the details.

Awesome!

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T39aec8f3f9d8503d-Mb7a4db08efa189a058ad48aa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[Ethan Gardener]

On Mon, Jan 25, 2021, at 10:31 PM, David Arroyo wrote:
> On Tue, Dec 29, 2020, at 18:50, cigar562hfsp952f...@icebubble.org wrote:
> > It's well-known that 9P has trouble transferring large files (high
> > volume/high bandwith) over high-latency networks, such as the Internet.
> 
> From what I know of 9P, I don't think this is the fault of the protocol
> itself. In fact, since 9P lets the clients choose Fid and Tag identifiers,
> it should be uniquely well suited for "long fat pipes". You could avoid
> waiting for round-trips by optimistically assuming your requests succeed.
> For example, you could do the following to optimistically read the first
> 8K bytes of a file without needing to wait for a response from the server.
> 
> * Twalk tag=1 fid=0 newfid=1 /path/to/somefile
> * Topen tag=2 fid=1 o_read
> * Tread tag=3 fid=1 off=0 count=4096
> * Tread tag=4 fid=1 off=4096 count=4096
> * Tclunk tag=5 fid=1
> 
> I'm not aware of any client implementations that do this kind of
> pipelining, though.

fcp(1)? 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M1b4dd6e347d2d00d2cd645d8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] authoritative source for u9fs?

[Ethan Gardener]

On Mon, Jan 25, 2021, at 5:10 AM, Lucio De Re wrote:
> 
> PS: The new executable seems noticeably bigger than whatever I used
> previously. Which happens to be the NetBSD "pkg" version
> (/usr/pkgsrc/filesysytems/u9fs). Hmm, the differences are quite
> significant...

Just checking: Was the old one `strip`ped and the new one not? That's caught be 
out before; the symbol table being by far the largest part of some binaries.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tee2220301f2a891c-M74ae21d6ac07c6d16acab49f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] thin clints, confession and a freebie

[Ethan Gardener]

On Sat, Jan 9, 2021, at 2:09 PM, Steve Simon wrote:
> 
> to port plan9 to it.

It could be easy. I remember a Kirkwood port a few years ago. Labs 9 may 
already support everything but the graphics.

(Not interested myself, just saying.)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4a0764bde8bd29cc-M916dbd26c18cb8f3a019ce7a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] TabFS

[Ethan Gardener]

On Mon, Jan 4, 2021, at 12:04 AM, Ethan Gardener wrote:
> On Sat, Jan 2, 2021, at 11:14 AM, Nick LaForge wrote:
> > Saw this on hacker news today: https://omar.website/tabfs/
> 
> Awesome! I may very well steal this for my (non-filesystem) control 
> efforts. It would be just-about the best test case I could have.

Orrr apparently I could use WebDriver. I reply too quickly.
https://developer.mozilla.org/en-US/docs/Web/WebDriver

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td86a3606588c352f-M672ace14e470a61a06258d8b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] TabFS

[Ethan Gardener]

On Sat, Jan 2, 2021, at 11:14 AM, Nick LaForge wrote:
> Saw this on hacker news today: https://omar.website/tabfs/

Awesome! I may very well steal this for my (non-filesystem) control efforts. It 
would be just-about the best test case I could have.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td86a3606588c352f-M3e9f1cc9a781f6e53448418b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Dual dialing/forking sessions to increase 9P throughput

[Ethan Gardener]

> The idea, basically, is to use an open flag (OJUMBO) to signal that two
> connections to the same server should be attempted.  

What's the advantage over fcp(1)? 9p can have numerous requests "in flight" at 
once to work around latency issues, but of all the user programs, fcp is 
probably the only one which takes advantage of this.

> If a second
> connection can be established, it is used for normal 9P transactions,
> while the first connection is used for large ("jumbo") writes.

How large is "jumbo"? I believe all the user programs have 8KB buffers at 
present; are you going to change them all?

I'm not negative about this; just raising the points.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M59ac782c0f58a0cc1eec8c10
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9Front / cwfs64x and hjfs storage

[Ethan Gardener]

On Tue, Dec 29, 2020, at 1:06 PM, Alex Musolino wrote:
> > While it is not yet a concern, I am trying to figure something out
> > that does not seem to be well documented in the man pages or the fqa
> > about the file systems.
> 
> Parts of fs(4), fs(8), and fsconfig(8) can be applied to cwfs.  The
> syntax that Ethan talked about for concatenating WORM devices is
> described in fsconfig(8).

Only approximately. This page puts several paragraphs into describing syntax 
specific to Ken Thompson's standalone fileserver which we no longer have. CWFS 
is a port of this, so the syntax is similar, but the device specifications are 
different. Looking at a real config will help make the transition, along with 
some guesswork. There was something about adding option letters to the 
beginning of paths...

I'm *really* not happy with the state of cwfs documentation and I'm not 
qualified to fix it.

> > I am currently running a plan9front instance with cwfs64x (the whole
> > "hjfs is experimental, you could loose your files" seemed to be a
> > bit dangerous when I started everything) and I understand that it is
> > a WORM file system.  My question is for the end game.  If the
> > storage gets full with all of the diffs, is there a way for the
> > oldest ones to roll off, or do you need to expand the storage or
> > export them or ?  I come from the linux world where this is not a
> > feature file system wise and worst case I would have lvm's that I
> > could just grow or with repos I could cull the older diffs, if
> > needed.
> 
> Cwfs doesn't know anything about diffs as such, it just keeps track of
> dirty blocks and writes these out to the WORM partition when a dump is
> requested.  The plan 9 approach to storage is to just keep adding
> capacity since the price of storage falls faster than you can use it
> up.
> 
> I recently upgraded my home file server from an 80GB HDD to a 240GB
> SSD and documented the process [1].  The WORM partition contained 25GB
> and dates back to 2016-04-12.  Now, maybe you'll generate much more
> data than me over less time, but in this day and age of cheap
> multi-terrabyte HDDs and hundred-gigabyte SSDs I think it's still
> perfectly reasonable to just keep adding capacity as you need it.
> [1] http://docs.a-b.xyz/migrating-cwfs.html

Good link.

Incidentally, I bought 2 720GB drives in January 2007 and partitioned them as 
500GB/remainder. (I always keep spare partitions.) I never even filled one of 
those 500GB partitions in 10 years. ;) In my case, it would be well worth 
migrating rather than extending the space.

> Another thing to consider is how much data you really need to be
> sending to the WORM in the first place.  Multimedia, for example,
> might be better stored on a more convential file system since the lack
> of content-based deduping in cwfs might result in these files being
> dumped multiple times as they are moved around or have their metadata
> edited.  Even venti won't dedup in the latter case as it doesn't do
> content-defined chunking.

Yes. 9p lacks any sort of move command and moving is done by copying, so you'll 
end up with multiple copies of these large unchanging files in the dump for no 
good reason. I'm not so sure about metadata because the dump is block-based, 
not file-based, but if the metadata is variable-length, changing it will 
pollute any block-based WORM, dedup'd or not.

It might seem more reasonable to keep such large, unchanging files on cwfs 
"other", except "other" reacts badly to being accidentally filled. (Other is 
really just the cwfs cache partition code which also can't handle being filled 
due to some cache-specific practical issue.) It's better to use another 
filesystem entirely. I haven't heard of many problems with hjfs, but 
filesystems in general are the worst for unpleasant surprises. There is also 
dossrv (very heavily used and tested), extsrv (possibly not so much?), and kfs 
(if we still have it). Kfs is a bit lightweight, but I had no problems using it 
for root in a 9vx setup years ago. It may have smaller limits. Dossrv supports 
fat32, so the file size limit is 2 or 4GB.

> Plan 9 is really good at combining multiple filesystems from multiple
> machines (running different operating systems!) together into a single
> namespace.  My music collection lives on an ext4 filesystem mirrored
> across 2 drives (and backed up elsewhere) but can be easily accessed
> from 9front using sshfs(4).  I just run `9fs music` and the entire
> collection appears under /n/music.

Yes indeed! I haven't used sshfs myself, I used u9fs. (The needed updates to 
ssh only happened in recent years.) We have so many options for networked 
filesystems. :) Anyway, it's recommended to use u9fs over ssh so there's 
probably no point to it, but I dug up the links anyway for nostalgic reasons.

source
http://9p.io/sources/plan9/sys/src/cmd/unix/u9fs/
man page:
http://9p.io/magic/man2html/4/u9fs

--
9fans: 9fans

Re: [9fans] 9Front / cwfs64x and hjfs storage

[Ethan Gardener]

You can add disks. CWFS config allows multiple devices/partitions to form the 
WORM. It's like a simple form of LVM. I forget the exact syntax and I don't 
think there's a man page documenting cwfs's particular variant syntax, but I 
think it's something like (/dev/sdE0/worm /dev/sdF0/worm) in place of just 
/dev/sdE0/worm

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc951a224dde6dde5-M57af3d63f67cdbfadc721ff2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Plan 9 announcements on twitter

[Ethan Gardener]

On Sat, Dec 5, 2020, at 10:25 PM, cigar562hfsp952f...@icebubble.org wrote:
> 
> It would be nice if there was some way to translate between technology
> intended for idiots and technology intended for experts.  Imagine if,
> for example, every Android app automatically exported its functionality
> over 9P.  The cell phone idiots would have all their flashy toasts and
> swipes, but the apps would still be usable by command line nerds.

I recently learned most Amiga programs had "Rexx ports". They'd accept commands 
in the scripting language Rexx (or rather Arexx) from other programs or the 
user. It's another way of doing the same thing. It also avoids some GUI bloat: 
if a program wanted to open a file selector, it would call the file manager to 
do it.

> > PS: I concur with the late Dijkstra that the programming language(s)
> > you learn shape(s) your ability to construct abstractions in your
> > mind. We're kind of safe for as long as C remains the base language
> 
> That sounds like a variant of the Sapir-Whorf Hypothesis (which applies
> to natural languages) as applied to computer languages.

I don't know the hypothesis, but very much agree different languages influence 
how you think and even feel.

> > I had an electrical engineering friend, back at university, who used
> > array subscripts in C because he couldn't get his head around
> > pointers. Like me, his migration was from Pascal to C.
> 
> Pascal has pointers, too, and they make alot more sense than pointers in
> C.

To me, C pointers are just another way of indexing the Great Memory Array -- 
it's a union of arrays of all different types. ;) I am much more comfortable 
with the syntax of array subscripts, too. I came to C from BASIC and assembly 
language.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3fd028fcf2eeb24c-M45f25095dd8e2da7aa645f47
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: various problems with installing go lang

[Ethan Gardener]

On Wed, Oct 28, 2020, at 1:08 PM, Richard Miller wrote:
> > non-deterministic builder
> 
> It's probably not non-deterministic. It's just unpredictable (to me)
> because the rules are encoded in the logic of 'go build' rather than
> being visibly exposed as mk patterns.

I understand, but I'm sure it would seem unpredictable to me too. Such apparent 
unpredictability bothers my brain when I'm trying to concentrate. A compiler 
unexpectedly taking the time to rebuild the entire toolchain in the middle of 
an edit-test-debug cycle would be a little too much for me personally.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T80ee3327f2f3dc57-M49b2b4839b7e74f9c263bf8a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: various problems with installing go lang

[Ethan Gardener]

On Wed, Oct 28, 2020, at 9:46 AM, Richard Miller wrote:
> 
> That's telling you that it's attempting to rebuild some of the go library.
> (Don't ask why. Rather than use something understandably deterministic like 
> mk,
> the go authors have opted for an inference engine to detect "staleness",
> which, in my experience, can trigger a recompile of the entire library
> when something apparently innocent is touched.)

Ugh! Didn't it formerly use mk? Just yesterday, I recalled my ancient notion of 
forking an early version of the language and calling it Stop. ;) If I liked the 
language, I might have done it already, (and the switch to a non-deterministic 
builder would be a likely trigger,) but then I am a little crazy.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T80ee3327f2f3dc57-M5fdf7ac6aba0282180e67457
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9term, insta scroll to bottom?

[Ethan Gardener]

On Sat, Oct 24, 2020, at 2:01 AM, nydldm...@mail.com wrote:
> Hi, I am an idiot and sometimes I cat huge files in 9term (on 9front)
> 
> The result of this is a mess I cannot seem to scroll to the bottom of,  how 
> can I instantly scroll to the bottom in 9term? 

Enable scroll. When at the bottom, disable it if desired. I did this all the 
time, especially with man pages.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T13b7a14fa28da183-M8670a7f02a6dac2b9ed84b78
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Flakey DNS server

[Ethan Gardener]

On Thu, Oct 8, 2020, at 4:48 AM, Lucio De Re wrote:
> *** no longer on topic ***
> So, on a lighter note: for all my dislike of multi-media and how it
> has taken over the Internet, I find youtube's collection of music from
> my teens very enjoyable, in some kind of extreme nostalgia - and the
> comments from many others who mirror my sentiments also somewhat
> reassuring (I believe critics call that an "echo chamber"); that's my
> own idea of "mellowing".

I get that. Someone reminded me of Thin Lizzy the other day, and youtube of 
course made it very convenient to hear them again. Also, some of the best times 
in my life involved a terribly badly-coded server-client system with a 
painfully bad GUI! I'm not sure how that happened, but it did. There were some 
good design features in that system.

> On another, weirdly related note, I wonder if anyone else who may be
> following developments of the Go language have noted the recent shift
> from email identities that at least resemble human names and surnames
> to the most extraordinary monikers. I have been subscribed to gerrit's
> stream of change requests for quite a while and the change has really
> given me cause for concern. I do plan to stop receiving those
> notifications as soon as I can figure how to unsubscribe in bulk.
> 
> My heart goes out to Russ, Rob and Ian Taylor as well as the many
> others who need to deal with that flow of consciousness.

I wouldn't be too worried, politeness is the new punk. I had a very polite 
friend who wore a most extraordinary mohawk with waistcoat, pocket watch, 
neatly pressed trousers and patent leather shoes. Somehow, even the mohawk 
looked smart. Besides, this may be a return to the sensible practice of not 
putting your real identity online. I recently found reasons to wish I'd kept to 
that, although I thankfully haven't had any real problems from it.

~ eekee ~

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4e8db4c94a81d90f-Mcb78fdde72046aafa1db59e5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 in Brazil

[Ethan Gardener]

On Tue, Sep 1, 2020, at 1:10 PM, hiro wrote:
> > developing new, non-unix operating systems
> 
> which?

Google's Fuschia, Huawei's Harmony.

Besides, hobbyist interest in operating systems seems as alive as ever.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T46e6d1465ae13031-M083b7f89d3cdc98e949ad125
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 in Brazil

[Ethan Gardener]

On Sat, Aug 29, 2020, at 10:30 PM, o...@eigenstate.org wrote:
> > I really don't understand why Plan 9 has not been adopted. Legacy base?
> 
> Porting software is expensive and time consuming. Unix
> mostly works. On top of that, Unix has many features.
> Bolted on in ways that don't fit, but features that
> aren't provided by Plan 9 tools, nonetheless.
> 
> When given a familiar but ugly environment with more
> features, which requires less work to get their familiar
> software running, what do you expect the result to be?

I agree, and add to all that the fact that Linux was popular and well-regarded 
many years before Plan 9 became open-source. Plan 9 was not only expensive, but 
IIRC hardly available before it was open-sourced in 2000. 

Also, denial of a serious bug in Fossil must have contributed to crushing what 
little chance Plan 9 had in this century. It took over 10 years to fix a 
serious data corruption bug which affected most, perhaps almost all new users. 
What commercial developer or balanced hobbyist would put up with that? For some 
perspective, see mycroftiv's mail: [9fans] notes on fossil, ANTS, and 
9front/Bell labs controversies. He put a lot of effort into working around 
failure of the root filesystem. I'm sorry for the part I've played in 
contributing to the Plan 9 attitude problem, and I'm glad to see it has faded 
away.

With the attitude problem gone and some corporations developing new, non-unix 
operating systems, I think Plan 9 could well become more popular than it's ever 
been.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T46e6d1465ae13031-M84bf4987dcdd85beea8fdbc6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Object Icon, drawterm, riox

[Ethan Gardener]

On Fri, Aug 28, 2020, at 7:04 PM, Leonardo wrote:
> I can see the need for a window have an owner and stay on the screen only if 
> your owner stays,

I'm not sure I'm thinking clearly today, but don't we have this? A single 
window normally requires at least 3 procs, (keyboard, mouse, output,) so, to 
quote rio(1): Deleting a window causes a `hangup' note to be sent to all 
processes in the window's process group (see notify(2)). Is there any reason 
one process group cann't have multiple windows? If not, then the default is to 
close all when one is closed. Now I see the clever bit would be the reverse of 
the problem statement: *not* closing the parent window when a child window is 
deleted.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T888cf1c8059b63ab-Me5cf137fda993d1d87d93fd6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Early version of Floppy Demo

[Ethan Gardener]

On Thu, Jul 23, 2020, at 10:59 PM, Will Senn wrote:
> Interestingly enough, I found an old 4 floppy set of vd's in the same folder 
> with the demo image. It looks like they are Nov 1995 (I apparently winimaged 
> them from floppies back then). When I boot disk 1, it complains about not 
> having an mbr partition and bails. I'm guessing it's expecting some OS and 
> hard disk to be present to install to. 

Huh! You noticed them just a little sooner than I did. Reading betweent he 
lines of the README, it looks like they were being very careful about MBR 
matters. I think a hard disk image with an empty MBR should be enough. 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfc1bc1c6f9de7e59-M1e25abc9435eee75cab2ad9e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Early version of Floppy Demo

[Ethan Gardener]

On Thu, Jul 23, 2020, at 10:33 PM, Skip Tavakkolian wrote:
> 
> 
> On Thu, Jul 23, 2020 at 1:31 PM Ethan Gardener  wrote:
>> On Thu, Jul 23, 2020, at 6:50 PM, Skip Tavakkolian wrote:
>> > Going by memory, assuming aux/vga ran, you should be able to type 
>> > 8-Alt-1-2 to type 8½
>> > You should also be able to start acme or sam instead of 8½.
>> 
>> These will probably work, except acme hadn't been invented yet and sam may 
>> or may not give an error the first time. (Checked with another demo disk.) 
>> You probably do want to start the window system, there is no way to kill the 
>> foreground process without it.
> 
> Acme (Alef version) is in 2ed; the single-floppy version doesn't seem to have 
> the binary. Looking at the screenshot that Will sent me directly, the dates 
> on the binaries match up to 2ed release.

I stand corrected.

> I'm pretty sure the four-floppy set that came with the CDROM has the acme 
> binary. I don't have any floppy drives that I trust to look at my copy.

I think I have images of those, could send them if desired. At least, the ones 
I have are described like this in the README:
> The files in this directory recreate the four 1.44MB diskettes
> used to load a limited version of Plan 9 onto a PC.  It is intended
> to let you try out Plan 9 before buying, in particular to see if
> the system supports your PC hardware.

They also contain fixes, perhaps over the iso? Anyway, if they contain iso9660, 
I imagine they're enough to get the iso installed.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfc1bc1c6f9de7e59-Mb42ab4b7ee40bbf471c065a3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Early version of Floppy Demo

[Ethan Gardener]

On Thu, Jul 23, 2020, at 6:50 PM, Skip Tavakkolian wrote:
> Going by memory, assuming aux/vga ran, you should be able to type 8-Alt-1-2 
> to type 8½
> You should also be able to start acme or sam instead of 8½.

These will probably work, except acme hadn't been invented yet and sam may or 
may not give an error the first time. (Checked with another demo disk.) You 
probably do want to start the window system, there is no way to kill the 
foreground process without it.

I could email a slightly newer demo disk which prompts, "Start the window 
system? (y/n)". Note that it has more annoyances than 4th edition. For 
instance, while the down arrow key behaves appropriately, the up arrow key 
inserts Î. Home inserts Í, End inserts CR. Double-click doesn't select anything 
in 8½, which is a nuisance when you habitually use send. The grep command does 
not exist! It does, however, have ftpfs. Useful demo, not useful tool.

I could email a 2nd edition CD-ROM too. It has grep and the source to 
everything, but it's not a bootable disk. I don't think the demo floppy's 
kernel has appropriate drivers. (It certainly lacks 9660srv.) The contents of 
#S are unfamiliar too. The demo floppy lacks a lot of things, such as 
/dev/drivers and even ns, which hinders exploration. I extracted a bunch of 
kernels from the CD-ROM in the past, but I couldn't be bothered to figure out 
how to boot them, much less find which one(s) will mount root from a CD-ROM. I 
wonder if they'll boot if I tell qemu they're floppy disk images... (tired now)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfc1bc1c6f9de7e59-Mb3eeae6faecc6b73f27406f1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Acme fonts

[Ethan Gardener]

On Thu, Jul 23, 2020, at 6:27 AM, Lucio De Re wrote:
> 
> It does mean that acme needs some way to extend its grasp of
> delimiters into the extended fonts.

How about just masking off the top few bits when checking for delimiters? Not 
really a clean solution, but certainly simple. It would mean some long numbers 
in subfont files. If we use the top 4 bits:
0x1000 0x101f /mnt/font/MyriadPro-It/36a/x.bit
That doesn't look as bad as I thought it would.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9673b88bfb3c3d3b-Mb7b9badadb38745e744e6e5a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 127.0.0.1 considered harmful

[Ethan Gardener]

On Mon, Jul 13, 2020, at 8:04 AM, Lucio De Re wrote:
> On 7/11/20, Ethan Gardener  wrote:
> > #
> > #  because the public demands the name localsource
> > #
> > ip=127.0.0.1 sys=localhost dom=localhost
> >
> Yes, someone should submit a legacy patch just to correct the comment!

An easy patch, but I rather like the comment. It amuses me. ;)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta94caa59de01adf8-M212e6765d90cf48099bf448e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 127.0.0.1 considered harmful

[Ethan Gardener]

On Sat, Jul 11, 2020, at 12:04 PM, Richard Miller wrote:
> So the problem seems to be latency of 9p transactions. Could it be
> an artifact of tcp flow control not adapting well to the loopback
> interface? Can anyone offer an insight?

A comment in the default /lib/ndb/local makes me think the loopback interface 
was a bit of an afterthought. It's this one:

#
#  because the public demands the name localsource
#
ip=127.0.0.1 sys=localhost dom=localhost

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta94caa59de01adf8-Ma890076e256fae55db4f2e59
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9p File mount in OpenBSD

[Ethan Gardener]

what is serving the host directory? is qemu involved? i ask because qemu's 9p 
is not the same as plan 9's 9p. plan 9's 9p is 9p2000 which transports a subset 
of plan 9 system calls over the network. qemu's 9p is 9p2000.L which transports 
a subset of *linux* system calls over the network. the 2 protocols are similar 
in design, but not compatible. some years ago, the maintainer of v9fs (linux's 
9p driver) stated it was essentially 2 separate drivers because of this. so, if 
you want to use 9pfuse in the guest, you probably want to serve the host files 
with u9fs, not qemu.

On Mon, Jun 29, 2020, at 6:11 PM, rt.ml via 9fans wrote:
> Hey,
> I am running OpenBSD as a Guest with Fedora(host system) using virsh 
> .
>  Actually I want to mount one of my host directory (let's call it /test) to 
> the OpenBSD system(guest as /test) using 9p FS 
> . Since OpenBSD doesn't come with 
> inbuilt 9P software I have installed plan9port on my BSD machine . But I am 
> confused on how to mount the host directory to OpenBSD using 9pfuse. I have 
> already searched for this but I couldn't find any hint on that. I would be 
> greatfulif anyone could help me out in mounting my host machines directory to 
> OpenBSD as 9P File system.
> 
> Thanking You in advance.
> 
> Best,
> RT
> *9fans * / 9fans / see discussions 
>  + participants 
>  + delivery options 
>  Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T6bef8e6b70bc5d0b-Mbd28c4ab6be1a9dfb724907c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] `test -x` returns wrong results for directories

[Ethan Gardener]

On Mon, Jun 8, 2020, at 3:13 AM, Charles Forsyth wrote:
>> "search" is exactly the wrong word for what this bit does, because if you 
>> don't have "search" permission, the one thing you can still do is look at 
>> the names.
> 
> in ramfs, but that's a bug that no-one had noticed 

oh it's the same in cwfs and in linux. if i remember right, (and i think i do,) 
it's always been this way in linux. (tried linux tmpfs recently, but i think 
permissions are enforced by the kernel 'over there', and i'm pretty sure it was 
the same on ext2 in linux 2.0.) i'd try some other unixes, but i have too much 
work to do today.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M7b2a2c3581f03b37fca88b23
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] `test -x` returns wrong results for directories

[Ethan Gardener]

On Sat, Jun 6, 2020, at 10:13 PM, o...@eigenstate.org wrote:
> > it's open() which is failing. i suppose it should.
> > 
> > if the open fails, maybe access should stat the file, and if it's a
> > directory, try dirread(2). or maybe just opening it for reading will
> > work. i don't know, i'm new to this bit of plan 9 & i haven't slept.
> 
> This is a bit subtle, though -- if you want
> to check if *you* can traverse the directory,
> then simply checking for an execute bit isn't
> enough -- you need to check that you belong to
> a group that has the execute bit.
> 
> On a related note, execute permission seems
> to behave strangely in general. You can create
> a directory and list it:
> 
> 
> Even without execute permission it's listable.
> Makes sense.

sarcasm? i've been confused about search permission since my earliest linux use 
where i experimented with permissions to see what, exactly, they did. it made 
no sense then, even without plan 9 leaving permission checks up to the 
individual filesystems. (this would have been linux 2.0.0)

> 
>   cpu% mkdir -p d/a/b
>   cpu% touch d/x
>   cpu% chmod -x d
>   cpu% ls -ld d
>   d-rw-r--r-- M 81 ori ori 0 Jun  5 07:53 d
>   cpu% ls d
>   d/a
>   d/x
> 
> As expected, it can't be traversed:
> 
>   cpu% ls d/x
>   ls: d/x: 'd/x' does not exist
> 
> But, you can cd into it:
> 
>   cpu% cd d
> 
> And list '.':
> 
>   cpu% ls
>   a
>   x
>   cpu% ls .
>   a
>   x
> 
> Can't traverse it to list subdirectories,
> though:
> 
>   ls a
>   ls: a: 'a' access permission denied
>   cd a
>   Can't cd a: 'a' access permission denied
>   cpu% cd ..
>   Can't cd ..: '..' access permission denied
> 
> So, cd'ing into a directory withut +x leads
> to an inescapabler trap.
> 
> Perhaps 'cd' should prevent entering that
> directory.

thanks for your analysis too, although you didn't say what filesystem you're 
using. i had to laugh at that trap; doesn't software get ridiculous sometimes? 
but it made me think, because charles said fossil doesn't handle the execute 
bit properly. perhaps once plan 9 went open source & had a public contrib, 
someone made just such a trap in contrib and fossil's permission handling was 
changed to stop it happening again. regardless of the cause, fossil just moved 
up another notch in my estimation because directory search restriction is so 
broken.

i just checked linux 2.6.30. (old vm i had handy.) it's much like you describe 
except there is no trap. cd is indeed prevented and if you're in the directory 
when "search" permission is revoked, you can't list it but you can `cd ..`.

"search" is exactly the wrong word for what this bit does, because if you don't 
have "search" permission, the one thing you can still do is look at the 
names... which lets you search them! it's more like "permission to open the 
display case and touch the things inside" or "permission to step over the 
museum's rope barriers".

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-Mce9e440c1218f5ab33129df6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] `test -x` returns wrong results for directories

[Ethan Gardener]

On Sat, Jun 6, 2020, at 2:25 PM, Charles Forsyth wrote:
> execute permission on files, meaning here non-directories, is a special 
> variant of read. a file with mode 0111 can be opened with OEXEC and read(2) 
> will work as well as exec(2),
> but can't be opened with OREAD, because it's not got any of 0444 set. bits 
> 0111 distinguish a file with contents that are intended to be executed once 
> read from files with only 0444 that do not contain executable content.
> you wouldn't want every readable file to be executable (especially if you've 
> used systems that didn't have that distinction).
> on the other hand, in a distributed file system, the client needs the 
> contents of the file to run it (whether code or #!script) so it needs to be 
> able to read files with just OEXEC.
> I suppose the rule could have been that it would need mode 5 (r+x) to make 
> clear that the file was also readable, but it isn't.
> 
> that OEXEC allows reading isn't true for a directory because exec means 
> "search", so if it's mode 0111 (say) you can chdir into it but not read the 
> names within it.
> if you know a name of a file in that directory, though, you can still open 
> that. that's entirely enforced by the server.
> 
> as the bug in access(2) suggests, only the server knows whether access should 
> be granted, and the open call gets it to do that,
> but it doesn't work for OEXEC for directories as others have noted. perhaps 
> stat+chdir is the most accurate test, since you need x (search) permission to 
> walk(5) into a directory,
> but the caller won't thank you for the chdir (and there's no easy or certain 
> way back), and ... that restriction isn't enforced by fossil or ramfs. (ramfs 
> wrongly allows you to read a directory that's mode 0.)
> 
> probably the best thing is just to ignore the owner/group/other distinction, 
> and if the open(...OEXEC) fails, dirstat it, and if it's a directory with any 
> of 0111 set, it's fine (a little better than now).

thanks for the analysis, charles. the dirstat you suggest wouldn't do any good 
for my case because rc-httpd runs as user none. the common problem it's trying 
to catch is a directory which isn't world-readable & world-searchable. 770 750 
and 700 are common permissions. perhaps i should have rc-httpd just run the 
commands and test their status rather than trying to test ahead of time, but 
this would somewhat spoil the neat and simple design.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M84c47e7be623cb8feb49865e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] `test -x` returns wrong results for directories

[Ethan Gardener]

On Fri, Jun 5, 2020, at 8:22 PM, Richard Miller wrote:
> Looks to me like access(2) is not doing the right thing for directory
> execute (=search) permission.

thanks for the tip. access is a very simple function. it doesn't do the right 
thing, but there's a reason:

 BUGS
  Since file permissions are checked by the server and group
  information is not known to the client, access must open the
  file to check permissions.  (It calls stat(2) to check sim-
  ple existence.)

it's open() which is failing. i suppose it should.

if the open fails, maybe access should stat the file, and if it's a directory, 
try dirread(2). or maybe just opening it for reading will work. i don't know, 
i'm new to this bit of plan 9 & i haven't slept.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M6c82b233d9b0cabf21ca7512
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] `test -x` returns wrong results for directories

[Ethan Gardener]

in rc-httpd, i rely on `test -x` to check if a directory is searchable. this 
works in plan9port, 9base, inferno (with root from host fs), gnu coreutils, and 
freebsd. it doesn't work in 9front, nor in labs plan 9. (the labs version 
tested was a live-cd from 2010.)

term% test -x static ; echo $status
test 13436: false
term% ls -ld static
d-rwxrwxr-x M 24 ethan adm 0 Mar 15 14:58 static
term% man 1 test | grep -- -x
  -x fileTrue if the file exists and has execute permis-
term% 

the word 'wrong' in the subject may be a little strong, but there doesn't seem 
to be an alternative test for searchable directories other than mucking about 
with ls -l | sed or awk. test(1) has nothing to say on the matter.

for anyone using rc-httpd, the intended logic in rc-httpd/handlers/dir-index is 
this:
if(! test -r $full_path -a -x $full_path) {
a suitable workaround is to remove ` -a -x $full_path`.
9front's version of rc-http has a workaround which may break when test is fixed.
/rc/bin/rc-httpd/handlers/dir-index:/-x
if(! test -r $full_path -x $full_path){
in plan 9 and gnu coreutils, this effectively replaces the logical and (-a) 
with a logical or. freebsd reports an error, 'unexpected operator'.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tdd7a9b1b32d01f54-M4c8942fa39b91446ff4eb885
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 and Pine

[Ethan Gardener]

On Wed, Apr 29, 2020, at 7:46 PM, Thaddeus Woskowiak wrote:
> KDE Plasma
> uses a different input method meaning drawterm does not trigger the
> onscreen keyboard. 

You can use Plan 9's onscreen keyboard:
rio -k bitsy/keyboard

bitsy/keyboard has a scribble area which can be turned off with -n. See 
bitsy(1). You may have to recompile keyboard to change the font.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tca918503d5b19459-M5b6a63d38bd5ca6fc6d4386c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 and Pine

[Ethan Gardener]

this would be easy with a stylus on a resistive touchscreen and a few 
well-placed physical buttons.

on a progressive^Winaccurate touchscreen with no buttons, what changes would be 
required? strictly speaking, none at all: i've used plan 9 over vnc from my 
tablet with various interfaces. it's not strictly necessary to modify any of 
the programs, but... well, selecting text is the hard part. if i remember 
right, i always used kurt's trick: place brackets and double-click one of them. 
(for large selections, it's good even on a desktop) the vnc viewers i used had 
decent trackpad emulation. i prefer double-tapping on a touchscreen/pad to 
double-clicking a mouse, it's much less damaging to my joints. i suppose some 
might find it triggers the drag emulation, but i usually disabled drag because 
touchscreens are too inaccurate for drag to be useful in plan 9. besides, i 
always found it much easier to deliver a solid double-tap than the fiddly 
nonsense necessary to start drag emulation.

which vnc viewers were good? it's been a while, but one of the best ones had a 
bar at the bottom of the screen with buttons for right-mouse and control -- 
plan 9 interpretes control-b3 as b2. the rmb button modified the next tap. it 
was simple but quite effective. it reminds me of drawterm-ios, which if i 
understood right, (i never used it,) had 3 big buttons on-screen but off the 
drawing area. i've used a vnc viewer with onscreen buttons, but they were drawn 
on top of the display, leaving too little area visible. besides, i don't really 
want both hands on the screen. buttons which modify the next tap allow more 
flexibility in the way you hold the device, including the option to not hold it 
at all.

i found that one open-source vnc viewer for android to be awful. it got better 
over the years, but not better enough unless miracles have happened in the last 
year.

does anyone know what changes p9p has for apple multitouch trackpads? i recall 
one old-timer liking them much more than chording.

for some, all this may be moot; sl likes to use ed on his phone. i forget his 
full argument, but part of it is that phones are hard to type on, and so were 
teletypes. ;) i think poor/slow network was another part; he uses ed or sam -d 
with ssh and drawterm -G over mobile internet. i struggle with those editors 
specifically, but from other stuff i can confirm that keyboard-only use can be 
as good as anything else on a tablet. i think i'd like samterm on mobile.

...or you could plug a mouse into your phone. ;) i actually installed a game 
which told me "this is no good without a real mouse."

hmm... mouse cumbersome... so when are we getting a phone with a built-in 
trackpoint? ;) i had an idea for a tablet with 2 trackpoints; you'd use them 
both to pinch.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tca918503d5b19459-Meba0f16c03529273c344d6c5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] iOS drawterm

[Ethan Gardener]

On Tue, Mar 31, 2020, at 9:52 AM, yy wrote:
> 
> In case there is any interest, I would be glad of helping to port
> devwsys: https://bitbucket.org/yiyus/devwsys-prev/src/default/
> 
> Even if the goal is to have drawterm, this may be an easier middle
> step, since it would allow you to get something working first, and
> later you could use the same devices from drawterm.

indeed. it could be bound to drawterm -G if android or ios lets them talk to 
each other.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T69dec3540d033863-Ma2f61c291706a0ac44c1c18c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] iOS drawterm

[Ethan Gardener]

On Fri, Mar 27, 2020, at 5:51 AM, Anthony Sorace wrote:
> I mean, c’mon, now it practically *needs* drawterm...
> 
> https://www.instagram.com/p/B-OctqFhNnB/?igshid=rmqsml1hwqck

It also needs to be mounted vertically in a case which looks like the Blit. :D

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T69dec3540d033863-M0c484ae458a99effe00e5038
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 on virtual machine in Mac os

[Ethan Gardener]

On Wed, Mar 25, 2020, at 9:30 PM, Nicolas S. Montanaro wrote:
> VMware works excellently with 9front on macOS. No quirks - just install 
> as usual.

9vx doesn't even require installation as such, which is nice but doesn't matter 
so much in the long term. (but i did have trouble getting vmware itself 
installed in windows 7 a couple of years ago.) how is network setup in vmware?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta7f245368d4d10b8-Mf5bf10388ae5dfe3d5920c0e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 on virtual machine in Mac os

[Ethan Gardener]

On Wed, Mar 25, 2020, at 8:11 PM, Brian L. Stuart wrote:
> On Wednesday, March 25, 2020, 02:02:40 PM EDT, Ethan Gardener 
>  wrote:
> > i still miss 9vx. it was so convenient when it
> > worked. fun too; i had it full-screened in a little
> > ...
> 
> Was? I still use it everyday. It's my primary
> terminal. I have it take the root from my file
> server when I'm on my home network, and
> off a little local mini root when I'm not.

it doesn't work on 64-bit only linux or freebsd, and it can't work at all on 
windows due to some page size issue, so i haven't had an os to run it on for 
many years. that might not be quite true, i probably had multilib linux at some 
points, but i didn't need it when i ran plan 9 native on my laptops. i have 
ergonomic issues which are getting worse with age, and so i stopped using 
laptops.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta7f245368d4d10b8-M6f3c5567303ae6efd833d6d9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan9 on virtual machine in Mac os

[Ethan Gardener]

On Wed, Mar 25, 2020, at 6:39 AM, Cyber Fonic wrote:
> I have been using Russ Cox's 9vx  on OS/X Mavericks 
> with considerable success. The only issue being that I need to connect a 
> Logitech 3 button mouse via a Unifying RF dongle (BlueTooth mice don't work 
> for me).

i still miss 9vx. it was so convenient when it worked. fun too; i had it 
full-screened in a little laptop & it felt like it was native. i've tried to 
use inferno in the same way, but i found it rougher than plan 9 and it lacks 
awk.

> Personally I find the 9vx environment more to my liking as I can edit code 
> with vim, use Finder, etc using OS/X concurrently with Plan9 -- yes, I know 
> that is heretical to die-hard Plan9 folks, but I'm a *nix guy foremost and a 
> Plan9 newbie.

this was exactly how i used it until i got used to acme, but i also got used to 
eagle mode and badly missed that when i switched to native plan 9. i still miss 
it. if i could code half as well as i'd like to, we'd have a zui file manager & 
notes organizer by now.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta7f245368d4d10b8-Mca78898a5a2ca126c758ffce
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] iOS drawterm

[Ethan Gardener]

how about vnc + drawterm -G; 2 connections? just a wild suggestion. -G (no 
graphics) is a feature of 9front's drawterm, but i think it should connect to 
labs.

red cursor is a little 9front hack; it's transparent to red only. i'm sure it 
could be reverted fairly easily, but the cursor is too small when the dpi is 
very high. client-side cursor would be much larger on my windows machines, 
presumably others too.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T69dec3540d033863-Mc5715f2b5175f52871d76357
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Help with Interpretation

[Ethan Gardener]

On Mon, Jan 6, 2020, at 12:19 AM, Frank D. Engel, Jr. wrote:
> 
> I built the file server using a 32-bit 386 kernel but I think 64-bit 
> CWFS was used?

64-bit CWFS just means it uses larger addresses for larger disks & files, it's 
nothing to do with the system architecture. If I remember right, smaller/older 
CWFS uses 56 bits, but that leaves me wondering why the change was made. (56 
bits can address 72e15 bytes.)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta16a4beaa5de93c0-M1092349edcc58b2c60f7f2d9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Object Icon, drawterm, riox

[Ethan Gardener]

On Sun, Jan 5, 2020, at 4:13 PM, hiro wrote:
> i object indeed. it's insulting what they did to those programs.

Indeed! It's been a while since I felt strongly enough to close a page in 
disgust. "Transient windows" indeed.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T888cf1c8059b63ab-Ma55b2176153c89512dce85b0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9port on osx

[Ethan Gardener]

> i cannot find a plan9port maillist, so i am asking here.

it's called plan9port-dev and it's on google groups:

https://groups.google.com/forum/#!forum/plan9port-dev

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Teef4e32e6f6c10de-M1d6b3a480cfecfb3a249bd28
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: moving 9fans to new server, but still 9fans@9fans.net

[Ethan Gardener]

On Wed, Oct 23, 2019, at 8:38 AM, Anthony Martin wrote:
> Ethan Gardener  once said:
> > As for the footer, I'm sure I'll be glad to have the permalink in every
> > email, and it's not in the headers.
> >
> > [...]
> >
> > Permalink: 
> > https://9fans.topicbox.com/groups/9fans/T73a7388a716e3644-M377ada983df012733fe78595
> 
> It is in the headers:
> 
> Archived-At: 
> <https://9fans.topicbox.com/groups/9fans/T73a7388a716e3644-M377ada983df012733fe78595>

Ah, then there's a deficiency in both the standard and my mail client. I see 
this in the headers:

Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?=
 =?UTF-8?B?ZmFucy9UNzNhNzM4OGE3MTZlMzY0NC1NM2I5MjYyMGQzNzhiYTIwNTA2NGNh?=
 =?UTF-8?B?MDg0Pg==?=

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T73a7388a716e3644-Me91b97a1190ba8eadb75c643
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: moving 9fans to new server, but still 9fans@9fans.net

[Ethan Gardener]

Glad the changeover was successful. :)

On Fri, Oct 11, 2019, at 8:14 PM, hiro wrote:
> i received a lot of html here.
> 
> in addition to the original html sent by the authors there is now even
> more html stuff, e.g. those footers:
>  9fans / 9fans / see discussions + participants + delivery options
> Permalink
> 
> there's also a plaintext version of this, adding 5 lines to every
> email. all this seems quite redundent if you ask me.

There's no html in your mail, at least.  

As for the footer, I'm sure I'll be glad to have the permalink in every email, 
and it's not in the headers.

I'm not commenting on the size of the headers though. :)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T73a7388a716e3644-M377ada983df012733fe78595
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] aux/timesync -n doesn't work

[Ethan Gardener]

On Sun, Sep 22, 2019, at 11:01 AM, Richard Miller wrote:
> > I don't think I ever had a reason for that assumption beyond laziness and 
> > craziness.
> 
> Not so crazy.  RTFMing in Plan 9 requires close attention - minimalist style
> means every word matters. 

Thanks!  The trouble is I knew that; 9 or 10 years ago, I was telling other 
people!  I don't know what happened, but it's been a long time since I wanted 
to put everything aside and clear my head to just read the instructions.  
Hmm... these days, I don't think my mood would let me if I tried.  I think I 
might be able to fix that.  

Re: [9fans] building Alef language

[Ethan Gardener]

On Sun, Sep 22, 2019, at 10:38 AM, Rodrigo G. López wrote:
> so you need them running in order to execute them publicly, in front of the 
> go masses.

I don't think it's quite that bad. (But maybe it is! XD )

Re: [9fans] I went down a Forth rabbit hole and found Glenda

[Ethan Gardener]

Replying to the subject, I'm surprised there's not more association between 
Forth and Plan 9. Both seem to be based on changing design goals to make the 
software simple. ;) The biggest difference for me is the Forth world tells you 
how. (It's a bigger world, so there are more people to write books, I guess.) 
In Plan 9, we just get heavily-factored C code without explanation. Not knowing 
why it's factored, we misapply the term "bikeshedding". I knew I should have 
read Thinking Forth years ago.

Now I'm wondering how much of Plan 9 development time went into factoring for 
minimalism.

Re: [9fans] building Alef language

[Ethan Gardener]

On Fri, Sep 20, 2019, at 9:45 PM, Phil Kulin wrote:
> 
> # I don't know why, but "tar x alef.tgz" command do nothing...

You requested to extract a file named alef.tgz from a tar stream on standard 
input. ;) You need the f option to specify a tar file.

Re: [9fans] aux/timesync -n doesn't work

[Ethan Gardener]

On Thu, Sep 19, 2019, at 11:11 AM, Richard Miller wrote:
> > # when timesync(8) says "$ntp", it's lying.
> 
> Actually it's not.  But it depends on having a definition
> for ntp= associated with your host or [sub]network in the
> ndb database.

Oh of course! I wrote a top-level definition in ndb, assuming it would be 
inherited by networks and hosts. I don't think I ever had a reason for that 
assumption beyond laziness and craziness.

Re: [9fans] aux/timesync -n doesn't work

[Ethan Gardener]

On Tue, Sep 10, 2019, at 3:20 PM, Олег Бахарев wrote:
> aux/timesync doesnt work in raspberry pi 2. How to fix this problem ?

I could never get it working until I did this:

term% cat /rc/bin/termrc.local
# timesync
# when timesync(8) says "$ntp", it's lying.
rm -f /sys/log/timesync
TIMESYNCARGS=(-na100 2.europe.pool.ntp.org)
term% 

I'm not sure what the rm was for, but it's not needed now. It must have been a 
debug option. I think I remember timesync complaining if /sys/log/timesync 
existed when it started up.

Re: [9fans] printing from Plan 9

[Ethan Gardener]

On Sat, Sep 14, 2019, at 10:04 AM, Richard Miller wrote:
> Before replacing my expiring inkjet printer I thought I'd ask
> the list: does anyone still use lp(1) nowadays, and are there
> printers currently on the market which work well with Plan 9?

I got an Epson because they have an email print service. It supports pdf, but 
not ps. Is that any good? Maybe you could filter through ps2pdf(1).

I just realised I never tried it before, so I sent it an email with empty 
subject, empty body, attached il.pdf; it printed out fine apart from a 1-2 
minute delay before it began. Results are identical to printing from a PDF 
reader on Windows with default settings, apart from not being vertically 
centered on the page. I imagine it would be better if ps2pdf was given the 
correct paper size; il.pdf is set for taller paper than I have.

The setup to get the email address for the printer was fairly brief, involving 
a web page if I remember right. Nothing like setting up anything on Linux. You 
get an email address unique to your printer.

https://www.epsonconnect.com/

https://www.epsonconnect.com/guide/en/html/uses_1.htm

Re: [9fans] Plan 9 security

[Ethan Gardener]

On Tue, Aug 20, 2019, at 2:29 PM, Don A. Bailey wrote:
> 
> Fwiw Plan 9’s code vase has indeed been audited. By me. Several exploitable 
> bugs were found including a kernel exploit due to the env driver. I wrote a 
> working PoC for it which is somewhere on the internet, but it’s quite old.

My apologies!

> Much of the code hasn’t changed, and, I would suspect, is largely secure.

Good to know. :)

I wonder how many relevant parts have changed in 9front?  There are regular 
kernel changes, some of which were made to handle the heavy shell-script load 
of running werc sites.  (For a short time, the load on cat-v.org was very 
heavy.)

> But you’re talking implementation security versus architectural security. In 
> the case of IoT, Plan 9 does exceptional things to close the gaps that 
> embedded systems supply its users, but it is nowhere near complete.

I guess I am, and yes, Plan 9 is sadly incomplete in many areas.  

[9fans] Plan 9 security

[Ethan Gardener]

On Mon, Aug 19, 2019, at 12:53 PM, Cyber Fonic wrote:
> 
> It has been said : "The 'S' in IoT stands for security". If Plan9 can address 
> that deficiency of the current state of the art for IoT devices, then it 
> would be a worthwhile exercise.

Plan 9 may have a decent security model, but it's never been audited.  Auditing 
a codebase, even one as small as Plan 9's, is a lot of work.  Are you willing 
to make a start on it?

If you want something free and already audited, with more security features, 
(but perhaps not quite the same convenience,) look into OpenBSD.

-- 
I love that *Open*BSD is so *security*-focused!

Re: [9fans] Plan9 on radpberry pi zero ?

[Ethan Gardener]

On Fri, Aug 16, 2019, at 2:26 PM, Олег Бахарев wrote:
> 
> Do you mean something like BlackIce II (I'm under RV32I)? There is still one 
> interesting board (inexpensive) on the RISC V 64 bit (RV64IMAG) - if you want 
> I will show where to get

Yes please

Re: [9fans] Someone made a Wayland compositor based on Rio, Wio

[Ethan Gardener]

On Tue, May 7, 2019, at 5:17 AM, Lucio De Re wrote:
>  Keep in mind where Minix-3
> lurks, before you discount it...

I didn't discount Minix-3 until I learned it's recently started using memory 
protection, and they're having trouble making it work with their IPC.  I'll 
wait until they've got it sorted.