On March 15, 2024 3:04:56 PM EDT, Stanley Lieber <sl@stanleylieber.com> wrote:
>http://git.9front.org/git/plan9front/plan9front/6c9c2beb6e54a2ced1466615452e338d9bb7d48d/commit.html
>
>existing installations will need to create a new log file.
>
>sl
>
my mistake, distproto already does the right thing.
sl
http://git.9front.org/git/plan9front/plan9front/6c9c2beb6e54a2ced1466615452e338d9bb7d48d/commit.html existing installations will need to create a new log file. sl
very nice summary, thanks! :)
On Fri, Mar 15, 2024 at 2:20 AM <sl@stanleylieber.com> wrote:
>
> since 2005, some thinkpads have shipped with integrated, transparent
> wacom tablets overlaying the screen. the x41, x60, and x61 tablets
> were all serial devices. the x230 and x1 yoga 3rd gen tablets are usb
> devices. all of these have been previously made to work in 9front.
> aiju wrote a driver[0] for the serial ones, while the usb ones "just
> work" and are treated as usb mice[1].
>
> the x1 tablet series took a different tack. these tablets are ps/2
> devices:
>
> x1 tablet 1st/2nd gen: wacom hid 5115
> x1 tablet 3rd gen: wacom hid 511a
>
> both of these were at some point added to linuxwacom[2][3][4], and
> they work fine for me with wayland under alpine linux.
>
> where do we start to try and make these work in 9front? i have both
> machines and can hack/test/etc., but i'm a dog sitting at a keyboard
> and i have no idea what i'm doing.
>
> if this requires more than a trivial effort i am willing to put up
> another bounty to fund the work.
>
> sl
>
> [0] http://fqa.9front.org/fqa3.html#3.2.4.1
> [1] http://fqa.9front.org/fqa3.html#3.2.4.2.1
> [2] https://linux-hardware.org/?id=ps/2:wacom-5115-hid-5115-pen
> [3] https://linux-hardware.org/?id=ps/2:wacom-5115-hid-5115-finger
> [4] https://linux-hardware.org/index.php?id=ps/2:wacom-511a-hid-511a-pen
since 2005, some thinkpads have shipped with integrated, transparent wacom tablets overlaying the screen. the x41, x60, and x61 tablets were all serial devices. the x230 and x1 yoga 3rd gen tablets are usb devices. all of these have been previously made to work in 9front. aiju wrote a driver[0] for the serial ones, while the usb ones "just work" and are treated as usb mice[1]. the x1 tablet series took a different tack. these tablets are ps/2 devices: x1 tablet 1st/2nd gen: wacom hid 5115 x1 tablet 3rd gen: wacom hid 511a both of these were at some point added to linuxwacom[2][3][4], and they work fine for me with wayland under alpine linux. where do we start to try and make these work in 9front? i have both machines and can hack/test/etc., but i'm a dog sitting at a keyboard and i have no idea what i'm doing. if this requires more than a trivial effort i am willing to put up another bounty to fund the work. sl [0] http://fqa.9front.org/fqa3.html#3.2.4.1 [1] http://fqa.9front.org/fqa3.html#3.2.4.2.1 [2] https://linux-hardware.org/?id=ps/2:wacom-5115-hid-5115-pen [3] https://linux-hardware.org/?id=ps/2:wacom-5115-hid-5115-finger [4] https://linux-hardware.org/index.php?id=ps/2:wacom-511a-hid-511a-pen
Make WiFi go faster. $100 We already live with a theoretical hard limit of 54mbps. In practice, no WiFi card supported by 9front comes anywhere close to achieving that hard limit. Some newer cards (Intel 7260, 8265, 9620) even exhibit slower throughput than older cards. All of this combined with 9p latency really sucks. Please make WiFi go fast and I will pay you $100. Acceptable results include "cards capable of throughput approaching 54mbps consistently exhibit throughput approaching 54mbps" and "cards capable of throughput greater than 54mbps consistently exhibit throughput greater than 54mbps. http://fqa.9front.org/appendixb.html sl
Some of you may have noticed that the original deadline for the camera-ready copy of papers and the WiP reports is today. The committee has decided to extend that deadline by one week. So anyone for whom the edits have slid to the back burner, you've got a reprieve. After the new deadline on the 20th, we'll work on putting the online proceedings together. Thanks, BLS
> I would vote for not changing the code example, but adding a clarifying comment:
>
> On the first run, auth/secstore -g factotum will result in an error because the file does not exist yet. This error can be ignored.
this has been accomplished.
sl
[-- Attachment #1: Type: text/plain, Size: 398 bytes --] Somewhat tangentially, I am in the beginning of working on a kernel for the RK3308 (and learning kernel stuff along the way), but am trying to go u-bootless and boot directly to 9 currently; this invariably requires their blobs (at least I think it does) currently. I only have a basic bare-metal UART going as of now (and, it was just yesterday I discovered it was functionally an 8250..). -Aidan [-- Attachment #2: Type: message/rfc822, Size: 4096 bytes --] From: adventures in9 <adventuresin9@gmail.com> To: 9front@9front.org Subject: Re: [9front] mnt reform rcore rk3588 Date: Mon, 11 Mar 2024 14:31:44 -0700 Message-ID: <CAPfmpJDNRnKRnAyUJbXX4tDYW-J1biz7JDv1FRhcdpP=JOBGwQ@mail.gmail.com> I have done some basic 9front kernels with some help from Cinap for the rk3399 and rk3568. Not much beyond getting it to boot and talking on a uart. With the new generic Arm64 kernel, I would want to redo them to work with that. https://github.com/adventuresin9/9front-rk3399 https://github.com/adventuresin9/9front-rk3568 I had heard about this new module for the Reform, and the rk3568 shares 4 A55 cores with the rk3588. However, the rk3588 also has an additional 4 A76 cores. My experience so far with Rockchip; Documents are not too hard to come across. They tend to use standard uarts, and other peripherals tend to be stuff from Designware, so getting information on those from the BSD's is pretty easy. They seem to just use Mali for graphics on all their chips. On Mon, Mar 11, 2024 at 8:53 AM Stanley Lieber <sl@stanleylieber.com> wrote: > > anyone thinking about getting one of these and making 9front run on it? > > https://community.mnt.re/t/mnt-reform-rcore-rk3588-processor-module-release/1924 > > maybe mnt would even donate one? > > sl
I have done some basic 9front kernels with some help from Cinap for the rk3399 and rk3568. Not much beyond getting it to boot and talking on a uart. With the new generic Arm64 kernel, I would want to redo them to work with that. https://github.com/adventuresin9/9front-rk3399 https://github.com/adventuresin9/9front-rk3568 I had heard about this new module for the Reform, and the rk3568 shares 4 A55 cores with the rk3588. However, the rk3588 also has an additional 4 A76 cores. My experience so far with Rockchip; Documents are not too hard to come across. They tend to use standard uarts, and other peripherals tend to be stuff from Designware, so getting information on those from the BSD's is pretty easy. They seem to just use Mali for graphics on all their chips. On Mon, Mar 11, 2024 at 8:53 AM Stanley Lieber <sl@stanleylieber.com> wrote: > > anyone thinking about getting one of these and making 9front run on it? > > https://community.mnt.re/t/mnt-reform-rcore-rk3588-processor-module-release/1924 > > maybe mnt would even donate one? > > sl
I ordered one.
anyone thinking about getting one of these and making 9front run on it? https://community.mnt.re/t/mnt-reform-rcore-rk3588-processor-module-release/1924 maybe mnt would even donate one? sl
11.03.2024 14:43:48 orjan <oras9@telia.com>:
> After help from sirjofri on discourse and some man page reading I gradually started to understand the the error msg was correct. At this point the file doesn't exist.
>
> So my suggestion is to add:
>
> % touch factotum
>
> %auth/secsstore -p factotum
>
> before the line triggering the error msg.
I would vote for not changing the code example, but adding a clarifying comment:
On the first run, auth/secstore -g factotum will result in an error because the file does not exist yet. This error can be ignored.
sirjofri
When I was following the instructions: % ramfs -p; cd /tmp %auth/secstore - g factotum secstore password:[ user pw] after entering the pw I got an error msg: remote file missing After help from sirjofri on discourse and some man page reading I gradually started to understand the the error msg was correct. At this point the file doesn't exist. So my suggestion is to add: % touch factotum %auth/secsstore -p factotum before the line triggering the error msg. I'm sorry I have not yet learned to make a patch, I have started to read.. /örjan
> Is 9front widely considered to be the successor to Plan9, in the sense
no.
the problem is that plan9 is not widely considered in the first place.
of the few people that heard about plan9, i suspect fewer have heard
about 9front. this is a testament to the stability of this ecosystem.
C code is portable, between architectures, and also between plan9
forks.
Quoth Jay F. Shachter <jay@m5.chicago.il.us>:
>
> This is a 9front mailing list, to which Plan9 questions are routinely
> asked (e.g., "What is the Plan 9 equivalent of uname?").
>
> Is 9front widely considered to be the successor to Plan9, in the sense
> that, e.g., Fortran90 is the successor to Fortran77, such that answers
> descriptive of Fortran90 can be given to a question about "Fortran"?
Depends who's answering. Why do you care?
On Sun, Mar 10, 2024 at 06:01:38PM -0500, Jay F. Shachter wrote: > > This is a 9front mailing list, to which Plan9 questions are routinely > asked (e.g., "What is the Plan 9 equivalent of uname?"). > > Is 9front widely considered to be the successor to Plan9, in the sense > that, e.g., Fortran90 is the successor to Fortran77, such that answers > descriptive of Fortran90 can be given to a question about "Fortran"? > Similarly, can an answer descriptive of 9front be given to a question > about Plan9? Or are there other incompatible operating systems that > claim to be the successor to Plan9? Fortan has a standards body. Plan 9 does not. I don't believe 9front is generally considered at all, much less generally considered to be anything. > (Parenthetically, and completely off-topic for this mailing list, the > most recent standardized version of Fortran is Fortran2023, but does > anyone in the real world actually use a version of Fortran that is > less than 34 years old?) Yes. The E3SM model uses Fortran95 with a subset of Fortran2003. khm
On March 10, 2024 7:01:38 PM EDT, "Jay F. Shachter" <jay@m5.chicago.il.us> wrote:
>
>This is a 9front mailing list, to which Plan9 questions are routinely
>asked (e.g., "What is the Plan 9 equivalent of uname?").
>
>Is 9front widely considered to be the successor to Plan9, in the sense
>that, e.g., Fortran90 is the successor to Fortran77, such that answers
>descriptive of Fortran90 can be given to a question about "Fortran"?
>Similarly, can an answer descriptive of 9front be given to a question
>about Plan9? Or are there other incompatible operating systems that
>claim to be the successor to Plan9?
>
>(Parenthetically, and completely off-topic for this mailing list, the
>most recent standardized version of Fortran is Fortran2023, but does
>anyone in the real world actually use a version of Fortran that is
>less than 34 years old?)
>
> Jay F. Shachter
> 6424 North Whipple Street
> Chicago IL 60645-4111
> (1-773)7613784 landline
> (1-410)9964737 GoogleVoice
> jay@m5.chicago.il.us
> http://m5.chicago.il.us
>
> "Quidquid latine dictum sit, altum videtur"
>
>
there's no official anything, and nobody writing 9front code really cares about names. 9front forked from bell labs plan 9 in 2011. the concepts, and most of the features remain the same. it's probay fine to refer to any of the existing forks of bell labs plan 9 as plan 9, especially since the ones that diverged widely enough to raise objections have mostly ceased to be developed.
sl
This is a 9front mailing list, to which Plan9 questions are routinely asked (e.g., "What is the Plan 9 equivalent of uname?"). Is 9front widely considered to be the successor to Plan9, in the sense that, e.g., Fortran90 is the successor to Fortran77, such that answers descriptive of Fortran90 can be given to a question about "Fortran"? Similarly, can an answer descriptive of 9front be given to a question about Plan9? Or are there other incompatible operating systems that claim to be the successor to Plan9? (Parenthetically, and completely off-topic for this mailing list, the most recent standardized version of Fortran is Fortran2023, but does anyone in the real world actually use a version of Fortran that is less than 34 years old?) Jay F. Shachter 6424 North Whipple Street Chicago IL 60645-4111 (1-773)7613784 landline (1-410)9964737 GoogleVoice jay@m5.chicago.il.us http://m5.chicago.il.us "Quidquid latine dictum sit, altum videtur"
> While I'm a firm believer in precedent, it's shouldn't be cast in
> granite. I firmly believe documenting command flags inline was a
> mistake. We should be able to admit that and fix it.
i don't need to admit anything that isn't true.
and btw, if you're bored... there's enough other more important things
to fix, work on.
On 3/10/24 16:03, Eli Cohen wrote:
> hey, well... ape/uname :)
>
ape/uname is pretty useless for the purpose
of what they were asking for. It just reads out
the various environment variables that were already
discussed.
- moody
10.03.2024 20:18:25 Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca>: > sirjofri writes: > >> I also like the idea of having an additional program that parses the source f >> ile for everything in between ARGBEGIN/ARGEND, combined with comments for des >> cription. Flags without comment could be omitted to have the option of omitti >> ng debug functionality, and it's easy enough to document with that. On the ot >> her hand, that puts part of the documentation into the source code, which is >> very much different from how man pages work. > > The trouble with this approach is it only works with the languages > it knows about. > > What if I write something in Fortran? Or Go? Or whatever other > language I port across. Whatever this is, it needs to be universal, > and I don't see a practical solution. That's a valid point. I was also briefly thinking about rc programs, and that has the same problem, basically (although we have a standard there). > I don't really believe the argument that people will read only > the flags documentation and ignore the manpage. Someone that lazy > is likely not reading the manpage at all. And anyway, that argument > is purely speculation. > > Whenever you read technical documentation, those sorts of enumerated > lists are almost always called out separately. There are several > reasons for that, readablilty being paramount. I also sometimes see man pages with both practices on the same page. While one part discussed the arguments inline, another section has a list/table of arguments that's suitable for a look-up table. That would of course lengthen the man pages, but also be helpful. I often find myself looking for all the print(2) arguments. I know how print works, so I don't need all the page, but the table only. Sometimes it would be nice to just open that part of the page and skip everything else, but there can't be a single solution for everything. > While I'm a firm believer in precedent, it's shouldn't be cast in > granite. I firmly believe documenting command flags inline was a > mistake. We should be able to admit that and fix it. I don't believe it's a mistake. I think "mistake" is a strong word for decisions like that. I'm sure the inventors invested lots of thought and discussion to get to this decision, although it doesn't seem like that in the modern light. Coming from a hypertext perspective, the format of the content is never "correct" for all use cases. You can present something as a list, as paragraphs, as a table, as a guided tour or even graphics. Just ask ChatGPT to tell you about the command line flags written as a poem. Useful? Probably not at all. Though that discussion leads to nothing and I know people don't like AI (for reasons). Better find a way to write documentation that helps most people in most cases. sirjofri
hey, well... ape/uname :)
On Sat, Mar 9, 2024 at 9:33 AM <rockyhotas@firemail.cc> wrote:
>
> Hello!
> I'm trying to move the first steps into Plan9.
> It is not Unix, the user is often warned about this. However, some tools
> are available in both systems with almost the same usage, like uptime(1)
> for example. Is there anything equivalent to `uname'? I couldn't find
> such a tool nor in
>
> <https://fqa.9front.org/fqa8.html>
>
> neither in
>
> <https://wiki.9front.org/unix2plan9>
>
> If there is not a perfect equivalent tool, is it anyway possible to list
> some basic information about the current system? For example the OS
> name,
> the kernel version, the architecture, the hostname.
>
> Bye!
>
> Rocky
sirjofri writes:
> I also like the idea of having an additional program that parses the source f
> ile for everything in between ARGBEGIN/ARGEND, combined with comments for des
> cription. Flags without comment could be omitted to have the option of omitti
> ng debug functionality, and it's easy enough to document with that. On the ot
> her hand, that puts part of the documentation into the source code, which is
> very much different from how man pages work.
The trouble with this approach is it only works with the languages
it knows about.
What if I write something in Fortran? Or Go? Or whatever other
language I port across. Whatever this is, it needs to be universal,
and I don't see a practical solution.
I don't really believe the argument that people will read only
the flags documentation and ignore the manpage. Someone that lazy
is likely not reading the manpage at all. And anyway, that argument
is purely speculation.
Whenever you read technical documentation, those sorts of enumerated
lists are almost always called out separately. There are several
reasons for that, readablilty being paramount.
While I'm a firm believer in precedent, it's shouldn't be cast in
granite. I firmly believe documenting command flags inline was a
mistake. We should be able to admit that and fix it.
--lyndon
On mar 09 11:42, Jacob Moody wrote:
>
> There is /dev/osversion but its not really particularly insightful.
> Uname is generally used to differentiate different Unixen from
> each other, so I don't see why it would be particularly useful
> on Plan 9.
>
> We also do not generally have version of the kernel per se,
> at least not in the same way something like Linux does.
Yes, in fact I thought kernel versions and OS type were handled
similarly to Linux or other Unix-like system, but that's not the case
for Plan9.
Thanks to you and to all those who added their suggestions.
You have been very helpful!
Rocky
On Sat, 9 Mar 2024, rockyhotas@firemail.cc wrote: > > If there is not a perfect equivalent tool, is it anyway possible to list > some basic information about the current system? For example the OS name, > the kernel version, the architecture, the hostname. > /rc/bin/sysinfo is also handy. Peace, Jon -- jrsharp@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org