>> As a result, if we have a timestamp like this:
>>
>> Jan 1 2013, 7:00 PM EST
>>
>> will not be able to deal with the timezone component.
>
> And now that I've started poking at converting code like
> seconds(1), it looks like I'm going to need to solve it.
> I'm thinking that I want to
> As a result, if we have a timestamp like this:
>
> Jan 1 2013, 7:00 PM EST
>
> will not be able to deal with the timezone component.
And now that I've started poking at converting code like
seconds(1), it looks like I'm going to need to solve it.
I'm thinking that I want to add /adm/time
yes, this is a known issue in this release and it has already
been fixed here:
https://code.9front.org/hg/plan9front/rev/cc5c37116d5e
i did not have the time to schedule a new binary release.
if you want you can try the "unofficial" kernels linked
below and copy them on the sdcard.
raw kenrel:
> Hi folks,
> After the mice problems I have on my rpi2 with 9front [1], I
> decided to check if I can have an instance working on another
> machine, i.e. an old rpi model A. I cannot get through the
> boostrap process, the kernel panics.
Thanks for the reports. Two things:
0) It's going to be ve
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. Se
Hi folks,
After the mice problems I have on my rpi2 with 9front [1], I decided to check
if I can have an instance working on another machine, i.e. an old rpi model A.
I cannot get through the boostrap process, the kernel panics.
I can provide more context and information, but first I wanted to a
