cool! it seems you could implement an fs with unlimited name length
using the file-backed-strings and store the data as the file name;
very efficient.
On Wed, Feb 2, 2011 at 7:35 PM, wrote:
> ron minnich writes:
>
>> OK, let's do a test. You write your stuff with iterators and put it on
>> a ma
Plan 9 is a research operating system. It also happens that many
people who use it for research also use it in production.
Many of the engineering decisions that went into Plan 9 were a matter
of priorities. The creators of Plan 9 chose a simple, comprehensible C
compiler over more complex alterna
>usually with oversized log files.
sam -d, indeed!
On 3 February 2011 14:17, erik quanstrom wrote:
> On Thu Feb 3 09:17:27 EST 2011, rogpe...@gmail.com wrote:
>> i've found it very useful quite a few times.
>> usually with oversized log files.
>>
>> On 3 February 2011 13:59, erik quanstrom wrote:
>> > On Thu Feb 3 08:41:23 EST 2011, rogpe...@gm
On Thu Feb 3 09:17:27 EST 2011, rogpe...@gmail.com wrote:
> i've found it very useful quite a few times.
> usually with oversized log files.
>
> On 3 February 2011 13:59, erik quanstrom wrote:
> > On Thu Feb 3 08:41:23 EST 2011, rogpe...@gmail.com wrote:
> >> On 3 February 2011 13:01, erik quan
i've found it very useful quite a few times.
usually with oversized log files.
On 3 February 2011 13:59, erik quanstrom wrote:
> On Thu Feb 3 08:41:23 EST 2011, rogpe...@gmail.com wrote:
>> On 3 February 2011 13:01, erik quanstrom wrote:
>> > i think you're better off with char*s and realloc.
>
On Thu Feb 3 08:41:23 EST 2011, rogpe...@gmail.com wrote:
> On 3 February 2011 13:01, erik quanstrom wrote:
> > i think you're better off with char*s and realloc.
> > it's worth looking at the heavy machinery in sam
> > and acme, though, and comparing against ed.
>
> i'd hesitate before trying t
On 3 February 2011 13:01, erik quanstrom wrote:
> i think you're better off with char*s and realloc.
> it's worth looking at the heavy machinery in sam
> and acme, though, and comparing against ed.
i'd hesitate before trying to edit 500MB files in ed...
nor does ed cope with arbitrary length lin
On Thu Feb 3 04:36:35 EST 2011, fors...@terzarima.net wrote:
> > The finished version will support strings backed by file storage
>
> string(2) doesn't go quite that far, but is used by the mailer upas
> and perhaps other things to reduce the instances of arbitrarily low limits
> and bounds excee
> The finished version will support strings backed by file storage
string(2) doesn't go quite that far, but is used by the mailer upas
and perhaps other things to reduce the instances of arbitrarily low limits
and bounds exceeded.
On Thursday, February 03, 2011 04:35:04 am smi...@zenzebra.mv.com wrote:
> ron minnich writes:
> > OK, let's do a test. You write your stuff with iterators and put it on
> > a machine with 256MB. I'll create a file with a file name that is
> > 257MB long. What does your stuff do then?
>
> The fin
On Thu, Feb 03, 2011 at 03:35:04AM +, smi...@zenzebra.mv.com wrote:
>
> The finished version will support strings backed by file storage and
> should actually be able to handle that. But that's still far in the
> future, at this point. I haven't even finished coding the basic string
> operat
> The finished version will support strings backed by file storage and
I'm patiently waiting for strings backed by cloud storage.
ron minnich writes:
> OK, let's do a test. You write your stuff with iterators and put it on
> a machine with 256MB. I'll create a file with a file name that is
> 257MB long. What does your stuff do then?
The finished version will support strings backed by file storage and
should actually be abl
On Wed, Feb 2, 2011 at 11:15 AM, wrote:
>> bugs, iterators and the other crap you mentioned would had obfuscated
>> it.
>
> The "other crap" I mentioned would have made that bug IMPOSSIBLE.
OK, let's do a test. You write your stuff with iterators and put it on
a machine with 256MB. I'll create
"Federico G. Benavento" writes:
> I take it was trivial to find that overflow, come on the code is so simple
> that you just see and get it the first time, which makes easier to find/fix
Oh, really? Simple to find? Trivial? If so, then why wasn't that
overflow found and fixed long before I ev
> I know the cp suicide is a problem in cp, because I designed the test
> case to exercise a buffer overflow I found at /sys/src/cmd/cp.c:77,93
>
> void
> copy(char *from, char *to, int todir)
> {
> Dir *dirb, dirt;
> char name[256];
> int fdf, fdt, mode;
>
> > There's a reason it does not use that stuff, and it may not be what
> > you think.
>
> OK, come on already, quit teasing me! :) What's the secret reason?
when ron says this it's almost always a formula that means that it was
not done out of ignorance, stogginess, etc. as oo proponents tend t
On Tue, Feb 1, 2011 at 4:28 PM, wrote:
> ron minnich writes:
>
>> There's a reason it does not use that stuff, and it may not be what
>> you think.
>
> OK, come on already, quit teasing me! :) What's the secret reason?
I don't think it's a secret. There is a not very small group of people
who
ron minnich writes:
>>However, the Plan 9 code (at last that under /sys/src/cmd)
>> doesn't seem to make use of iterators, string objects (or even
>> object-orientation), modern string parsing routines, etc.
>
> There's a reason it does not use that stuff, and it may not be what
> you think.
OK,
On Tue, Feb 1, 2011 at 10:33 AM, ron minnich wrote:
> p.s. If you're going to rewrite /bin, maybe it's time to look at Go?
I've written a few unix-style programs in Go:
http://code.google.com/p/mango-doc/
http://code.google.com/p/simple-shell-utils/
(neither are exactly examples of my best-foot
On Tue, Feb 1, 2011 at 9:51 AM, wrote:
>However, the Plan 9 code (at last that under /sys/src/cmd)
> doesn't seem to make use of iterators, string objects (or even
> object-orientation), modern string parsing routines, etc.
There's a reason it does not use that stuff, and it may not be what you
ron minnich writes:
>> term% cp abc* abc* x
>> # watch the cp executable suicide
>> # now, make SURE there's nothing in this rio window that you want to keep...
>> term% rm abc*
>> # watch the rio window go bye bye!
>>
>
> it's not cp and it's not rio. I think you need to diagnose this a bit
> be
On Feb 1, 2011 1:05 AM, wrote:
> Reading about Plan 9, I was quite excited to install it. I was quite
> excited when I first booted and ran it, too. But I distinctly felt my
> heart sink a little the first time it hung. Since then, I've browsed
> some of the OS source code and, having done that
>The docs I've read seem to
>suggest that gcc is kind of "glued onto the side of" Plan 9 proper.
it's kind of unglued off the side of Plan 9 proper: gcc came unstuck
(in more ways than one).
i'm afraid it's harder to port (or do i mean compile?) than it ever was.
and then there's glibc, which you
> term% mkdir trashdir && cd trashdir && mkdir x
> term% touch `{i=0; while (test $i -lt 128) { echo -n abcdefghijklmnop;
> i=`{echo $i+1|hoc} } }
> term% cp abc* abc* x
> # watch the cp executable suicide
> # now, make SURE there's nothing in this rio window that you want to keep...
> term% rm ab
> Some, yes. But most not. At least not yet. :) I expect I might run
> into trouble figuring out how to pass around strings containing NUL
> bytes, though.
why would you do that? what's the application? if you tell me
sed'ing an object file, i'm going to remain unconvinced. if you
tell me su
lotte% 9fs sources
lotte% diff /sys/src/cmd/rc/plan9.c /n/sources/plan9/sys/src/cmd/rc/plan9.c
446d445
< char *s;
468,474c467
<
< s = dir[f].dbuf[dir[f].i].name;
< if(strlen(s) >= NDIR){
< pfmt(err, "rc: file name too long: %s\n", s);
< return 0;
<
Somehow a particular problem with a particular application
has degenerated into a rather unfair generalization of the
whole system:
> Reading about Plan 9, I was quite excited to install it. I was quite
> excited when I first booted and ran it, too. But I distinctly felt my
> heart sink a little
> term% mkdir trashdir && cd trashdir && mkdir x
> term% touch `{i=0; while (test $i -lt 128) { echo -n abcdefghijklmnop;
> i=`{echo $i+1|hoc} } }
> term% cp abc* abc* x
> # watch the cp executable suicide
> # now, make SURE there's nothing in this rio window that you want to keep...
> term% rm ab
On Tue, Feb 01, 2011 at 07:07:30AM +, smi...@zenzebra.mv.com wrote:
> Lucio De Re writes:
>
> > Also, you have managed to stomp all over a couple of this mailing list's
> > most sacred cows with your suggestion that the Plan 9 kernel code is less
> > than perfect
>
> Ooh! No intent to offen
Lucio De Re writes:
> Also, you have managed to stomp all over a couple of this mailing list's
> most sacred cows with your suggestion that the Plan 9 kernel code is less
> than perfect
Ooh! No intent to offend. I actually haven't even looked at the kernel
code, yet. I was referring to the bi
On Mon, Jan 31, 2011 at 10:02 PM, wrote:
> term% mkdir trashdir && cd trashdir && mkdir x
> term% touch `{i=0; while (test $i -lt 128) { echo -n abcdefghijklmnop;
> i=`{echo $i+1|hoc} } }
> term% cp abc* abc* x
> # watch the cp executable suicide
> # now, make SURE there's nothing in this rio w
On Tue, Feb 01, 2011 at 06:02:06AM +, smi...@zenzebra.mv.com wrote:
>
> I'm not someone to complain without also offering solutions, though.
> I'm in the process of writing some C macros that might help clean up the
> source code, ensure intended bounary conditions, improve some
> interfaces,
"Steve Simon" writes:
> This is the exact scenario I had when I ran fossil + venti with ephemerial
> snapshots enabled, are you sure you don't have them on?
Quite sure. :) That's why I ended up recovering the data from Linux.
> fossil/conf /dev/sd??/fossil | grep snaptime
I have just tw
> My system/file system locks up periodically, and (as I recently
> discovered) I don't even appear to have dumps/snapshots enabled. If the
> system doesn't lock up hard, any command that needs to read from the
> filesystem (i.e. running any command that's not built into rc) causes
> the shell to
Richard Miller <9f...@hamnavoe.com> writes:
> YMMV. My fossil has never locked up, but I get a corrupted daily
> dump two or three times a month.
My system/file system locks up periodically, and (as I recently
discovered) I don't even appear to have dumps/snapshots enabled. If the
system doesn'
On Sun Jan 30 09:20:31 EST 2011, 9f...@hamnavoe.com wrote:
> > sadly there is a bug in fossil that makes it unreliable
> > if snapshots ar enabled - it locks up once a month or so,
> > dumps work fine though.
>
> YMMV. My fossil has never locked up, but I get a corrupted daily
> dump two or three
> sadly there is a bug in fossil that makes it unreliable
> if snapshots ar enabled - it locks up once a month or so,
> dumps work fine though.
YMMV. My fossil has never locked up, but I get a corrupted daily
dump two or three times a month.
yep, dump is great.
sadly there is a bug in fossil that makes it unreliable
if snapshots ar enabled - it locks up once a month or so,
dumps work fine though.
free beer to the first person to find the fossil deadlock...
-Steve
smi...@zenzebra.mv.com writes:
> Of course, this overwrote important.h, a file containing C macros I
> spent all day writing.
Never mind!
I was able to recover the file from Linux:
term% aux/listen1 tcp!headache!1234 cat /dev/sdC0/fossil
I then used netcat on the Linux end and got the data bac
41 matches
Mail list logo
