2009/7/28 J.R. Mauro :
> One caveat about E: if you're paranoid like I am and save your file
> many times while editing, E will not be terribly friendly until you
> train yourself to save only when finished. (This is not a criticism of
> E, it is merely a warning to people with my kind of idiosyncr
> * set up venti manually after the install, and after I've set the timezone
Sorry if I'am being a pedant, but its not the timezone - that
is an offset that effects how dates and times are printed, plan9
like Unix always uses UTC for all time/date stamps. The problem is
the time in the RTC chip wa
On Tue, 28 Jul 2009 02:59:19 -0300
"Federico G. Benavento" wrote:
> "This video is not available in your country due to copyright restrictions."
Odd that. Search for _One Is the Loneliest Number_ by _Three Dog Night_ if you
want to hear it. It's a bit of a classic.
>
> On Tue, Jul 28, 2009 at
>the unicode proposal says that matches depend on (re, locale, input).
>not just (re, input). i would think that is not acceptable.
it's not just the unicode people. shell file name matching takes locale into
account
which often makes it case-independent (even with case-dependent
file systems).
> > -L used with -r to indicate the real time clock is in
> >local time rather than GMT. This is useful on PCs that
> >also run the Windows OS.
> >
>
> I must be stuck in some sort of logic error, so please correct me where I'm
> wrong:
>
> * the Plan
On Tue, 28 Jul 2009 11:39:46 +0100
Charles Forsyth wrote:
> >the unicode proposal says that matches depend on (re, locale, input).
> >not just (re, input). i would think that is not acceptable.
>
> it's not just the unicode people. shell file name matching takes locale into
> account
> which o
On Tue, Jul 28, 2009 at 7:11 AM, Ethan Grammatikidis wrote:
> On Tue, 28 Jul 2009 11:39:46 +0100
> Charles Forsyth wrote:
>
>> >the unicode proposal says that matches depend on (re, locale, input).
>> >not just (re, input). i would think that is not acceptable.
>>
>> it's not just the unicode peo
I don't think we need to debate the exact semantics of
time on Plan 9 in order to figure this out.
It's easy to believe that the installer and the main distribution
end up with different time settings, no matter what the exact
details are. The right fix is probably to comment out the print
in ven
On Tue, 28 Jul 2009 07:52:14 -0700
John Floren wrote:
> On Tue, Jul 28, 2009 at 7:11 AM, Ethan Grammatikidis
> wrote:
> > On Tue, 28 Jul 2009 11:39:46 +0100
> > Charles Forsyth wrote:
> >
> >> >the unicode proposal says that matches depend on (re, locale, input).
> >> >not just (re, input). i
Okay, it's authsrv(2) that describes the nvram search sequence. And for
whatever reason I had it in my head that these days it was possible to
grab the nvram across the wire, which in hindsight makes no sense
whatsoever. And now that I think about it, my last (2ed) 'diskless' CPU
server had a f
On Tue Jul 28 14:00:22 EDT 2009, lyn...@orthanc.ca wrote:
> Okay, it's authsrv(2) that describes the nvram search sequence. And for
> whatever reason I had it in my head that these days it was possible to
> grab the nvram across the wire, which in hindsight makes no sense
> whatsoever. And now t
On Tue, Jul 28, 2009 at 10:58 AM, Lyndon Nerenberg wrote:
> Okay, it's authsrv(2) that describes the nvram search sequence. And for
> whatever reason I had it in my head that these days it was possible to grab
> the nvram across the wire, which in hindsight makes no sense whatsoever. And
> now that
Ever wish you had more GUI programs on Plan 9 to show off to your
friends? Do you think Mothra represents the very pinnacle of UI
design? Then have I got a program for you...
I've spent the last day or so whipping up a quick libpanel application
to read USENET via nntpfs. You can read newsgroups (
> i guess i need to update this man page. i didn't recall the
> search algorithm was documented. thanks for pointing that out.
sorry for the obtuse reference. now that i've made it on the list,
i'll just explain myself. i made a local change to how
nvram is found because i kept needing to upda
> years back I modified the library so that it could use the cmos nvram.
> no more disk. We used this when Andrey
> put plan 9 in FLASH.
>
> It was nice to not have any spinning media for nvram.
>
> It gets a little tricky because cmos is not sane in where you can
> store bits, but it's doable.
Hi, all
I boot diskless (very obsolete PC) embedding the nvram data in the kernel.
Basically I implemented a fake-nram driver and declare it in the plan9.ini
It's just a trick but works.
If such a solution could be useful for the community I would be happy
to deliver the source.
adriano
> The right fix is probably to comment out the print in venti
> and move on, which you have already done.
I'd suggest: if the time is off by more than 24 hours, warn once.
That will mean timezone problems will be silently ignored, but
something "really odd" will still make it presence known.
> If
On Tue Jul 28 18:16:08 EDT 2009, davide...@cs.cmu.edu wrote:
> > The right fix is probably to comment out the print in venti
> > and move on, which you have already done.
>
> I'd suggest: if the time is off by more than 24 hours, warn once.
> That will mean timezone problems will be silently ignor
On Tue, Jul 28, 2009 at 12:24 PM, erik quanstrom wrote:
> i don't believe this is safe for an arbitrary (rtc device, bios vendor).
> i may have missed something, since some of the bios in question
> are obsolete.
Hard to say. newer rtc has a whopping doubled-size CMOS and the BIOS
vendors don't s
On Tuesday 28 July 2009 06:22:19 erik quanstrom wrote:
> > > -L used with -r to indicate the real time clock is in
> > >local time rather than GMT. This is useful on PCs that
> > >also run the Windows OS.
> >
> > I must be stuck in some sort of logic err
On Tue, Jul 28, 2009 at 2:55 AM, sqweek wrote:
> 2009/7/28 J.R. Mauro :
>> One caveat about E: if you're paranoid like I am and save your file
>> many times while editing, E will not be terribly friendly until you
>> train yourself to save only when finished. (This is not a criticism of
>> E, it is
On Tuesday 28 July 2009 15:16:23 erik quanstrom wrote:
> On Tue Jul 28 18:16:08 EDT 2009, davide...@cs.cmu.edu wrote:
> > > The right fix is probably to comment out the print in venti
> > > and move on, which you have already done.
> >
> > I'd suggest: if the time is off by more than 24 hours, warn
On Mon, Jul 27, 2009 at 1:41 PM, C H Forsyth wrote:
> I've no idea why the current owners of that domain name bother
> to keep it registered. Perhaps there's a little back story there;
> I don't know.
Likely Google juice, there are still plenty of high-rank links
pointing there lying around the ne
On Tuesday 28 July 2009 11:19:08 John Floren wrote:
> Ever wish you had more GUI programs on Plan 9 to show off to your
> friends? Do you think Mothra represents the very pinnacle of UI
> design? Then have I got a program for you...
>
> I've spent the last day or so whipping up a quick libpanel app
On Tue, Jul 28, 2009 at 7:52 PM, Corey wrote:
> On Tuesday 28 July 2009 11:19:08 John Floren wrote:
>> Ever wish you had more GUI programs on Plan 9 to show off to your
>> friends? Do you think Mothra represents the very pinnacle of UI
>> design? Then have I got a program for you...
>>
>> I've spen
> #6 - reboot, (first-time login), as glenda:
> - remove -L switch from $TIMESYNCARGS in /rc/bin/termrc
if the time was already correct modulo timezone, why did you do this?
also, after allowing the machine to run for some time, does timesync
cause the system time (date -n) to jump? i.e
On Tuesday 28 July 2009 16:50:15 erik quanstrom wrote:
> > #6 - reboot, (first-time login), as glenda:
> > - remove -L switch from $TIMESYNCARGS in /rc/bin/termrc
>
> if the time was already correct modulo timezone, why did you do this?
>
My (ill-founded?) reasoning went like this:
* -L
> Approximately how long is 'some time'? (so I know how long to wait)
5-10 minutes. /sys/log/timesync should be informative.
> My point though is that yes, it makes the timezone change take
> effect immediately - and it likewise causes the 'creation time after
> last write time' /dev/kprint's t
On Tue, Jul 28, 2009 at 3:16 PM, erik quanstrom wrote:
> ignoring little bugs is the path to ruin.
That's why the print should just go away entirely.
The code assumes that the time from one boot
to the next only ever increases, which has been
demonstrated not to be true. Maybe during one
boot you
On Tuesday 28 July 2009 18:42:05 Russ Cox wrote:
> On Tue, Jul 28, 2009 at 3:16 PM, erik quanstrom
wrote:
> > ignoring little bugs is the path to ruin.
>
> That's why the print should just go away entirely.
> The code assumes that the time from one boot
> to the next only ever increases, which has
30 matches
Mail list logo
